Crea 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. Consente inoltre di scrivere codice in qualsiasi altro linguaggio in grado di 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 che tu possa concentrarti sulla creazione della tua applicazione.

Per creare un runtime personalizzato, devi:

Fornisci un file app.yaml

Il file di configurazione di app.yaml deve contenere almeno le seguenti impostazioni:

runtime: custom
env: flex

Per informazioni sulle altre impostazioni che puoi impostare per l'app, vedi 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 sia che tu stia fornendo la tua immagine di base sia che 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 registri di container come DockerHub.

Individua il Dockerfile

In generale, il Dockerfile viene 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 all'ambiente degli strumenti utilizzato.

Struttura del codice

Questa sezione descrive il comportamento che il codice deve implementare se utilizzi un'immagine di base fornita da Google o la tua immagine di base.

Ascolta la porta 8080

Il frontend 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 all'applicazione determinati eventi del ciclo di vita.

Chiusura dell'applicazione

Quando un'istanza deve essere arrestata, le nuove richieste in entrata vengono instradate ad altre istanze (se presenti) e alle richieste in fase di elaborazione viene dato il tempo di essere completate. Quando arresta un'istanza, l'ambiente flessibile normalmente invia un indicatore STOP (SIGTERM) al container dell'app. La tua app non deve rispondere a questo evento, ma può utilizzarla 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, quindi invia un segnale KILL (SIGKILL), arrestando 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 controllare periodicamente lo stato dell'istanza, utilizzandola 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 verificare che un'istanza in esecuzione mantenga lo stato integro.

Crea ed esegui il deployment del tuo runtime personalizzato

Dopo aver configurato i file app.yaml e DOCKER, puoi creare ed eseguire il deployment dell'immagine del container in App Engine.

In alternativa, puoi eseguire il deployment di immagini container predefinite dei tuoi runtime personalizzati archiviate in Artifact Registry. Ad esempio, puoi utilizzare Cloud Build per creare separatamente le tue immagini e quindi archiviarle in Artifact Registry. Per ulteriori informazioni, consulta Immagini push e pull.

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 le API standard.

Autenticazione con i servizi Google Cloud

Le credenziali predefinite dell'applicazione offrono il modo più semplice per eseguire l'autenticazione 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 maggiori 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. Puoi visualizzarli in Esplora log della 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. Vengono conservate solo le voci più recenti per stdout e stderr 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 container dell'applicazione, assicurati di configurare gli agenti in modo che accedano a stdout e stderr o a un log personalizzato. Ciò garantisce che tutti gli errori prodotti da questi agenti siano 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 per una dimensione superiore a 1 GB, puoi esportare i log in Cloud Storage. Puoi anche esportare i log in BigQuery e Pub/Sub per ulteriori elaborazioni.

Sono disponibili anche altri log che puoi utilizzare. Di seguito sono riportati alcuni dei log configurati per impostazione predefinita:

Nome log Tipo di payload Finalità
crash.log testo Informazioni registrate in caso di errore di configurazione. Se l'esecuzione dell'applicazione non riesce, controlla questo log.
monitoring.* testo Informazioni provenienti dal container 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, esterno al container Docker.