Crie tempos de execução personalizados

Um tempo de execução personalizado permite-lhe usar uma implementação alternativa de qualquer idioma de ambiente flexível suportado ou personalizar um idioma fornecido pela Google. Também lhe permite escrever código em qualquer outro idioma que possa processar pedidos HTTP recebidos (exemplo). Com um tempo de execução personalizado, o ambiente flexível fornece e gere a sua infraestrutura de escalamento, monitorização e equilíbrio de carga, para que se possa concentrar na criação da sua aplicação.

Para criar um tempo de execução personalizado, tem de:

Forneça um ficheiro app.yaml

O ficheiro de configuração app.yaml tem de conter, pelo menos, as seguintes definições:

runtime: custom
env: flex

Para obter informações sobre o que mais pode definir para a sua app, consulte o artigo Configurar a sua app com app.yaml.

Crie um ficheiro Dockerfile

Está disponível documentação abrangente sobre a criação de Dockerfiles no Website do Docker. Se estiver a usar um tempo de execução personalizado, tem de fornecer um Dockerfile, quer esteja a fornecer a sua própria imagem base ou a usar uma das imagens base da Google.

Especifique uma imagem base

O primeiro comando num Dockerfile é normalmente um comando FROM que especifica uma imagem de base. É usada uma imagem base para criar o contentor e compilar a sua aplicação. Pode criar a sua própria imagem de base ou selecionar uma imagem de base a partir de registos de contentores, como o DockerHub.

Localize o ficheiro Dockerfile

Em geral, o Dockerfile chama-se sempre Dockerfile e é colocado no mesmo diretório que o ficheiro app.yaml correspondente. No entanto, em alguns casos, o ambiente de ferramentas pode ter requisitos diferentes. Por exemplo, as ferramentas Java baseadas no Cloud SDK, como os plugins Maven, Gradle, Eclipse e IntelliJ, requerem que o Dockerfile esteja em src/main/docker/Dockerfile e que o ficheiro app.yaml esteja em src/main/appengine/app.yaml. Consulte a documentação do seu ambiente de ferramentas para mais informações.

Estrutura do código

Esta secção descreve o comportamento que o seu código tem de implementar, quer use uma imagem base fornecida pela Google ou a sua própria imagem base.

Ouvir a porta 8080

O front-end do App Engine encaminha os pedidos recebidos para o módulo adequado na porta 8080. Tem de se certificar de que o código da aplicação está a ouvir na porta 8080.

Processe eventos de ciclo de vida

O ambiente flexível envia periodicamente à sua aplicação determinados eventos do ciclo de vida.

Encerramento da aplicação

Quando uma instância tem de ser encerrada, os novos pedidos recebidos são encaminhados para outras instâncias (se existirem) e é dado tempo para a conclusão dos pedidos que estão a ser processados. Ao encerrar uma instância, o ambiente flexível envia normalmente um sinal STOP (SIGTERM) para o contentor da app. A sua app não tem de responder a este evento, mas pode usá-lo para realizar as ações de limpeza necessárias antes de o contentor ser encerrado. Em condições normais, o sistema aguarda até 30 segundos para que a app pare e, em seguida, envia um sinal KILL (SIGKILL), encerrando imediatamente a instância.

Em casos raros, as indisponibilidades podem impedir o App Engine de fornecer 30 segundos de tempo de encerramento, o que significa que os sinais STOP e KILL podem não ser enviados antes de uma instância terminar. Para lidar com esta possibilidade, deve verificar periodicamente o estado da sua instância, usando-a principalmente como uma cache na memória em vez de um armazenamento de dados fiável.

Pedidos de verificação de funcionamento

Pode usar pedidos de verificação do estado periódicos para confirmar que uma instância de VM foi implementada com êxito e para verificar se uma instância em execução mantém um estado normal.

Crie e implemente o seu tempo de execução personalizado

Depois de configurar o ficheiro app.yaml e DOCKER, pode criar e implementar essa imagem de contentor no App Engine.

Em alternativa, pode implementar imagens de contentores pré-criadas dos seus tempos de execução personalizados que estão armazenadas no Artifact Registry. Por exemplo, pode usar o Cloud Build para criar as suas imagens separadamente e, em seguida, armazená-las no Artifact Registry. Para mais informações, consulte o artigo Envie e extraia imagens.

Integre a sua aplicação com o Google Cloud

As aplicações executadas em tempos de execução personalizados podem usar as bibliotecas cliente do Google Cloud para aceder aos Google Cloud serviços. As aplicações em tempos de execução personalizados também podem usar qualquer serviço de terceiros através de APIs padrão.

Autentique com os serviços Google Cloud

As Credenciais padrão da aplicação oferecem a forma mais simples de autenticar e chamar APIs Google.

Se a sua aplicação usar o Cloud Build para compilar imagens do Docker, os anfitriões de rede cloudbuild alojam as Credenciais padrão da aplicação, o que permite que os serviços Google Cloud associados encontrem automaticamente as suas credenciais.

Para mais informações sobre a autenticação, consulte o artigo Autenticação na Google.

Registo

Quando um pedido é enviado para a sua aplicação em execução no App Engine, os detalhes do pedido e da resposta são registados automaticamente. Podem ser vistos no Google Cloud Explorador de registosda consola.

Quando a sua aplicação processa um pedido, também pode escrever as suas próprias mensagens de registo em stdout e stderr. Estes ficheiros são recolhidos automaticamente e podem ser vistos no Explorador de registos. Apenas as entradas mais recentes para stdout e stderr são retidas para limitar o respetivo tamanho.

Também pode escrever registos personalizados para /var/log/app_engine/custom_logs, usando um ficheiro que termine com .log ou .json.

Se incluir agentes de terceiros no contentor da aplicação, certifique-se de que configura os agentes para registarem dados em stdout e stderr ou num registo personalizado. Isto garante que quaisquer erros produzidos por estes agentes são visíveis no Cloud Logging.

Os registos de pedidos e aplicações da sua app são recolhidos por um agente do Cloud Logging e são mantidos durante um máximo de 90 dias, até um tamanho máximo de 1 GB. Se quiser armazenar os seus registos durante um período mais longo ou armazenar um tamanho superior a 1 GB, pode exportar os seus registos para o Cloud Storage. Também pode exportar os seus registos para o BigQuery e o Pub/Sub para processamento adicional.

Outros registos também estão disponíveis para utilização. Seguem-se alguns dos registos que estão configurados por predefinição:

Nome de registo Tipo de payload Finalidade
crash.log texto Informações registadas quando a configuração falha. Se a sua aplicação não for executada, verifique este registo.
monitoring.* texto Informações do contentor Docker que publica dados no Cloud Monitoring.
shutdown.log texto Informações registadas no encerramento.
stdout texto Saída padrão da sua app.
stderr texto Erro padrão do seu contentor.
syslog texto O syslog da VM, fora do contentor do Docker.