Teste e implemente a sua aplicação

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.

OK

Go Java Node.js PHP Python Ruby

Saiba como executar a sua aplicação localmente, implementá-la e testá-la no App Engine.

Executar localmente

Para testar a sua aplicação antes da implementação, execute-a no ambiente local com as ferramentas de desenvolvimento que usa habitualmente. Recomendamos que use ferramentas Python padrão, como virtualenv, para criar ambientes isolados e pytest para executar testes unitários e testes de integração, em vez de depender do dev_appserver, o servidor de desenvolvimento local fornecido com o Google Cloud SDK.

Por exemplo, normalmente, pode executar uma aplicação Flask com o servidor de desenvolvimento do Flask usando:

python main.py

Inicie aplicações Django com:

python manage.py runserver

Para simular um ambiente de produção do App Engine, execute o servidor de interface de gateway do servidor Web (WSGI) completo localmente. Use o mesmo comando especificado como ponto de entrada no seu ficheiro app.yaml, por exemplo:

gunicorn -b :$PORT main:app

Antes de implementar a sua aplicação

Antes de implementar a sua aplicação:

• O proprietário do Google Cloud projeto tem de configurar o seu Google Cloud projeto para o App Engine.
• Certifique-se de que a sua conta de utilizador inclui os privilégios necessários.

Implemente a sua aplicação

Implemente a sua aplicação no App Engine através do comando gcloud app deploy. Durante a implementação, o serviço Cloud Build cria uma imagem de contentor da sua aplicação para execução no ambiente padrão. Cada compilação é executada na mesma região que o seu Google Cloud projeto. Para mais informações, consulte o artigo Faça a gestão de imagens de compilação.

Para implementar as suas apps programaticamente, use a API Admin.

Implemente um serviço

Implementa a sua aplicação no App Engine implementando versões dos serviços da sua aplicação e cada um dos respetivos ficheiros de configuração.

Para implementar uma versão do serviço da sua aplicação, execute o seguinte comando a partir do diretório onde se encontra o ficheiro app.yaml do seu serviço:

gcloud app deploy

Se não especificar ficheiros com o comando, apenas implementa o ficheiro app.yaml no diretório atual. Por predefinição, o comando deploy gera um ID exclusivo para a versão que implementa, implementa a versão no projetoGoogle Cloud para o qual configurou a CLI Google Cloud para usar e encaminha todo o tráfego para a nova versão.

Pode alterar o comportamento predefinido do comando segmentando ficheiros específicos ou incluindo parâmetros adicionais:

• Para implementar os outros ficheiros de configuração do seu serviço, tem de segmentar e implementar cada ficheiro em separado. Por exemplo:

  gcloud app deploy cron.yaml
  gcloud app deploy dispatch.yaml
  gcloud app deploy index.yaml

• Para especificar um ID da versão personalizado, use a flag --version.
• Para impedir que o tráfego seja encaminhado automaticamente para a nova versão, use a flag --no-promote.
• Para implementar num Google Cloud projeto--project específico, use a flag --project.

Por exemplo, para implementar o serviço definido pelo ficheiro app.yaml num projeto Google Cloud específico, atribua-lhe um ID de versão personalizado e impeça o encaminhamento do tráfego para a nova versão:

gcloud app deploy --project PROJECT_ID --version VERSION_ID --no-promote

Para mais informações sobre este comando, consulte a gcloud app deploy referência.

Nota: pode definir propriedades para a CLI Google Cloud e criar e gerir configurações do SDK para não ter de especificar flags como --project sempre que implementar.

Quando implementa uma nova versão com o mesmo nome de uma versão existente, o App Engine migra imediatamente o tráfego para a nova versão. Existe um pico de latência quando o App Engine carrega pedidos para a nova versão. A nova versão substitui a anterior e não pode migrar o tráfego para a versão anterior. Todas as instâncias da versão anterior são imediatamente encerradas. Para mais informações, consulte o artigo Migrar tráfego.

