Como criar ambientes de execução personalizados

Um ambiente de execução personalizado permite usar uma implementação alternativa de qualquer linguagem de ambiente flexível do App Engine compatível ou personalizar uma fornecida pelo Google. Também é possível escrever o código em qualquer outra linguagem capaz de processar solicitações HTTP recebidas (exemplo). Em um ambiente de execução personalizado, a infraestrutura de dimensionamento, monitoramento e balanceamento de carga é fornecida e gerenciada pelo ambiente flexível do App Engine, o que permite a você se concentrar na criação do seu aplicativo.

Para criar um ambiente de execução personalizado, você precisa:

Fornecer um arquivo app.yaml

Seu arquivo de configuração app.yaml precisa conter pelo menos as seguintes configurações:

runtime: custom
env: flex

Para informações sobre o que mais pode ser definido para seu aplicativo, consulte Como configurar seu aplicativo com app.yaml.

Criar um DockerFile

Uma documentação abrangente sobre criação de Dockerfiles está disponível no site do Docker. Se você estiver usando um ambiente de execução personalizado, precisará fornecer um Dockerfile, esteja você fornecendo sua própria imagem de base ou usando uma das imagens de base do Google.

Como especificar uma imagem de base do Google

O primeiro comando em um Dockerfile é geralmente um comando FROM, que especifica uma imagem de base. A tabela a seguir mostra o comando FROM, usado para especificar imagens de base fornecidas pelo Google, com o projeto do github usado para criar a imagem:

Runtime Comando Nota
Go
Projeto do GitHub
FROM gcr.io/google-appengine/golang
Java (somente JDK 8 aberto)
Projeto do GitHub
FROM gcr.io/google-appengine/openjdk Dockerfiles para Java.
Java (Open JDK 8 + Eclipse Jetty 9.3)
Projeto do GitHub
FROM gcr.io/google-appengine/jetty Dockerfiles para Java.
Python 2.7 & 3.6
Projeto do GitHub
FROM gcr.io/google-appengine/python
Node.js
Projeto do GitHub
FROM gcr.io/google-appengine/nodejs
Ruby
Projeto do GitHub
FROM gcr.io/google-appengine/ruby
PHP
Projeto do GitHub
FROM gcr.io/google-appengine/php

Como usar as APIs de serviço do App Engine

Para acessar as APIs de serviço do App Engine a partir de um aplicativo Go que esteja executando a imagem de base do golang, é preciso importar as bibliotecas do Go do App Engine para seu código-fonte.

Como usar os ambientes de execução Java personalizados

Para personalizar um ambiente de execução Java e incluir diretivas adicionais, é preciso criar um Dockerfile.

Exemplo de Dockerfile para Java 8/Jetty 9:

FROM gcr.io/google-appengine/jetty
ADD test-webapp-1.0-SNAPSHOT.war $JETTY_BASE/webapps/root.war
WORKDIR $JETTY_BASE
RUN java -jar $JETTY_HOME/start.jar --approve-all-licenses --add-to-startd=jmx,stats,hawtio 
&& chown -R jetty:jetty $JETTY_BASE

em que test-webapp-1.0-SNAPSHOT.war é o nome do arquivo WAR criado no diretório target/ (maven) ou build/staged-app/ (gradle).

Não é necessário um Dockerfile para implantar seu aplicativo no App Engine caso você opte por usar uma imagem de base não personalizada de um dos tempos de execução Java fornecidos pelo Google. Para mais informações, consulte Ambiente de execução do Java 8 ou Ambiente de execução do Java 8/Jetty 9.

Para ver uma lista com todas as imagens fornecidas pelo Google, consulte o projeto google-appengine.

Como nomear e localizar o Dockerfile

Em geral, o Dockerfile é sempre nomeado Dockerfile e é colocado no mesmo diretório que o arquivo app.yaml correspondente. Em alguns casos, o ambiente de ferramentas pode ter requisitos diferentes. Por exemplo, as ferramentas Java baseadas no SDK do Cloud, como os plug-ins Maven, Gradle, Eclipse e IntelliJ, exigem que o Dockerfile esteja em src/main/docker/Dockerfile e o arquivo app.yaml esteja em src/main/appengine/app.yaml. Para mais informações, consulte a documentação do seu ambiente de ferramentas.

