Confronta App Engine e Cloud Run

Questa guida fornisce un'introduzione a Cloud Run per chi conosce App Engine. Descrive le principali somiglianze e differenze tra le piattaforme serverless per preparare la migrazione dall'ambiente standard di App Engine o dall'ambiente flessibile di App Engine.

Panoramica

Cloud Run è l'ultima evoluzione di Google Cloud Serverless, basato sull'esperienza di esecuzione di App Engine da oltre un decennio. Cloud Run viene eseguito su gran parte della stessa infrastruttura dell'ambiente standard di App Engine, quindi ci sono molte somiglianze tra queste due piattaforme.

Cloud Run è progettato per migliorare l'esperienza di App Engine, incorporando molte delle migliori funzionalità sia dell'ambiente standard di App Engine sia dell'ambiente flessibile di App Engine. I servizi Cloud Run sono in grado di gestire gli stessi carichi di lavoro dei servizi App Engine, ma Cloud Run offre ai clienti molta più flessibilità nell'implementazione di questi servizi. Questa flessibilità, insieme a integrazioni migliorate con servizi sia di Google Cloud che di terze parti, consente anche a Cloud Run di gestire i carichi di lavoro che non possono essere eseguiti su App Engine.

Riepilogo confronto

Sebbene esistano molte somiglianze e differenze tra App Engine e Cloud Run, questa panoramica si concentra sulle aree più importanti per i clienti di App Engine che iniziano a utilizzare Cloud Run.

Modello di risorsa

Il modello di risorse Cloud Run è molto simile ad App Engine, ma con alcune differenze fondamentali:

• Cloud Run non dispone di una risorsa Applicazione di primo livello o del servizio default corrispondente.
• È possibile eseguire il deployment dei servizi Cloud Run nello stesso progetto in regioni diverse. In App Engine, tutti i servizi nel progetto si trovano nella stessa regione.
• Cloud Run usa il termine Revisione, anziché Versione, per allinearsi al modello di risorsa Knative.
• I nomi delle revisioni di Cloud Run utilizzano il formato SERVICE_NAME-REVISION_SUFFIX, dove REVISION_SUFFIX viene generato automaticamente oppure impostato utilizzando il flag di deployment --revision-suffix=REVISION_SUFFIX.
• Le revisioni di Cloud Run sono immutabili, il che significa che non puoi riutilizzare nomi come accade con le versioni App Engine (con il flag di deployment --version=VERSION_ID).
• Gli URL del servizio Cloud Run si basano su un identificatore di servizio che viene generato automaticamente al primo deployment del servizio. Gli identificatori di servizio utilizzano il formato: SERVICE_NAME-<auto-generated identifier>. L'identificatore del servizio è univoco e non cambia per tutta la durata del servizio.
• In Cloud Run, per impostazione predefinita sono esposti solo gli URL di servizio (SERVICE_IDENTIFIER.run.app e https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app). Per gestire una revisione specifica, devi configurare un tag di traffico. In App Engine, gli URL di servizio e di versione vengono esposti automaticamente.

Deployment e configurazione

In App Engine, la maggior parte della configurazione viene eseguita in app.yaml incluso in ogni deployment. Questa semplicità ha un costo in quanto, sebbene alcune impostazioni possano essere aggiornate utilizzando l'API Admin, per la maggior parte delle modifiche è necessario eseguire nuovamente il deployment del servizio.

Cloud Run dispone del file di configurazione service.yaml, ma non viene utilizzato come app.yaml. Impossibile utilizzare Cloud Run service.yaml durante il deployment dall'origine, poiché uno degli elementi obbligatori è il percorso dell'immagine container finale. Inoltre, service.yaml è conforme alle specifiche Knative e può essere difficile da leggere per chi non ha familiarità con i file di configurazione in stile Kubernetes. Per ulteriori informazioni sull'utilizzo di service.yaml per gestire la configurazione, consulta la documentazione di Cloud Run.

Per i clienti di App Engine che iniziano a utilizzare Cloud Run, l'uso dei flag di deployment della gcloud CLI allinea molto più strettamente alla gestione della configurazione al momento del deployment di App Engine.

Per impostare la configurazione quando esegui il deployment di nuovo codice in Cloud Run, utilizza i flag gcloud run deploy:

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Sebbene non sia necessario utilizzare i flag di configurazione con ogni deployment (vedi Gestione delle configurazioni), puoi farlo per semplificare la gestione delle configurazioni.

In Cloud Run, puoi anche aggiornare la configurazione senza eseguire nuovamente il deployment del codice sorgente utilizzando gcloud run services update:

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Poiché le revisioni di Cloud Run sono immutabili, questo comando creerà una nuova revisione con la configurazione aggiornata, ma utilizzerà la stessa immagine container della revisione esistente.

Gestione delle configurazioni

Per i deployment di App Engine, devono essere fornite tutte le impostazioni per ogni deployment e a quelle non fornite devono essere assegnati valori predefiniti. Ad esempio, prendi in considerazione App Engine service-a, con versioni che utilizzano i file app.yaml mostrati di seguito:

runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a

runtime: python39
service: service-a
instance_class: F4
default values:
..
..

runtime: python39
service: service-a
default values:
instance_class: F1
..
..

version1 è configurato con instance_class: F4, mentre version2, che non ha fornito alcun valore per instance_class, è configurato con il valore predefinito instance_class: F1.