Implemente vários serviços

Usa o mesmo comando de implementação para implementar ou atualizar os vários serviços que compõem a sua aplicação.

Antes de começar:

• Inicialmente, tem de implementar uma versão da sua aplicação no serviço default antes de poder criar e implementar serviços subsequentes.
• O ID de cada um dos seus serviços tem de ser especificado nos respetivos ficheiros de configuração app.yaml. Para especificar o ID do serviço, inclua a definição do elemento service em cada ficheiro de configuração. Por predefinição, a exclusão desta definição de elemento do ficheiro de configuração implementa a versão no serviço default.

Para implementar vários serviços, implemente separadamente o ficheiro app.yaml de cada serviço. Pode especificar vários ficheiros com um único comando gcloud app deploy:

gcloud app deploy service1/app.yaml service2/app.yaml

Veja os registos de compilação

O Cloud Build transmite registos de compilação e implementação que são visíveis na secção Histórico de compilação do Cloud Build na Google Cloud consola. Para ver compilações na região da app, use o menu Região para filtrar por região.

Faça a gestão das imagens de compilação

Atenção: o Container Registry foi descontinuado. A partir de 18 de março de 2025, o Container Registry é encerrado e a gravação de imagens no Container Registry fica indisponível. Para ver detalhes sobre a descontinuação e como migrar para o Artifact Registry, consulte Descontinuação do Container Registry.

Sempre que implementa uma nova versão:

1. O App Engine cria uma imagem de contentor através do serviço Cloud Build.

2. O Cloud Build cria a imagem de contentor na região da app e é executado no ambiente padrão do App Engine.

3. O App Engine armazena imagens de contentores criadas no Artifact Registry. Pode transferir estas imagens para as manter ou apresentar noutro local.

Após a conclusão da implementação, o App Engine já não precisa das imagens de contentores. As imagens de contentores não são eliminadas automaticamente. Para evitar atingir a quota de armazenamento, pode eliminar em segurança as imagens de que não precisa. No entanto, se precisar das imagens no futuro ou quiser manter uma cópia das imagens, tem de exportar uma cópia antes da eliminação. Para mais informações sobre a gestão de imagens no Artifact Registry, consulte o artigo Faça a gestão de imagens.

Ignore ficheiros

Pode usar um ficheiro .gcloudignore para especificar ficheiros e diretórios que não vão ser carregados para o App Engine quando implementar os seus serviços. Isto é útil para ignorar artefactos de compilação e outros ficheiros que não precisam de ser carregados com a sua implementação.

Nota: não pode especificar o campo skip_files no ficheiro app.yaml se tiver um ficheiro .gcloudignore.

Veja a sua candidatura

Depois de implementar a aplicação no App Engine, pode executar o seguinte comando para iniciar o navegador e vê-la em https://PROJECT_ID.REGION_ID.r.appspot.com:

gcloud app browse

Teste no App Engine antes de mudar o tráfego

Antes de configurar uma nova versão para receber tráfego, pode testá-la no App Engine. Por exemplo, para testar uma nova versão do seu serviço default:

1. Implemente a nova versão, mas impeça o encaminhamento automático do tráfego para a nova versão:

   gcloud app deploy --no-promote

2. Aceda à nova versão navegando para o seguinte URL:

   https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

   Nota: pode encontrar o ID da versão na Google Cloud consola ou especificar um quando fizer a implementação com o --version flag. A CLI do Google Cloud também produz o ID da versão quando implementa.

   Agora, pode testar a nova versão no ambiente de tempo de execução do App Engine. Pode depurar a sua aplicação vendo os respetivos registos. Para mais informações, consulte o artigo Escrever registos de aplicações.

   O App Engine encaminha os pedidos enviados para https://PROJECT_ID.REGION_ID.r.appspot.com para a versão configurada anteriormente para receber tráfego.

