Il runtime Ruby consente di eseguire l'app in App Engine in un ambiente sandbox. Questo documento illustra i dettagli dell'ambiente di runtime Ruby, tra cui le intestazioni fornite al 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 indica i numeri di versione Ruby MAJOR
e MINOR
. Ad esempio, per utilizzare l'ultima versione di Ruby, Ruby 3.3 (anteprima), specifica 33
.
Per altre versioni di Ruby supportate e la versione Ubuntu corrispondente per la tua versione Ruby, consulta la pianificazione del supporto del runtime.
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 delle patch, ma non aggiorna automaticamente la
versione secondaria.
Ad esempio, il deployment dell'applicazione potrebbe essere eseguito su Ruby 2.6.0 e aggiornata automaticamente alla versione 2.6.1 in un deployment successivo, ma non verrà aggiornata automaticamente a Ruby 2.7.
Dipendenze
Per ulteriori informazioni sulla dichiarazione e la gestione delle dipendenze, consulta Specifica delle dipendenze.
Avvio dell'applicazione
Il runtime avvia l'applicazione utilizzando il entrypoint
definito in
app.yaml
. Il punto di ingresso deve avviare un processo che
risponde 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"
Un esempio di punto di ingresso che utilizza puma per un'applicazione Rails:
entrypoint: bundle exec rails server Puma -p $PORT
Un esempio di punto di ingresso che utilizza 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. Impostata 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 richiesta, in MB. |
GAE_RUNTIME |
Il tempo di esecuzione specificato nel file app.yaml . |
GAE_SERVICE |
Il nome del servizio specificato nel file app.yaml . Se non viene specificato alcun nome di 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 variabili di ambiente aggiuntive nel file app.yaml
,
ma i valori precedenti non possono essere sostituiti, ad eccezione di NODE_ENV
.
Proxy HTTPS e di forwarding
App Engine termina le connessioni HTTPS a livello di bilanciatore del carico e inoltra le richieste all'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 per considerare attendibile il proxy.
File system
Il runtime include una directory /tmp
accessibile in scrittura, con tutte le altre directory che dispongono dell'accesso di sola lettura. La scrittura su /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 di metadati di App Engine per eseguire query sulle informazioni sull'istanza e sul progetto.
Puoi accedere al server di 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.
La tabella seguente elenca gli endpoint in cui è possibile effettuare richieste HTTP per metadati specifici:
Endpoint metadati | Descrizione |
---|---|
/computeMetadata/v1/project/numeric-project-id |
Il numero del progetto assegnato al tuo 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 in altre API Google Cloud. |
Ad esempio, per recuperare l'ID progetto, invia una richiesta a http://metadata.google.internal/computeMetadata/v1/project/project-id
.