Il runtime Ruby ti 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 è il numero di versione di Ruby MAJOR e MINOR. Ad esempio, per utilizzare la versione più recente di Ruby, Ruby 3.4, specifica 34.
Per altre versioni di Ruby supportate e la versione di Ubuntu corrispondente alla tua versione di Ruby, consulta la pianificazione del supporto del runtime.
Versione Ruby
L'ultima versione di Ruby supportata è 3.4. Il runtime Ruby utilizza la release stabile più recente della versione specificata nel file app.yaml. App Engine si aggiorna automaticamente alle nuove versioni delle release delle patch, ma non aggiorna automaticamente la versione minore.
Ad esempio, l'applicazione potrebbe essere dipiattaforma 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 su come dichiarare e gestire le dipendenze, consulta Specificare le dipendenze.
Avvio dell'applicazione
Il runtime avvia l'applicazione utilizzando il entrypoint definito in
app.yaml. Il punto di contatto 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
della tua applicazione. Il runtime installerà tutte le dipendenze prima che venga chiamato il punto di contatto.
source "https://rubygems.org"
gem "rack"
gem "puma"
Un esempio di punto di contatto 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 che possono gestire le richieste senza un server Rack, puoi semplicemente eseguire uno script Ruby:
entrypoint: bundle exec ruby app.rb
Variabili di ambiente
Le seguenti variabili di ambiente vengono impostate dal runtime:
| Variabile di ambiente | Descrizione |
|---|---|
GAE_APPLICATION
|
L'ID della tua applicazione App Engine. Questo ID è preceduto da "region code~", ad esempio "e~" per le applicazioni di cui è stato eseguito il deployment in Europa. |
GAE_DEPLOYMENT_ID |
L'ID del deployment corrente. |
GAE_ENV |
L'ambiente App Engine. Imposta 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 di servizio, viene impostato su default. |
GAE_VERSION |
L'etichetta della versione corrente del servizio. |
GOOGLE_CLOUD_PROJECT |
L' Google Cloud ID progetto associato alla tua applicazione. |
PORT |
La porta che riceve le richieste HTTP. |
NODE_ENV (disponibile solo nel runtime di Node.js) |
Imposta su production quando il servizio viene disegnato. |
Puoi
definire variabili di ambiente aggiuntive nel file app.yaml,
ma i valori sopra indicati non possono essere sostituiti, tranne per NODE_ENV.
Proxy HTTPS e 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 framework web in modo che attenda il proxy.
Filesystem
Il runtime include una directory /tmp scrivibile, con tutte le altre directory che hanno accesso di sola lettura. La scrittura in /tmp occupa memoria di sistema. Per ulteriori informazioni, consulta la documentazione di TempDir e TempFile.
Server dei 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 dei metadati tramite i seguenti endpoint:
http://metadatahttp://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'intenzione di recuperare i valori dei metadati.
La tabella seguente elenca gli endpoint in cui puoi inviare 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 progetto. |
/computeMetadata/v1/instance/service-accounts/default/scopes |
Elenca tutti gli ambiti supportati per i service account predefiniti. |
/computeMetadata/v1/instance/service-accounts/default/token |
Restituisce il token di autenticazione che può essere utilizzato per autenticare la tua applicazione ad altre API Google Cloud. |
Ad esempio, per recuperare l'ID progetto, invia una richiesta a
http://metadata.google.internal/computeMetadata/v1/project/project-id.