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 é o número da versão do Ruby MAJOR MINOR. Por exemplo, o Ruby 3.2 usa 32.

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

Observação: o comando entrypoint será executado pela função exec do bash. Variáveis do shell como $PORT serão substituídas normalmente, mas a sintaxe do shell como if, for e while incorporada no comando entrypoint não funcionará.

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.

Observação: não há suporte para metadados personalizados no ambiente padrão.

É 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.