Creare runtime personalizzati

Un runtime personalizzato consente di utilizzare un'implementazione alternativa di qualsiasi linguaggio di ambiente flessibile supportato o di personalizzare uno fornito da Google. Inoltre, ti consente di scrivere codice in qualsiasi altro linguaggio che possa gestire le richieste HTTP in entrata (esempio). Con un runtime personalizzato, l'ambiente flessibile fornisce e gestisce l'infrastruttura di scalabilità, monitoraggio e bilanciamento del carico per te, in modo da poterti concentrare sulla creazione della tua applicazione.

Per creare un runtime personalizzato, devi:

Fornisci un file app.yaml

Il file di configurazione 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

Il primo comando in un Dockerfile è in genere un comando FROM che specifica un'immagine di base. Un'immagine di base viene utilizzata per creare il container e compilare l'applicazione. Puoi creare la tua immagine di base o selezionarne una da registry dei container come DockerHub.

Individua il Dockerfile

In genere, il file Dockerfile si chiama sempre Dockerfile e si trova nella stessa directory del file app.yaml corrispondente. In alcuni casi, tuttavia, l'ambiente di strumenti 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 alla tua applicazione 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 aspetta fino a 30 secondi che l'app si arresti, quindi invia un segnale KILL (SIGKILL) e arresta immediatamente l'istanza.

In rari casi, le interruzioni possono impedire ad App Engine di fornire 30 secondi di tempo di arresto, il che significa che gli indicatori STOP e KILL potrebbero non essere inviati prima dell'interruzione 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 datastore affidabile.

Richieste di controllo di integrità

Puoi utilizzare periodicamente richieste di controllo di integrità per confermare che un'istanza VM è stata dispiata correttamente e per verificare che un'istanza in esecuzione mantenga uno stato di integrità.

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 dei tuoi runtime personalizzati archiviati 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.

Integrare l'applicazione con Google Cloud

Le applicazioni in esecuzione in ambienti di runtime personalizzati possono utilizzare le librerie client Google Cloud per accedere ai servizi Google Cloud. Le applicazioni nei runtime personalizzati possono utilizzare anche qualsiasi servizio di terze parti che utilizza API standard.

Eseguire l'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 le Credenziali predefinite dell'applicazione che consentono ai servizi Google Cloud associati di trovare automaticamente le tue credenziali.

Per ulteriori informazioni sull'autenticazione, consulta Autenticazione su Google.

Logging

Quando viene inviata una richiesta all'applicazione in esecuzione in App Engine, i dettagli della richiesta e della risposta vengono registrati automaticamente. Possono essere visualizzati 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 vengono raccolti automaticamente e possono essere visualizzati in Esplora log. Per limitare le dimensioni, vengono conservate solo le voci più recenti di stdout e stderr.

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 un'ulteriore elaborazione.

Sono disponibili anche altri log. 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 dell'app.
stderr testo Errore standard del container.
syslog testo Il syslog della VM, al di fuori del container Docker.