3. Quando quiser enviar tráfego para a nova versão, use a Google Cloud consola para migrar o tráfego:

   Faça a gestão das versões

   Selecione a versão que acabou de implementar e clique em Migrar tráfego.

Pode usar o mesmo processo para testar novas versões de outros serviços substituindo default no URL pelo nome do seu serviço:

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

Para mais informações sobre a segmentação de serviços e versões específicos, consulte o artigo Como os pedidos são encaminhados.

Use variáveis de ambiente de compilação

Pode definir variáveis de ambiente de compilação para tempos de execução que suportam buildpacks.

As variáveis de ambiente de compilação são pares de chave-valor que pode especificar para configurar o buildpack que usa para implementar a sua app. Por exemplo, pode querer especificar opções do compilador.

Antes de começar:

• As chaves têm de começar com uma letra ASCII em maiúsculas e podem incluir letras ASCII em maiúsculas, dígitos e sublinhados.
• Deve evitar criar variáveis com um prefixo de chave GOOGLE_*.
• As seguintes chaves estão reservadas para utilização pela Google:
  • GOOGLE_RUNTIME
  • GOOGLE_RUNTIME_VERSION
  • GOOGLE_ENTRYPOINT
  • GOOGLE_DEVMODE
• Pode usar qualquer chave suportada por buildpacks.

Para usar variáveis de ambiente com buildpacks, especifique o campo build_env_variables no ficheiro app.yaml.

Saiba mais acerca dos buildpacks.

Use o servidor de desenvolvimento local

A CLI do Google Cloud inclui um servidor de desenvolvimento local denominado dev_appserver que pode executar localmente para simular a execução da sua aplicação no App Engine de produção. Este servidor de desenvolvimento simula parcialmente o ambiente em que a sua aplicação é executada, o que lhe permite testar apps escritas para qualquer um dos tempos de execução do ambiente padrão.

Execute o servidor de desenvolvimento local

Importante: antes de executar o servidor de desenvolvimento local, siga as instruções de configuração.

Depois de criar o ficheiro de configuração app.yaml para a sua app, pode iniciar o servidor de desenvolvimento local com o comando dev_appserver.py para executar a app localmente.

1. Para obter credenciais de acesso para a sua conta de utilizador, execute o seguinte comando:

   gcloud auth login
   

2. Permita que a sua aplicação local use temporariamente as suas credenciais de utilizador para acesso à API:

   gcloud auth application-default login
   

3. Para iniciar o servidor de desenvolvimento local:

   No diretório que contém o ficheiro de configuração app.yaml, execute o comando dev_appserver.py e especifique o ID do projeto e o caminho para o ficheiro app.yaml:

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml

   Para alterar a porta, inclua a opção --port:

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999

   Para testar uma app Python 3, execute dev_appserver.py com um intérprete Python 3. Tem de especificar o binário Python 3 na flag --runtime_python_path, por exemplo:

   python3 CLOUD_SDK_ROOT/bin/dev_appserver.py --runtime_python_path=/usr/bin/python3 --application=PROJECT_ID app.yaml --port=9999

   Para saber mais acerca das opções de comando dev_appserver.py, consulte as opções do servidor de desenvolvimento local.

4. À medida que o servidor de desenvolvimento local é iniciado, configura um ambiente de desenvolvimento que pré-instala as dependências encontradas no seu ficheiro requirements.txt.

5. O servidor de programação local está agora em execução e a ouvir pedidos. Visite http://localhost:8080/ no seu navegador de Internet para ver a app em ação.

   Se especificou uma porta personalizada com a opção --port, lembre-se de abrir o seu navegador nessa porta.

6. Para parar o servidor local a partir da linha de comandos, prima Control-C no teclado.

Detetar o ambiente de tempo de execução da aplicação

Para determinar se o seu código está a ser executado em produção ou no servidor de desenvolvimento local, pode verificar a variável de ambiente GAE_ENV:

if os.getenv('GAE_ENV', '').startswith('standard'):
  # Production in the standard environment
else:
  # Local execution.

