Um ambiente de execução personalizado permite usar uma implementação alternativa de qualquer linguagem de ambiente flexível 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, o que permite a você se concentrar na criação do seu aplicativo.
Para criar um ambiente de execução personalizado, você precisa:
- Forneça um arquivo
app.yaml
que descreva a configuração de tempo de execução do aplicativo para o App Engine. - Adicione um
Dockerfile
que configure internamente o ambiente de execução. - verificar se o código segue algumas regras básicas.
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.
Especificar uma imagem de base
O primeiro comando em um Dockerfile é geralmente um comando FROM
, que especifica uma imagem de base.
Uma imagem de base é usada para criar o contêiner e o aplicativo. É
possível criar sua própria imagem de base
ou selecionar uma imagem de base nos registros do contêiner, como o DockerHub.
Localize 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 do código
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.
Detectar 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.
Processar eventos de ciclo de vida
O ambiente flexível envia periodicamente ao seu aplicativo determinados eventos do ciclo de vida.
Encerramento de aplicativos
Quando uma instância precisar ser encerrada, novas solicitações recebidas serão roteadas para
outras instâncias (se houver) e as solicitações que estiverem sendo processadas terão
tempo para serem concluídas. Quando você desativa uma instância, um sinal STOP
(SIGTERM
) é enviado ao contêiner do app pelo ambiente flexível. O aplicativo não precisa
responder a esse evento, mas pode usá-lo para executar as ações de limpeza necessárias
antes que o contêiner seja encerrado. Em condições normais, o sistema
aguarda até 30 segundos para que o app pare e, em seguida, envia um sinal KILL
(SIGKILL
),
encerrando imediatamente a instância.
Em casos raros, interrupções podem impedir que o App Engine forneça 30 segundos
de tempo de encerramento, 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.
Crie e implante o ambiente de execução personalizado
Depois de configurar os arquivos app.yaml
e DOCKER
, é possível
criar e implantar
essa imagem de contêiner no App Engine.
Como alternativa, é possível implantar imagens de contêiner pré-criadas dos ambientes de execução personalizados que estão armazenadas no Artifact Registry. Por exemplo, é possível usar o Cloud Build para criar imagens separadas e armazená-las no Artifact Registry. Para mais informações, consulte Enviar e extrair imagens.
Integrar seu aplicativo ao Google Cloud
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. Aplicativos de ambiente de execução personalizados também podem usar qualquer serviço de terceiros por meio das APIs padrão.
Autenticar com os serviços do Google Cloud
O Application Default Credentials oferece a maneira mais simples de autenticar e chamar APIs do Google.
Se o aplicativo usar o Cloud Build para compilar imagens do Docker, a rede cloudbuild
hospedará o Application Default Credentials permitindo que os serviços do Google Cloud associados encontrem suas credenciais automaticamente.
Para mais informações sobre autenticação, consulte Autenticação no Google.
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 Explorador 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 Explorador de registros. Somente as entradas mais recentes para stdout
e stderr
são mantidas para limitar o tamanho delas.
Também é possível gravar registros personalizados em /var/log/app_engine/custom_logs
, usando um arquivo com final .log
ou .json
.
Se você incluir agentes de terceiros no contêiner do aplicativo, configure-os para registro em stdout
e stderr
ou em um registro personalizado.
Isso garante que os erros gerados por esses agentes sejam visíveis no Cloud Logging.
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. |