Un runtime personalizzato consente di utilizzare un'implementazione alternativa di qualsiasi linguaggio di ambiente flessibile supportato o di personalizzare uno fornito da Google. Ti permette inoltre di scrivere codice in qualsiasi altro linguaggio può gestire le richieste HTTP in entrata (esempio). Con un runtime personalizzato, l'ambiente flessibile fornisce e la tua infrastruttura di scalabilità, monitoraggio e bilanciamento del carico per te, puoi concentrarti sulla creazione della tua applicazione.
Per creare un runtime personalizzato, devi:
- Fornisci ad App Engine un file
app.yaml
che descriva la configurazione di runtime della tua applicazione. - Aggiungi un
Dockerfile
che configuri internamente l'ambiente di runtime. - Assicurati che il codice rispetti alcune regole di base.
Fornisci un file app.yaml
Il file di configurazione di app.yaml
deve contenere almeno le seguenti impostazioni:
runtime: custom
env: flex
Per informazioni su cosa altro puoi impostare per la tua app, consulta Configurare l'app con app.yaml.
Crea un Dockerfile
La documentazione completa sulla creazione di Dockerfile è disponibile sul sito web di Docker. Se utilizzi un runtime personalizzato, devi fornire un Dockerfile, indipendentemente dal fatto che fornisca la tua immagine di base o utilizzi una delle immagini di base di Google.
Specifica un'immagine di base
In genere il primo comando in un Dockerfile è un comando FROM
che specifica un'immagine di base.
Un'immagine di base viene utilizzata per creare il container e l'applicazione. Puoi creare la tua immagine di base o selezionarne una da registry dei container come Docker Hub.
Individua il Dockerfile
In generale, il Dockerfile viene sempre denominato Dockerfile
e viene inserito nel
della stessa directory del file app.yaml
corrispondente. In alcuni casi, tuttavia,
potrebbe avere requisiti diversi. Ad esempio, gli strumenti Java basati su Cloud SDK, come i plug-in Maven, Gradle, Eclipse e IntelliJ, richiedono che Dockerfile
si trovi in src/main/docker/Dockerfile
e che il file app.yaml
si trovi in src/main/appengine/app.yaml
. Per ulteriori informazioni, consulta la documentazione relativa al tuo ambiente di strumenti.
Struttura del codice
Questa sezione descrive il comportamento che il codice deve implementare indipendentemente dall'utilizzo di un'immagine di base fornita da Google o di un'immagine di base personalizzata.
Ascolta la porta 8080
Il front-end di App Engine indirizzerà le richieste in entrata al modulo appropriato sulla porta 8080. Devi assicurarti che il codice dell'applicazione sia in ascolto sulla porta 8080.
Gestire gli eventi del ciclo di vita
L'ambiente flessibile invia periodicamente la tua applicazione di determinati eventi del ciclo di vita.
Arresto dell'applicazione
Quando un'istanza deve essere arrestata, le nuove richieste in entrata vengono inoltrate ad altre istanze (se presenti) e alle richieste in fase di elaborazione viene dato il tempo di essere completate. Quando arresti un'istanza, l'ambiente flessibile in genere invia un segnale STOP
(SIGTERM
) al contenitore dell'app. L'app non deve rispondere a questo evento, ma può utilizzarlo per eseguire le azioni di pulizia necessarie prima dell'arresto del contenitore. In condizioni normali, il sistema
attende fino a 30 secondi per l'interruzione dell'app, quindi invia un KILL
(SIGKILL
)
arrestando immediatamente l'istanza.
In rari casi, le interruzioni possono impedire ad App Engine di fornire 30 secondi
di tempo di chiusura, il che significa che gli indicatori STOP
e KILL
potrebbero non essere inviati
prima della fine di un'istanza. Per gestire questa possibilità, devi eseguire periodicamente il checkpoint dello stato dell'istanza, utilizzandola principalmente come cache in-memory anziché come un data store affidabile.
Richieste di controllo di integrità
Puoi utilizzare l'opzione Richieste di controllo di integrità per verificare l'avvenuto deployment di un'istanza VM e per verificare un'istanza in esecuzione mantiene uno stato integro.
Crea ed esegui il deployment del tuo runtime personalizzato
Dopo aver configurato i file app.yaml
e DOCKER
, puoi
creare e implementare
l'immagine del contenitore in App Engine.
In alternativa, puoi eseguire il deployment di immagini container precompilate delle tue runtime personalizzate archiviate in Artifact Registry. Ad esempio, puoi utilizzare Cloud Build per creare le immagini separatamente e poi archiviarle in Artifact Registry. Per ulteriori informazioni, consulta Eseguire il push e il pull delle immagini.
Integra la tua applicazione con Google Cloud
Le applicazioni in esecuzione in runtime personalizzati possono utilizzare Google Cloud Librerie client per accedere ai servizi Google Cloud. Le applicazioni in runtime personalizzati possono inoltre utilizzare qualsiasi servizio di terze parti che impiega le API standard.
Autenticazione con i servizi Google Cloud
Le credenziali predefinite dell'applicazione offrono il modo più semplice per autenticarsi e chiamare le API di Google.
Se la tua applicazione utilizza Cloud Build per compilare le immagini Docker,
la rete cloudbuild
ospita
Credenziali predefinite dell'applicazione che abilitano i servizi Google Cloud associati per
a trovare automaticamente le tue credenziali.
Per ulteriori informazioni sull'autenticazione, consulta Autenticazione su Google.
Logging
Quando viene inviata una richiesta alla tua applicazione in esecuzione in App Engine, i dettagli della richiesta e della risposta vengono registrati automaticamente. Possono essere visualizzate in Esplora log della console Google Cloud.
Quando l'applicazione gestisce una richiesta, può anche scrivere i propri messaggi di log in stdout
e stderr
. Questi file sono
raccolti automaticamente e possono essere visualizzati in Esplora log. Solo il
le voci più recenti per stdout
e stderr
vengono conservate, in ordine
per limitarne le dimensioni.
Puoi anche scrivere log personalizzati in /var/log/app_engine/custom_logs
utilizzando un file che termina con .log
o .json
.
Se includi agenti di terze parti nel contenitore dell'applicazione, assicurati di configurarli in modo che registrino in stdout
e stderr
o in un log personalizzato.
In questo modo, tutti gli errori prodotti da questi agenti sono visibili in Cloud Logging.
I log delle richieste e delle applicazioni per la tua app vengono raccolti da un agente Cloud Logging e vengono conservati per un massimo di 90 giorni, fino a una dimensione massima di 1 GB. Se vuoi archiviare i log per un periodo più lungo o archiviare file di dimensioni superiori a 1 GB, puoi esportarli in Cloud Storage. Puoi anche esportare i log in BigQuery e Pub/Sub per per ulteriore elaborazione.
Sono disponibili anche altri log che puoi utilizzare. Di seguito sono riportati alcuni dei log che sono configurati per impostazione predefinita:
Nome log | Tipo di payload | Finalità |
---|---|---|
crash.log |
testo | Informazioni registrate quando la configurazione non va a buon fine. Se l'applicazione non viene eseguita, controlla questo log. |
monitoring.* |
testo | Informazioni del contenitore Docker che pubblica i dati in Cloud Monitoring. |
shutdown.log |
testo | Informazioni registrate all'arresto. |
stdout |
testo | Output standard della tua app. |
stderr |
testo | Errore standard del container. |
syslog |
testo | Il syslog della VM, al di fuori del container Docker. |