Ambiente di runtime Ruby

Il runtime Ruby consente di eseguire la tua app in App Engine in un ambiente sandbox. Questo documento illustra i dettagli dell'ambiente di runtime Ruby, incluse le intestazioni fornite al tuo codice e altre informazioni per eseguire correttamente il deployment dell'applicazione su App Engine.

Specifica il runtime Ruby per App Engine nell'ambiente standard nel file app.yaml:

runtime: rubyVERSION

Dove VERSION corrisponde ai numeri di versione Ruby MAJOR e MINOR. Ad esempio, per utilizzare l'ultima versione di Ruby, Ruby 3.2, specifica 32.

Per le altre versioni di Ruby supportate e la versione di Ubuntu corrispondente alla tua versione di Ruby, consulta la pianificazione del supporto dell'esecuzione.

Versione Ruby

Il runtime Ruby utilizza l'ultima release stabile della versione specificata nel file app.yaml. App Engine si aggiorna automaticamente alle nuove versioni di release delle patch, ma non alla versione secondaria.

Ad esempio, il deployment dell'applicazione potrebbe essere eseguito su Ruby 2.6.0 e poi essere aggiornato automaticamente alla versione 2.6.1 in un deployment successivo, ma non verrà aggiornato automaticamente a Ruby 2.7.

Dipendenze

Per saperne di più sulla dichiarazione e sulla gestione delle dipendenze, consulta Specifica delle dipendenze.

Avvio dell'applicazione

Il runtime avvia l'applicazione utilizzando il criterio entrypoint definito in app.yaml. Il punto di ingresso deve avviare un processo in risposta alle richieste HTTP sulla porta definita dalla variabile di ambiente PORT. Ad esempio:

entrypoint: bundle exec rails server -p $PORT

La maggior parte delle applicazioni web utilizza un server web supportato da Rack come Puma, Unicorn o Thin.

Devi aggiungere il server come dipendenza nel file di configurazione Gemfile dell'applicazione. Il runtime installerà tutte le dipendenze prima della chiamata del punto di ingresso.

source "https://rubygems.org"

gem "rack"
gem "puma"

Ecco un esempio di punto di ingresso in cui viene utilizzato puma per un'applicazione Rails:

entrypoint: bundle exec rails server Puma -p $PORT

Ecco un esempio di punto di ingresso in cui viene utilizzato puma per qualsiasi applicazione Rack:

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

Per le applicazioni in grado di gestire le richieste senza un server rack, è sufficiente eseguire uno script ruby:

entrypoint: bundle exec ruby app.rb

Variabili di ambiente

Le seguenti variabili di ambiente sono impostate dal runtime:

Variabile di ambiente Descrizione
GAE_APPLICATION L'ID della tua applicazione App Engine. Questo ID è preceduto dal prefisso "region code~", ad esempio "e~" per le applicazioni di cui è stato eseguito il deployment in Europa.
GAE_DEPLOYMENT_ID L'ID del deployment attuale.
GAE_ENV L'ambiente App Engine. Impostato su standard.
GAE_INSTANCE L'ID dell'istanza su cui è attualmente in esecuzione il servizio.
GAE_MEMORY_MB La quantità di memoria disponibile per il processo di applicazione, in MB.
GAE_RUNTIME Il runtime specificato nel file app.yaml.
GAE_SERVICE Il nome del servizio specificato nel file app.yaml. Se non viene specificato alcun nome del servizio, viene impostato su default.
GAE_VERSION L'etichetta della versione corrente del servizio.
GOOGLE_CLOUD_PROJECT L'ID progetto Google Cloud associato alla tua applicazione.
PORT La porta che riceve le richieste HTTP.
NODE_ENV (disponibile solo nel runtime Node.js) Imposta su production quando viene eseguito il deployment del servizio.

Puoi definire altre variabili di ambiente nel file app.yaml, ma i valori precedenti non possono essere sostituiti, ad eccezione di NODE_ENV.

HTTPS e proxy di inoltro

App Engine termina le connessioni HTTPS al bilanciatore del carico e inoltra le richieste alla tua applicazione. Alcune applicazioni devono determinare l'IP e il protocollo della richiesta originale. L'indirizzo IP dell'utente è disponibile nell'intestazione X-Forwarded-For standard. Le applicazioni che richiedono queste informazioni devono configurare il proprio framework web in modo da considerare attendibile il proxy.

Filesystem

Il runtime include una directory /tmp scrivibile, mentre tutte le altre directory hanno accesso di sola lettura. La scrittura in /tmp occupa memoria di sistema. Per saperne di più, consulta la documentazione di TempDir e TempFile.

Server metadati

Ogni istanza dell'applicazione può utilizzare il server metadati di App Engine per eseguire query sulle informazioni sull'istanza e sul progetto.

Puoi accedere al server metadati tramite i seguenti endpoint:

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

Le richieste inviate al server dei metadati devono includere l'intestazione della richiesta Metadata-Flavor: Google. Questa intestazione indica che la richiesta è stata inviata con l'intento di recuperare i valori dei metadati.

Nella tabella seguente sono elencati gli endpoint in cui è possibile effettuare richieste HTTP per metadati specifici:

Endpoint dei metadati Descrizione
/computeMetadata/v1/project/numeric-project-id Il numero di progetto assegnato al progetto.
/computeMetadata/v1/project/project-id L'ID progetto assegnato al progetto.
/computeMetadata/v1/instance/region La regione in cui è in esecuzione l'istanza.
/computeMetadata/v1/instance/service-accounts/default/aliases
/computeMetadata/v1/instance/service-accounts/default/email L'indirizzo email dell'account di servizio predefinito assegnato al progetto.
/computeMetadata/v1/instance/service-accounts/default/ Elenca tutti gli account di servizio predefiniti per il tuo progetto.
/computeMetadata/v1/instance/service-accounts/default/scopes Elenca tutti gli ambiti supportati per gli account di servizio predefiniti.
/computeMetadata/v1/instance/service-accounts/default/token Restituisce il token di autenticazione che può essere utilizzato per autenticare l'applicazione su altre API Google Cloud.

Ad esempio, per recuperare il tuo ID progetto, invia una richiesta a http://metadata.google.internal/computeMetadata/v1/project/project-id.