Per Cloud Run vengono applicate tutte le impostazioni di configurazione fornite, ma quelle non fornite conservano i valori esistenti. Devi specificare solo i valori per le impostazioni che vuoi modificare. Ad esempio:

gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a

service: service-a
vCPUs: 4
default values:
..
..

service: service-a
vCPUs: 4
default values:
..
..

In App Engine, il deployment senza impostazioni di configurazione crea una versione che utilizza tutte le impostazioni predefinite. In Cloud Run, il deployment senza impostazioni di configurazione crea una revisione utilizzando le stesse impostazioni di configurazione della revisione precedente. Per la prima revisione di un servizio Cloud Run, il deployment senza impostazioni di configurazione crea una revisione utilizzando tutte le impostazioni predefinite.

Impostazioni predefinite di configurazione

Punto di ingresso

Quando esegui il deployment dall'origine, App Engine legge il comando del punto di ingresso dall'attributo entrypoint in app.yaml. Se non viene fornito alcun punto di ingresso, viene utilizzato un valore predefinito specifico per il runtime. Cloud Run utilizza i buildpack di Google Cloud durante il deployment dall'origine e alcuni linguaggi non hanno un punto di ingresso predefinito, pertanto devi fornirne uno, altrimenti la build non andrà a buon fine. Ad esempio, i buildpack Python richiedono un Procfile o la specifica della variabile di ambiente di build GOOGLE_ENTRYPOINT.

Rivedi la documentazione dei buildpack per eventuali requisiti di configurazione specifici del linguaggio.

Scalabilità

Sebbene Cloud Run e l'ambiente standard di App Engine condividano gran parte della stessa infrastruttura di scalabilità, Cloud Run è stato semplificato per consentire una scalabilità molto più rapida. Nell'ambito di questa semplificazione, le impostazioni configurabili sono limitate a:

• Massima contemporaneità
• Numero massimo e Minimo istanze

Per le istanze Cloud Run, l'utilizzo della CPU di destinazione non è configurabile e fisso al 60%. Per ulteriori dettagli sulla scalabilità automatica, consulta la documentazione di Cloud Run.

L'ambiente flessibile di App Engine utilizza il gestore della scalabilità automatica di Compute Engine, perciò ha caratteristiche di scalabilità molto diverse rispetto all'ambiente standard di App Engine e a Cloud Run.

Timeout istanza inattiva

In App Engine, le istanze inattive rimangono attive per un massimo di 15 minuti dopo il termine dell'elaborazione dell'ultima richiesta. Cloud Run ti consente di configurare questo comportamento utilizzando l'allocazione della CPU. Per ottenere lo stesso comportamento di App Engine, imposta l'allocazione della CPU su CPU sempre allocata. In alternativa, utilizza CPU allocata solo durante l'elaborazione delle richieste per arrestare immediatamente le istanze inattive (se non ci sono richieste in attesa).

Richieste di riscaldamento

Cloud Run riscalda automaticamente le istanze utilizzando comando container entrypoint, quindi non è necessario abilitare manualmente le richieste di riscaldamento o configurare Gestore /_ah/warmup. Se hai del codice che vuoi eseguire nell'istanza prima che le richieste vengano elaborate, puoi:

• Configura la tua app per ascoltare le richieste
• Configura un probe di avvio personalizzato

Contenuti statici

Nell'ambiente standard App Engine, puoi pubblicare contenuti statici senza utilizzare risorse di calcolo pubblicando i dati da Cloud Storage o configurando i gestori. Cloud Run non dispone dell'opzione relativa ai gestori per pubblicare contenuti statici, quindi puoi pubblicare i contenuti dal servizio Cloud Run (come per i contenuti dinamici) o da Cloud Storage.

Ruolo Invoker di Cloud Run

Cloud Run offre inoltre la possibilità di controllare l'accesso a un servizio con Identity and Access Management (IAM). Le associazioni dei criteri IAM per un servizio possono essere impostate utilizzando gcloud CLI, la console o Terraform.

Per replicare il comportamento di App Engine, puoi rendere il servizio pubblico consentendo le richieste non autenticate. Può essere impostato al momento del deployment o aggiornando le associazioni di criteri IAM su un servizio esistente.

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

In alternativa, puoi scegliere di controllare chi ha accesso al servizio concedendo il ruolo IAM Invoker di Cloud Run, che è configurabile in base al servizio.

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

Variabili di ambiente e metadati

Sia App Engine che Cloud Run dispongono di determinate variabili di ambiente che vengono impostate automaticamente. La tabella seguente mostra le variabili di ambiente App Engine e i rispettivi equivalenti Cloud Run. Cloud Run implementa solo poche variabili di ambiente, rispetto ad App Engine, ma i dati disponibili dal server dei metadati sono per lo più equivalenti.

Variabili di ambiente predefinite

Percorsi comuni dei server di metadati

Passaggi successivi

• Guida rapida: esegui il deployment di un servizio web con Cloud Run
• La mia app è adatta per Cloud Run?
• Esegui la migrazione del mio dominio personalizzato App Engine a Cloud Load Balancing
• Altre risorse:
  • Esegui la migrazione da App Engine a Cloud Run con Docker (Python: codelab, video, Java: codelab)
  • Esegui la migrazione da App Engine a Cloud Run con i buildpack (Python: codelab, video, Java: codelab)