Problemas conhecidos no ambiente flexível do App Engine

Para uma lista completa de problemas conhecidos ou para relatar um novo problema, consulte o rastreador de problemas.

• Depois de implantar o aplicativo com gcloud app deploy, talvez seja necessário aguardar de um a dois minutos para que o aplicativo comece a ser veiculado em https://PROJECT_ID.REGION_ID.r.appspot.com. Durante esse tempo, talvez apareçam erros HTTP 503.

  O App Engine geralmente registra esses erros como backend_timeout ou failed_to_pick_backend nos registros do balanceador de carga de aplicativo externo global. O balanceador de carga de aplicativo externo global envia solicitações para um serviço no ambiente flexível do App Engine, independentemente da integridade das instâncias individuais. Depois de implantar uma nova versão, o balanceador de carga de aplicativo externo global leva um tempo para atualizar a configuração com as novas instâncias de back-end. Durante essa transição, a disponibilidade dos serviços de back-end é inconsistente. Ao migrar o tráfego para a nova versão, o balanceador de carga de aplicativo externo global pode tentar enviar tráfego para instâncias que não estão totalmente prontas para receber solicitações, resultando em erros 503. Isso também pode resultar em erros 502, principalmente ao usar um balanceador de carga de aplicativo clássico.

• Se houver uma política da organização no projeto que restrinja o acesso a IPs externos, não será possível implantar um aplicativo de ambiente flexível do App Engine com endereços IP externos. Por exemplo, a política da organização pode ter a seguinte aparência:

  • A política vigente para constraints/compute.vmExternalIpAccess é definida como DENY_ALL.
  • A política efetiva para constraints/compute.vmExternalIpAccess está definida para permitir somente instâncias de VM específicas.
  • A política vigente para constraints/compute.requireOsConfig está desativada no projeto para evitar atualizações de metadados.

  Essas restrições não são detectadas automaticamente e as implantações podem atingir o tempo limite e falhar. Para verificar a política da organização do seu projeto, execute o comando gcloud beta resource-manager org-policies describe compute.vmExternalIpAccess --project=my-project --effective. Também é possível substituir a política organizacional de um projeto específico.

  No entanto, mesmo com essas políticas da organização definidas, é possível implantar um app particular do ambiente flexível do App Engine que use apenas o endereço IP interno dele.

• Após a implantação de uma nova versão de um serviço atual no ambiente flexível do App Engine com gcloud app deploy, a métrica "Contagem/segundo" mostrada no gráfico "Resumo" do painel do App Engine pode diminuir significativamente. A métrica retornará gradualmente à contagem de solicitações esperada nos próximos 5 a 10 minutos.

  Isso não significa que seu aplicativo está exibindo menos solicitações. Ao implantar uma nova versão do aplicativo, há um atraso entre o momento em que a nova versão fica pronta para atender às solicitações e o horário em que as métricas para novas instâncias ficam disponíveis.

  Para garantir que essa métrica não seja afetada por uma nova implantação da versão:

  1. Implante sua nova versão com gcloud app deploy --no-promote.
  2. Aguarde 15 minutos após a conclusão da implantação.
  3. Migre o tráfego para a nova versão.

  Se você implantar com --no-promote, mas alocar qualquer quantidade de tráfego para a nova versão antes do período de 15 minutos após a conclusão da implantação, essa métrica poderá ser afetada.

• No ambiente flexível do App Engine, não é possível configurar app.yaml para que o aplicativo redirecione automaticamente as solicitações para sempre usar HTTPS. Isso é diferente do ambiente padrão do App Engine, em que é possível usar a configuração secure.

  Como alternativa, é redirecionar dentro do código do aplicativo analisando o valor do cabeçalho X-Forwarded-Proto. Também é possível incentivar os clientes a usar o cabeçalho Strict-Transport-Security.

• Se você atribuir uma conta de serviço gerenciada pelo usuário a uma versão do ambiente flexível do App Engine, o projeto poderá ser cobrado por métricas com prefixo agent.googleapis.com. Normalmente, essas métricas de agente não são cobradas no projeto. Recomendamos que você continue usando a conta de serviço padrão do App Engine até que esse problema seja resolvido.

• Não é possível estabelecer uma conexão SSH com uma instância de VM usando o IAP.

Redução inesperada no número de instâncias

• Em casos raros, o aplicativo pode perceber uma redução inesperada no número de instâncias devido a falhas na zona ou se um grupo inteiro de instâncias parar de responder. Para evitar isso, o Google recomenda o provisionamento excessivo do aplicativo para que o sistema não fique abaixo do número mínimo de instâncias. É possível definir o tamanho min_num_instances do aplicativo do ambiente flexível do App Engine ao implantá-lo. Veja a seguir alguns eventos que podem afetar o número mínimo de instâncias do ambiente flexível do App Engine:

  1. Lançamento de atualizações para instâncias de ambiente flexível
  2. Falha zonal (problemas de falta de estoque, como quando sua região atinge a capacidade da CPU selecionada etc.)

  O ambiente flexível do Google App Engine usa três zonas para distribuir suas instâncias e, em uma configuração como essa, recomendamos que você provisione 50% mais instâncias do que o necessário.

Métricas inconsistentes do Cloud Load Balancing

O painel do ambiente flexível do App Engine mostra todas as métricas apenas para solicitações roteadas por um back-end gerenciado de ambiente flexível. Se você usar o ambiente flexível do App Engine com o Cloud Load Balancing, algumas métricas na tabela de métricas do App Engine serão informadas como métricas da tabela loadbalancing. Para mais informações, consulte Geração de registros e monitoramento de balanceamento de carga HTTP(S).

InterruptedException em ambientes de execução usando JVM durante a falha na verificação de integridade

Quando uma verificação de integridade falha, a VM é encerrada. Como um sintoma de que o contêiner do app está com problemas, a JVM responde com erros InterruptedException e NullPointerException. Um manipulador pode responder ao sinal SIGTERM enviado pelo contêiner durante o encerramento para realizar as ações de limpeza ou depuração necessárias e evitar exceções.