Observação: o Go 1.11 chegou ao fim do suporte em 30 de janeiro de 2024. Os aplicativos Go 1.11 atuais continuarão a ser executados e a receber tráfego. No entanto, o App Engine pode bloquear a reimplantação de aplicativos que usam ambientes de execução após o término da data de suporte. Recomendamos que você migre para a versão compatível mais recente do Go.

Esta página foi traduzida pela API Cloud Translation.

Testar e implementar 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.

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

Execução local

Para testar a funcionalidade da sua aplicação antes da implementação, execute a aplicação no seu ambiente local com as ferramentas de desenvolvimento que usa habitualmente. Por exemplo, o comando go run.

Antes de implementar a sua aplicação

Antes de poder implementar a sua aplicação:

O proprietário do projeto Google Cloud tem de ativar o App Engine.
Tem de garantir que a sua conta de utilizador inclui os privilégios necessários.

Implementar 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 do App Engine. As compilações são criadas na região da app. Saiba mais em Faça a gestão das imagens de compilação.

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

Implementar 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.

Implementar 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.

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

Requisitos para implementar vários serviços

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.

Ver 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 do Cloud Build da Google Cloud consola. Para ver compilações na região da app, use o menu pendente Região na parte superior da página para escolher a região pela qual quer filtrar.

Ignorar 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.

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

Seguem-se os passos que ocorrem sempre que implementa uma nova versão:

O App Engine cria uma imagem de contentor através do serviço Cloud Build.
O Cloud Build cria a imagem de contentor na região da app e é executado no ambiente padrão do App Engine.
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.

Visualizar 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

Testar 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:

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
```
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 implementar 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.
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.

Usar variáveis de ambiente de compilação

Também pode definir variáveis de ambiente de compilação para tempos de execução que suportem os buildpacks do Google Cloud.

As variáveis de ambiente de compilação são pares de chave/valor implementados juntamente com uma app que permitem transmitir informações de configuração para os buildpacks. Por exemplo, pode querer personalizar as opções do compilador. Pode adicionar ou remover estas variáveis do ambiente de compilação configurando o campo build_env_variables no ficheiro app.yaml.

Nota: as chaves têm de começar com uma letra ASCII maiúscula e ser compostas por letras ASCII maiúsculas, dígitos e sublinhados. Deve evitar criar chaves de variáveis com o prefixo GOOGLE_*. Veja todas as variáveis de ambiente dos buildpacks suportadas.

Usar o servidor de desenvolvimento local

Pode usar dev_appserver para executar as suas apps 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.

Uma vez que o Go 1.11 atingiu o fim do apoio técnico, já não pode usar a versão mais recente do dev_appserver.py para executar localmente as suas aplicações. Para continuar a usar o dev_appserver.py, siga as instruções em Usar o servidor de desenvolvimento local.

Executar o servidor de desenvolvimento local

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.

Para obter credenciais de acesso para a sua conta de utilizador, execute o seguinte comando:
```
gcloud auth login
```
Permita que a sua aplicação local use temporariamente as suas credenciais de utilizador para acesso à API:
```
gcloud auth application-default login
```
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:
```
python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml
```
Para alterar a porta, inclua a opção --port:
```
python2 DEVAPPSERVER_ROOT/google_appengine/dev_appserver.py/dev_appserver.py --application=PROJECT_ID app.yaml --port=9999
```
Substitua DEVAPPSERVER_ROOT pelo caminho para a pasta onde extrai a versão arquivada de devapp_server.py. Para mais informações sobre como transferir e usar a versão arquivada do dev_appserver.py, consulte o artigo Usar o servidor de desenvolvimento local.

Para saber mais acerca das opções de comando dev_appserver.py, consulte as opções do servidor de desenvolvimento local.
À medida que o servidor de desenvolvimento local é iniciado, configura um ambiente de desenvolvimento que pré-instala as dependências encontradas no ficheiro requirements.txt.
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.
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.

Usar 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 da nuvem dependem da presença da variável de ambiente GOOGLE_CLOUD_PROJECT, que deve ser o ID do seu projetoGoogle Cloud . 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 usando o parâmetro --application=PROJECT_ID, conforme mostrado no exemplo anterior.

Emuladores do Cloud

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

Atualização automática das alterações `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

Descobrir 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ões, por exemplo, url: "customer1.myapp.com/*". As regras com padrões de caminhos 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.