Use o servidor de desenvolvimento local com Google Cloud serviços

Pode integrar o dev_appserver com outros Google Cloud componentes.

Bibliotecas cliente da nuvem

Muitas bibliotecas de cliente do Google Cloud dependem da presença da variável de ambiente GOOGLE_CLOUD_PROJECT, que deve ser o seuGoogle Cloud ID do projeto. Pode encontrar o respetivo valor executando o comando gcloud config list project ou consultando a página do projeto na Google Cloud console.

Para garantir que esta variável de ambiente está definida corretamente durante o desenvolvimento local, inicialize dev_appserver com o parâmetro --application=PROJECT_ID, conforme mostrado no exemplo acima.

Emuladores do Cloud

Pode testar a sua aplicação com emuladores para o Cloud Datastore, Cloud Bigtable e o Cloud Pub/Sub.

Recarregamento automático das alterações de requirements.txt e app.yaml

O servidor de desenvolvimento local instala automaticamente as dependências encontradas no ficheiro requirements.txt. dev_appserver também lhe permite testar a funcionalidade configurada através de app.yaml. Por exemplo, pode testar a capacidade da sua app de publicar ficheiros estáticos. Quando dev_appserver está em execução, quaisquer alterações a requirements.txt e app.yaml reiniciam automaticamente a sua app para refletir estas alterações. Isto pode resultar num atraso temporário à medida que as dependências são transferidas e instaladas.

Gestão e encaminhamento de instâncias no servidor de desenvolvimento

Descubra endereços de instâncias

O servidor de desenvolvimento local cria todas as instâncias de escalonamento manual no arranque. As instâncias dos serviços de escalabilidade automática e básica são geridas dinamicamente. O servidor atribui uma porta a cada serviço e os clientes podem depender do servidor para equilibrar a carga e selecionar uma instância automaticamente. As atribuições de portas para endereçar cada serviço aparecem na stream de mensagens de registo do servidor.

Seguem-se as portas de uma app que define três serviços:

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

Quando usa o endereço de um serviço, por exemplo, http://localhost:8082/, o servidor cria ou seleciona uma instância do serviço e envia o pedido para essa instância.

O servidor atribui portas únicas a cada instância de um serviço. Pode usar o servidor de administração para descobrir estas portas. Existe uma porta exclusiva para o servidor de administração, que aparece no registo de mensagens:

INFO Starting admin server at: http://localhost:8000

Este endereço direciona para a consola do servidor de administração. Clique em Instâncias para ver o estado dinâmico das instâncias da sua app

É apresentada uma entrada separada para cada instância manual e básica. Os números das instâncias são links com endereços de portas exclusivos para cada instância. Clique no link para enviar um pedido diretamente para essa instância.

Ficheiros de envio

Se a sua app incluir um ficheiro dispatch.yaml, o fluxo de mensagens de registo inclui uma porta do distribuidor:

INFO Starting dispatcher running at: http://localhost:8080

As solicitações para esta porta são encaminhadas de acordo com as regras no ficheiro de expedição. O servidor não suporta regras de ficheiros dispatch.yaml que incluam nomes de anfitrião, por exemplo, url: "customer1.myapp.com/*". As regras com padrões de caminho relativos (url: "*/fun") funcionam, pelo que pode usar URLs como http://localhost/fun/mobile para alcançar instâncias. O servidor comunica um erro no fluxo de registo se tentar iniciar uma aplicação com um ficheiro dispatch.yaml que contenha regras baseadas no anfitrião.

Use o Cloud Trace

O Cloud Trace é útil para compreender como os pedidos se propagam através da sua aplicação. Pode inspecionar informações detalhadas de latência para um único pedido ou ver a latência agregada para toda a sua aplicação.

Para ver detalhes do rastreio no Cloud Trace, pode seguir os passos em Encontre e explore rastreios. No Explorador de rastreios, pode usar os filtros para filtrar por um serviço e uma versão específicos do App Engine.