Estrutura de código obrigatória

Nesta seção, descrevemos o comportamento que seu código deve implementar, independentemente de você usar uma imagem de base fornecida pelo Google ou uma imagem de base própria.

Como escutar a porta 8080

As solicitações recebidas serão encaminhadas pelo front-end do App Engine para o módulo apropriado, na porta 8080. Você deve garantir que o código do seu aplicativo esteja escutando na porta 8080.

Como processar eventos do ciclo de vida

Determinados eventos do ciclo de vida são enviados periodicamente ao seu aplicativo pelo ambiente flexível do App Engine.

Desativação de aplicativos

Quando você desativa uma instância, um sinal STOP (SIGTERM) é enviado ao contêiner do app pelo ambiente flexível do App Engine. O aplicativo não precisa responder a esse evento, mas pode usá-lo para realizar qualquer ação de limpeza que precise ser feita antes que o contêiner seja fechado. Em condições normais, o sistema aguarda até 30 segundos para o aplicativo parar e envia um sinal KILL (SIGKILL).

Em casos raros, interrupções podem impedir que o Google App Engine forneça 30 segundos de tempo desativação, significando que os sinais STOP e KILL podem não ser enviados antes da finalização de uma instância. Para lidar com essa possibilidade, é preciso criar periodicamente checkpoints do estado da instância, usando-os principalmente como um cache na memória em vez de um armazenamento de dados confiável.

Solicitações de verificação de integridade

Você pode usar solicitações periódicas de verificação de integridade para confirmar que uma instância de VM foi implantada com êxito e para verificar se uma instância em execução mantém um status de integridade.

Como integrar um aplicativo ao Google Cloud Platform

Aplicativos em execução em ambientes de execução personalizados podem usar as Bibliotecas de cliente do Google Cloud para acessar os serviços do Google Cloud Platform. Aplicativos de ambiente de execução personalizados também podem usar qualquer serviço de terceiros por meio das APIs padrão.

Como autenticar com os serviços do Google Cloud Platform

Em geral, as Credenciais padrão do aplicativo oferecem a maneira mais simples para fazer a autenticação e chamar as APIs do Google.

É possível autenticar seu aplicativo diretamente com tokens de acesso usando a API de metadados do Compute Engine, mas isso é consideravelmente mais complexo. Em seguida, você pode usar esses tokens de acesso em solicitações de API, como solicitações em serviços e recursos do Cloud Storage e do Datastore.

Para mais informações sobre opções de autenticação, consulte este link.

Logging

Quando uma solicitação é enviada para um aplicativo em execução no App Engine, os detalhes da solicitação e as respostas são registrados automaticamente. Eles podem ser visualizados no visualizador de registros do Console do Google Cloud.

Ao tratar uma solicitação, o aplicativo pode gravar as próprias mensagens de registro em stdout e stderr. Esses arquivos são coletados automaticamente e podem ser vistos no Visualizador de registros. Somente as entradas mais recentes para stdout e stderr são mantidas para limitar o tamanho delas.

Os registros de solicitação e aplicativo são coletados por um agente do Cloud Logging e são mantidos por no máximo 90 dias, até um tamanho máximo de 1 GB. Se você quiser armazenar os registros por um período maior ou armazenar um tamanho maior que 1 GB, exporte os registros para o Cloud Storage. Além disso, é possível exportá-los para o BigQuery e Pub/Sub se quiser processamento adicional.

Outros registros também estão disponíveis para uso. A seguir, veja alguns dos registros configurados por padrão:

Nome do registro Tipo de payload Finalidade
crash.log texto Informações registradas quando a instalação falha. Se o aplicativo não for executado, verifique esse registro.
monitoring.* texto Informações dos dados de publicação do contêiner do Docker para o Cloud Monitoring.
shutdown.log texto Informações registradas no desligamento.
stdout texto Saída padrão do aplicativo.
stderr texto Erro padrão do contêiner.
syslog texto O syslog da VM fora do contêiner do Docker.