Ambiente de execução do Ruby

O ambiente de execução do Ruby permite executar o aplicativo no App Engine em um ambiente de sandbox. Neste documento, explicamos detalhes do ambiente de execução do Ruby, incluindo os cabeçalhos que são fornecidos para o código e outras informações para implantar com êxito o aplicativo no App Engine.

Especifique o ambiente de execução do Ruby para o App Engine no ambiente padrão no arquivo app.yaml como:

runtime: rubyVERSION

Em que VERSION são os números de versão do Ruby MAJOR e MINOR. Por exemplo: para usar a versão mais recente do Ruby, Ruby 3.3 (prévia), especifique 33:

Para outras versões compatíveis do Ruby e a versão do Ubuntu correspondente à sua versão do Ruby, consulte a Programação de suporte do ambiente de execução.

Versão do Ruby

O ambiente de execução usa a versão estável mais recente da versão especificada em seu arquivo app.yaml. O App Engine é atualizado automaticamente para novas versões de patch, mas não atualiza automaticamente a versão secundária.

Por exemplo, o aplicativo pode ser implantado no Ruby 2.6.0 e atualizado automaticamente para a versão 2.6.1 em uma implantação posterior, mas não será atualizado automaticamente para o Ruby 2.7.

Dependências

Para conferir mais informações sobre como declarar e gerenciar dependências, consulte Como especificar dependências.

Inicialização do aplicativo

O ambiente de execução inicia seu aplicativo usando o entrypoint definido em app.yaml. O entrypoint deve iniciar um processo que responde a solicitações HTTP na porta definida pela variável de ambiente PORT. Por exemplo:

entrypoint: bundle exec rails server -p $PORT

A maioria dos aplicativos da Web usa um servidor compatível com Rack, como Puma, Unicorn ou Thin.

É preciso adicionar o servidor como uma dependência no arquivo de configuração Gemfile de seu aplicativo. O ambiente de execução instalará todas as dependências antes que o ponto de entrada seja chamado.

source "https://rubygems.org"

gem "rack"
gem "puma"

Um exemplo de entrypoint que usa puma para um aplicativo do Rails:

entrypoint: bundle exec rails server Puma -p $PORT

Um exemplo de entrypoint que usa puma para um aplicativo do Rack:

entrypoint: bundle exec rackup -s Puma -p $PORT

No caso de aplicativos capazes de processar solicitações sem um servidor Rack, basta executar um script ruby:

entrypoint: bundle exec ruby app.rb

Variáveis de ambiente

As seguintes variáveis de ambiente são definidas pelo ambiente de execução:

Variável de ambiente	Descrição
`GAE_APPLICATION`	O ID do aplicativo do App Engine. Esse ID tem o prefixo "`region code`~", como "e~" para aplicativos implantados na Europa.
`GAE_DEPLOYMENT_ID`	O ID da implantação atual.
`GAE_ENV`	O ambiente do App Engine. Defina como `standard`.
`GAE_INSTANCE`	O ID da instância em que o serviço é executado no momento.
`GAE_MEMORY_MB`	A quantidade de memória disponível para o processo do aplicativo em MB.
`GAE_RUNTIME`	O ambiente de execução especificado no seu arquivo `app.yaml`.
`GAE_SERVICE`	O nome do serviço especificado no seu arquivo `app.yaml`. Se nenhum nome de serviço for especificado, ele será definido como `default`.
`GAE_VERSION`	O rótulo da versão atual do serviço.
`GOOGLE_CLOUD_PROJECT`	O ID do projeto do Google Cloud associado ao aplicativo.
`PORT`	A porta que recebe solicitações HTTP.
`NODE_ENV` (disponível apenas no ambiente de execução do Node.js)	Definido como `production` quando o serviço for implantado.

É possível definir outras variáveis de ambiente no arquivo app.yaml, mas os valores acima não podem ser modificados, exceto para NODE_ENV.

HTTPS e proxies de encaminhamento

O App Engine encerra as conexões HTTPS no balanceador de carga e encaminha as solicitações para o aplicativo. Em alguns aplicativos, é necessário determinar o protocolo e o IP de solicitação originais. O endereço IP do usuário está disponível no cabeçalho X-Forwarded-For padrão. Os aplicativos que necessitam dessa informação precisam configurar a biblioteca da Web para confiar no proxy.

Sistema de arquivos

O ambiente de execução inclui um diretório /tmp gravável, e todos os outros diretórios têm acesso somente de leitura. A gravação em /tmp ocupa a memória do sistema. Para obter mais informações, consulte as documentações TempDir e TempFile.

Servidor de metadados

Cada instância do aplicativo pode usar o servidor de metadados do App Engine para consultar informações sobre a instância e o projeto.

É possível acessar o servidor de metadados por meio dos endpoints a seguir:

http://metadata
http://metadata.google.internal

As solicitações enviadas ao servidor de metadados precisam incluir o cabeçalho da solicitação Metadata-Flavor: Google. Esse cabeçalho indica que a solicitação foi enviada para recuperar valores de metadados.

A tabela a seguir lista os endpoints em que é possível fazer solicitações HTTP para metadados específicos.

Endpoint de metadados	Descrição
`/computeMetadata/v1/project/numeric-project-id`	Número do projeto atribuído ao seu projeto.
`/computeMetadata/v1/project/project-id`	ID do projeto atribuído ao seu projeto.
`/computeMetadata/v1/instance/region`	A região em que a instância está em execução.
`/computeMetadata/v1/instance/service-accounts/default/aliases`
`/computeMetadata/v1/instance/service-accounts/default/email`	E-mail da conta de serviço padrão atribuído ao seu projeto.
`/computeMetadata/v1/instance/service-accounts/default/`	Lista todas as contas de serviço padrão do seu projeto.
`/computeMetadata/v1/instance/service-accounts/default/scopes`	Lista todos os escopos compatíveis com as contas de serviço padrão.
`/computeMetadata/v1/instance/service-accounts/default/token`	Retorna o token de autenticação que pode ser usado para autenticar o aplicativo em outras Google Cloud APIs.

Por exemplo, para recuperar o ID do projeto, envie uma solicitação para http://metadata.google.internal/computeMetadata/v1/project/project-id.