Problemas conhecidos no ambiente flexível do App Engine

ID da região

O REGION_ID é um código abreviado que a Google atribui com base na região que seleciona quando cria a sua app. O código não corresponde a um país ou uma província, embora alguns IDs de regiões possam parecer semelhantes aos códigos de países e províncias usados frequentemente. Para apps criadas após fevereiro de 2020, REGION_ID.r está incluído nos URLs do App Engine. Para apps existentes criadas antes desta data, o ID da região é opcional no URL.

Saiba mais acerca dos IDs de regiões.

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

  • Depois de implementar a sua aplicação com gcloud app deploy, pode ter de aguardar 1 a 2 minutos antes de a aplicação começar a publicar anúncios em https://PROJECT_ID.REGION_ID.r.appspot.com. Até lá, pode ver erros HTTP 503.

    O App Engine regista frequentemente estes erros como backend_timeout ou failed_to_pick_backend nos registos do balanceador de carga de aplicações externo global. O Application Load Balancer externo global envia pedidos para um serviço no ambiente flexível do App Engine, independentemente do estado de funcionamento das instâncias individuais. Depois de implementar uma nova versão, o Application Load Balancer externo global demora algum tempo a atualizar a respetiva configuração com as novas instâncias de back-end. Durante esta transição, a disponibilidade dos serviços de back-end é inconsistente. Quando migrar tráfego para a nova versão, o Application Load Balancer externo global pode tentar enviar tráfego para instâncias que não estão totalmente prontas para receber pedidos, o que resulta em erros 503. Isto também pode resultar em erros 502, particularmente quando usa um Application Load Balancer clássico.

  • Se existir uma política da organização no seu projeto que restrinja o acesso a IPs externos, não pode implementar uma app do ambiente flexível do App Engine com endereços IP externos. Por exemplo, a política da organização pode ter o seguinte aspeto:

    • A política em vigor para constraints/compute.vmExternalIpAccess está definida como DENY_ALL.
    • A política eficaz para constraints/compute.vmExternalIpAccess está definida para permitir apenas instâncias de VM específicas.
    • A política efetiva para constraints/compute.requireOsConfig está desativada para o projeto para impedir atualizações de metadados.

    Estas restrições não são detetadas automaticamente e as implementações podem exceder o limite de tempo e falhar. Pode verificar a política da organização do seu projeto executando o comando gcloud beta resource-manager org-policies describe compute.vmExternalIpAccess --project=my-project --effective. Também pode substituir a política organizacional para um projeto específico.

    No entanto, mesmo com estas políticas organizacionais definidas, pode implementar uma app do ambiente flexível do App Engine que use apenas o respetivo endereço IP interno.

  • Depois de implementar uma nova versão de um serviço existente no ambiente flexível do App Engine com gcloud app deploy, a métrica "Contagem/seg" apresentada no gráfico "Resumo" do painel de controlo do App Engine pode diminuir significativamente. A métrica vai regressar gradualmente à quantidade de pedidos esperada nos próximos 5 a 10 minutos.

    Isto não significa que a sua aplicação esteja a publicar menos pedidos. Quando implementa uma nova versão da sua aplicação, existe um atraso entre o momento em que a nova versão está pronta para publicar pedidos e o momento em que as métricas para novas instâncias ficam disponíveis.

    Para garantir que esta métrica não é afetada pela implementação de uma nova versão:

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

    Se fizer a implementação com --no-promote, mas atribuir qualquer quantidade de tráfego à nova versão antes do período de 15 minutos após a conclusão da implementação, esta métrica pode ser afetada.

  • No ambiente flexível do App Engine, não é possível configurar o app.yaml para que a sua app redirecione automaticamente os pedidos para usar sempre HTTPS. Isto difere do ambiente padrão do App Engine, onde pode usar a definição secure.

    Em alternativa, pode processar o redirecionamento no código da aplicação analisando o valor do cabeçalho X-Forwarded-Proto. Também pode incentivar os clientes a usarem o cabeçalho Strict-Transport-Security.

  • Se atribuir uma conta de serviço gerida pelo utilizador a uma versão do ambiente flexível do App Engine, o seu projeto pode ser faturado por métricas com o prefixo agent.googleapis.com. Normalmente, estas métricas de agentes não são cobrados ao seu projeto. Recomendamos que continue a usar a conta de serviço predefinida do App Engine até que este problema seja resolvido.

  • Não é possível estabelecer uma ligação SSH a uma instância de VM através do IAP.

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

  • Em eventos raros, a sua aplicação pode registar uma redução inesperada no número de instâncias devido a falhas de zona ou se um grupo inteiro de instâncias deixar de responder. Para evitar esta situação, a Google recomenda o aprovisionamento excessivo da sua aplicação para impedir que o sistema fique abaixo do número mínimo de instâncias. Pode definir o tamanho de min_num_instances da aplicação do ambiente flexível do App Engine quando a implementar. Seguem-se alguns eventos que podem afetar o número mínimo de instâncias do ambiente flexível do App Engine:

    1. Implementação de atualizações nas instâncias do ambiente flexível
    2. Falha zonal (problemas de indisponibilidade, como quando a sua região está no limite da capacidade para a CPU selecionada, etc.)

    O ambiente flexível do App Engine usa 3 zonas para distribuir as suas instâncias e, numa configuração deste tipo, recomendamos o aprovisionamento de 50% mais instâncias do que o necessário.

Métricas do Cloud Load Balancing inconsistentes

O painel de controlo do ambiente flexível do App Engine apresenta todas as métricas apenas para pedidos encaminhados através de um back-end gerido pelo ambiente flexível. Se usar o ambiente flexível do App Engine com o Cloud Load Balancing, determinadas métricas na tabela de métricas do App Engine são comunicadas como métricas da tabela loadbalancing. Para mais informações, consulte o artigo Registo e monitorização do balanceamento de carga HTTP(S).

InterruptedException em tempos de execução que usam a JVM durante a falha da verificação de funcionamento

Quando uma verificação de funcionamento falha, a VM é encerrada. Como sintoma de o contentor da app ficar em mau estado, a JVM responde com erros InterruptedException e NullPointerException. Um controlador pode responder ao sinal SIGTERM enviado pelo contentor durante o encerramento, para realizar quaisquer ações de limpeza ou depuração necessárias, de modo a evitar exceções.