Crea runtime personalizzati

Un runtime personalizzato consente di utilizzare un'implementazione alternativa di qualsiasi linguaggio dell'ambiente flessibile supportato o di personalizzare un linguaggio fornito da Google. Ti consente inoltre di scrivere codice in qualsiasi altro linguaggio in grado di gestire le richieste HTTP in entrata (esempio). Grazie a un runtime personalizzato, l'ambiente flessibile fornisce e gestisce l'infrastruttura di scalabilità, monitoraggio e bilanciamento del carico, così puoi concentrarti 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 sugli altri elementi che puoi impostare per la tua app, consulta Configurazione dell'app con app.yaml.

Crea un Dockerfile

Una documentazione completa sulla creazione di Dockerfile è disponibile sul sito web di Docker. Se utilizzi un runtime personalizzato, devi fornire un Dockerfile sia che tu stia fornendo la tua immagine di base o una delle immagini di base di Google.

Specifica un'immagine di base

Il primo comando in un Dockerfile di solito è un comando FROM che specifica un'immagine di base. Per creare il container e creare l'applicazione viene utilizzata un'immagine di base. Puoi creare la tua immagine di base o selezionare un'immagine di base dai registri di container come DockerHub.

Individuare il Dockerfile

In generale, il Dockerfile è sempre denominato Dockerfile e si trova nella stessa directory del file app.yaml corrispondente. In alcuni casi, tuttavia, l'ambiente degli 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 sia in src/main/docker/Dockerfile e il file app.yaml sia 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 tuo codice deve implementare, indipendentemente dal fatto che utilizzi un'immagine di base fornita da Google o la tua immagine di base.

Ascolta sulla porta 8080

Il front-end di App Engine instrada le richieste in entrata al modulo appropriato sulla porta 8080. Devi assicurarti che il codice dell'applicazione sia in ascolto su 8080.

Gestire gli eventi del ciclo di vita

L'ambiente flessibile invia periodicamente eventi del ciclo di vita dell'applicazione.

Arresto dell'applicazione

Quando un'istanza deve essere arrestata, le nuove richieste in entrata vengono instradate ad altre istanze (se presenti) e le richieste attualmente in fase di elaborazione vengono date il tempo di essere completate. Quando arresta un'istanza, l'ambiente flessibile invia normalmente un segnale STOP (SIGTERM) al container dell'app. L'app non deve rispondere a questo evento, ma può utilizzarlo per eseguire le azioni di pulizia necessarie prima dell'arresto del container. In condizioni normali, il sistema attende fino a 30 secondi per l'arresto dell'app e poi invia un segnale KILL (SIGKILL), arrestando immediatamente l'istanza.

In rari casi, le interruzioni possono impedire ad App Engine di fornire un tempo di arresto di 30 secondi, il che significa che gli indicatori STOP e KILL potrebbero non essere inviati prima della terminazione di un'istanza. Per gestire questa possibilità, devi controllare periodicamente lo stato dell'istanza, utilizzandolo principalmente come cache in memoria anziché come datastore affidabile.

Richieste di controllo di integrità

Puoi utilizzare richieste di controllo di integrità periodiche per confermare che il deployment di un'istanza VM sia stato eseguito correttamente e per controllare che un'istanza in esecuzione mantenga uno stato integro.

Crea ed esegui il deployment del runtime personalizzato

Dopo aver configurato i file app.yaml e DOCKER, puoi creare l'immagine container e eseguirne il deployment in App Engine.

In alternativa, puoi eseguire il deployment delle immagini container predefinite dei runtime personalizzati archiviati in Artifact Registry. Ad esempio, puoi utilizzare Cloud Build per creare separatamente le immagini e archiviarle in Artifact Registry. Per maggiori 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 le librerie client di Google Cloud per accedere ai servizi Google Cloud. Le applicazioni in runtime personalizzati possono inoltre utilizzare qualsiasi servizio di terze parti che impiega API standard.

Autenticazione con i servizi Google Cloud

Le credenziali predefinite dell'applicazione offrono il modo più semplice per autenticarsi con le API di Google e chiamarle.

Se la tua applicazione utilizza Cloud Build per compilare le immagini Docker, la rete cloudbuild ospita le Credenziali predefinite dell'applicazione consentendo ai servizi Google Cloud associati di trovare automaticamente le tue credenziali.

Per ulteriori informazioni sull'autenticazione, consulta la sezione Autenticazione a 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 nella console Google Cloud.

Quando l'applicazione gestisce una richiesta, può anche scrivere i propri messaggi di logging in stdout e stderr. Questi file vengono raccolti automaticamente e possono essere visualizzati in Esplora log. Per limitarne le dimensioni, vengono conservate solo le voci più recenti relative a 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 container dell'applicazione, assicurati di configurare gli agenti in modo che accedano a stdout e stderr o a un log personalizzato. In questo modo, gli eventuali errori generati da questi agenti saranno 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 una dimensione superiore a 1 GB, puoi esportarli in Cloud Storage. Puoi anche esportare i log in BigQuery e Pub/Sub per ulteriore elaborazione.

Sono disponibili anche altri log. Di seguito sono riportati alcuni log 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'esecuzione dell'applicazione non riesce, controlla questo log.
monitoring.* testo Informazioni dal container Docker che pubblicano dati su Cloud Monitoring.
shutdown.log testo Informazioni registrate all'arresto.
stdout testo Output standard della tua app.
stderr testo Errore standard dal container.
syslog testo Il syslog della VM all'esterno del container Docker.