Contrato de ambiente de execução do contêiner

Nesta página, listamos os principais requisitos e comportamentos de contêineres no Cloud Run.

Linguagens e imagens compatíveis

Sua imagem de contêiner pode executar o código escrito na linguagem de programação de sua escolha e usar qualquer imagem de base, desde que respeite as restrições listadas nesta página.

Os executáveis na imagem do contêiner precisam ser compilados para Linux de 64 bits. O Cloud Run é compatível especificamente com o formato ABI do Linux x86_64.

Como detectar solicitações na porta correta

O contêiner precisa detectar solicitações em 0.0.0.0 na porta para a qual as solicitações são enviadas. Por padrão, as solicitações são enviadas para 8080, mas é possível configurar o Cloud Run para enviar solicitações à porta de sua escolha.

Dentro das instâncias de contêiner do Cloud Run, o valor da variável de ambiente PORT sempre reflete a porta para a qual as solicitações são enviadas. O padrão é 8080.

Inicialização

As instâncias de contêiner precisam detectar solicitações em até quatro minutos depois de serem iniciadas.

Respostas

A instância do contêiner precisa enviar uma resposta dentro do tempo especificado na configuração de tempo limite da solicitação após receber uma solicitação, incluindo o tempo de inicialização da instância. Caso contrário, a solicitação é finalizada e um erro 504 é retornado.

Uma instância de contêiner será encerrada se retornar mais de 20 respostas sequenciais 5xx.

Variáveis de ambiente

As variáveis de ambiente a seguir são adicionadas automaticamente aos contêineres em execução:

Nome Descrição Exemplo
PORT A porta que o servidor HTTP deve detectar. 8080
K_SERVICE O nome do serviço do Cloud Run em execução. hello-world
K_REVISION O nome da revisão do Cloud Run em execução. hello-world.1
K_CONFIGURATION O nome da configuração do Cloud Run que criou a revisão. hello-world

Acesso ao sistema de arquivos

O sistema de arquivos do seu contêiner é gravável e está sujeito ao seguinte comportamento:

  • Esse é um sistema de arquivos na memória. Portanto, gravar nele usa a memória da instância do contêiner.
  • Os dados gravados no sistema de arquivos não permanecem quando a instância do contêiner é interrompida.

Considerações sobre o ciclo de vida da instância do contêiner

Em resposta a solicitações recebidas, cada revisão de um serviço é escalonada automaticamente para um determinado número de instâncias de contêiner, cada uma executando a imagem do contêiner implantada.

Quando uma revisão não recebe tráfego, ela é reduzida a zero instância de contêiner.

A computação tem um escopo delimitado a uma solicitação

Você só poderá realizar a computação dentro do escopo de uma solicitação: uma instância de contêiner não terá nenhuma CPU disponível se não estiver processando uma solicitação.

Serviços sem estado

Seu serviço precisa ser sem estado: não confie no estado de um serviço em todas as solicitações, porque uma instância de contêiner pode ser iniciada ou interrompida a qualquer momento.

Recursos da instância do contêiner

CPU

O Cloud Run aloca uma vCPU por instância de contêiner por padrão, mas isso pode ser alterado.

Uma vCPU é implementada como uma abstração do hardware subjacente para fornecer o tempo de CPU equivalente aproximado de um único hyper-thread de hardware em plataformas de CPU variáveis. A instância do contêiner pode ser executada em vários núcleos simultaneamente. A vCPU só é alocada durante a inicialização da instância do contêiner e o processamento da solicitação, mas ela é limitada.

Para alocar outro valor de vCPU, consulte a documentação para alocação de CPU.

Memória

Por padrão, cada instância de contêiner do Cloud Run recebe 256 MiB de memória. É possível alterar isso configurando limites de memória, até um máximo de 2 GiB.

Os usos típicos da memória incluem:

  • Código carregado na memória para executar o serviço
  • Gravação no sistema de arquivos
  • Processos extras em execução no contêiner, como um servidor nginx
  • Sistemas de armazenamento em cache na memória, como o OpCache do PHP
  • Uso da memória por solicitação

Simultaneidade

Por padrão, cada instância de contêiner do Cloud Run é definida como várias simultaneidades, em que cada instância de contêiner pode receber mais de uma solicitação ao mesmo tempo. Para alterar isso, defina a simultaneidade.

Sandbox de instâncias de contêiner

As instâncias de contêiner do Cloud Run (totalmente gerenciado) são colocadas no sandbox usando o sandbox do ambiente de execução do gVisor. Conforme documentado na referência de compatibilidade do syscall, algumas chamadas do sistema podem não ser compatíveis com esse sandbox de contêiner.

O Cloud Run para Anthos no Google Cloud não usa nenhum sandbox de contêiner.

Servidor de metadados da instância do contêiner

As instâncias de contêiner do Cloud Run expõem um servidor de metadados que pode ser usado para recuperar detalhes sobre sua instância de contêiner, como o ID do projeto, região, código da instância ou contas de serviço. Ele também pode ser usado para gerar tokens na conta de serviço do ambiente de execução.

É possível acessar esses dados a partir do servidor de metadados usando simples solicitações HTTP para o endpoint http://metadata.google.internal/ com o cabeçalho Metadata-Flavor: Google: nenhuma biblioteca de cliente é necessária. Para mais informações, consulte Como conseguir metadados.

A tabela a seguir lista algumas das informações disponíveis do servidor de metadados:

Caminho Descrição
/computeMetadata/v1/project/project-id ID do projeto deste serviço do Cloud Run
/computeMetadata/v1/instance/region Região deste serviço do Cloud Run
/computeMetadata/v1/instance/id Identificador exclusivo da instância do contêiner (também disponível em logs).
/computeMetadata/v1/instance/service-accounts/default/token Gera um token para a conta de serviço do ambiente de execução deste serviço do Cloud Run

O Cloud Run (totalmente gerenciado) não fornece detalhes sobre a zona do Google Cloud onde as instâncias de contêiner estão sendo executadas. Como consequência, o atributo de metadados /computeMetadata/v1/instance/zone sempre retorna projects/PROJECT-NUMBER/zones/REGION-1.