Confronta App Engine e Cloud Run

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base alla regione selezionata quando crei l'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici di paesi e province di uso comune. Per le app create dopo febbraio 2020, REGION_ID.r è incluso negli URL di App Engine. Per le app esistenti create prima di questa data, l'ID regione è facoltativo nell'URL.

Scopri di più sugli ID regione.

Questa guida fornisce un'introduzione a Cloud Run per chi ha familiarità con 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 del 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.

Ambiente standard di App Engine Ambiente flessibile di App Engine Cloud Run
Terminologia Applicazione N/D
Servizio Servizio
Versione Revisione

Endpoint URL
URL dell'app
(servizio default) 		https://PROJECT_ID.REGION_ID.r.appspot.com N/D
URL del servizio https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
  • https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
  • https://SERVICE_IDENTIFIER.run.app
URL versione/revisione https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
  • https://TAG---SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
  • https://TAG---SERVICE_IDENTIFIER.run.app

Scalabilità
Scalabilità automatica Sì Sì Sì
Scalabilità manuale Sì Sì Anche se non è prevista un'impostazione specifica di scalabilità manuale, lo stesso comportamento può essere replicato configurando un numero massimo di istanze pari al numero minimo di istanze
Scalabilità fino a zero Sì No Sì
Richieste di riscaldamento Configurabile No Automatico
Timeout dell'istanza inattiva (dopo il completamento dell'ultima richiesta) Fino a 15 minuti Dipende dall'impostazione dell'allocazione della CPU. Utilizza CPU sempre allocata per emulare il comportamento di App Engine
Timeout richiesta
  • Scalabilità automatica: 10 minuti
  • Scalabilità manuale/di base: 24 ore
 60 minuti Configurabile fino a 60 minuti (valore predefinito: 5 minuti)

Deployment
Dalla fonte Sì Sì
Immagine container No Sì (runtime personalizzati) Sì

Risorse di computing
vCPU
Classe di istanza vCPU* Memoria
V/B1 0,25 384 MB
F/B2 0,75 768 MB
F/B4 1 1,5 GB
F/B4_1G 1 3 GB
B8 2 3 GB
* Gli equivalenti vCPU sono approssimativi 		Fino a 80 vCPU Fino a 8 vCPU
Memoria Fino a 6,5 GB per vCPU Fino a 32 GB

Modello di determinazione del prezzo
Tariffa per richiesta No No, se la CPU è sempre allocata.
Sì, quando la CPU viene allocata solo durante l'elaborazione delle richieste.
Istanze minime inattive Stesso costo delle istanze attive Riduzione del costo per il numero minimo di istanze inattive (vedi Tempo dell'istanza di container fatturabile)
Sconti per impegno di utilizzo (CUD) No Sì

Sicurezza
Impostazioni traffico in entrata Sì Sì Sì
Ruolo invocatore No Sì
IAP Sì Sì Configura con Cloud Load Balancing
Firewall Sì Sì Configura con Google Cloud Armor

Connettività
Domini personalizzati Sì Sì Configura con Cloud Load Balancing
Connettività VPC (incluso VPC condiviso) Sì N/D Sì
Impostazioni di traffico in uscita VPC Sì N/D Sì
Bilanciamento del carico multiregionale No Sì

Accesso ai servizi Google Cloud
Cloud SQL Sì Sì Sì
Librerie client cloud Se utilizzi le librerie client di Cloud in App Engine, non devi apportare alcuna modifica durante la migrazione a Cloud Run. Queste librerie client funzionano ovunque, il che significa che la tua applicazione è più portabile.
Servizi integrati legacy di App Engine Sì (solo Java, Python, Go, PHP) No No

Modello di risorsa

Diagramma del modello di risorse di App Engine e Cloud Run

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

  • Cloud Run non dispone di una risorsa Application 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 del progetto si trovano nella stessa regione.
  • Cloud Run utilizza il termine Revisione anziché Versione per allinearsi al modello di risorse 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 nel file app.yaml incluso in ogni deployment. Questa semplicità ha un costo, in quanto, sebbene alcune impostazioni possano essere aggiornate utilizzando l'API Admin, la maggior parte delle modifiche richiede il nuovo dispiegamento 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 Gestire le configurazioni), puoi farlo per semplificare la gestione della configurazione.

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 App Engine service-a, con le versioni che utilizzano i file app.yaml mostrati di seguito:

Servizio App Engine - versione 1 Servizio App Engine - versione 2
app.yaml 
runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a
Configurazione applicata 
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 mantengono i valori esistenti. Devi fornire i valori solo per le impostazioni che vuoi modificare. Ad esempio:

Revisione 1 del servizio Cloud Run-a Revisione 2 del servizio Cloud Run
Comando di deployment 
gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a
Configurazione applicata 
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

Impostazione di configurazione Ambiente standard di App Engine Ambiente flessibile di App Engine Cloud Run
Risorse di computing F1 1 vCPU, 0,6 GB 1 vCPU, 512 MB
Contemporaneità massima (richieste) 10 Nessuno 80
Timeout richiesta
  • Scalabilità automatica: 10 minuti
  • Scalabilità manuale/di base: 24 ore
 60 minuti 5 minuti
Target di utilizzo della CPU 60% 50% 60%
Numero massimo di istanze Nessuno 20 100
Numero minimo di istanze 0 2 0

Entry point

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 contatto, viene utilizzato un valore predefinito specifico del runtime. Cloud Run utilizza i buildpack di Google Cloud per il deployment dal codice sorgente e alcune lingue non hanno un punto di contatto predefinito, il che significa che devi fornirne uno o la compilazione non andrà a buon fine. Ad esempio, i buildpack Python richiedono un Procfile o la specifica della variabile di ambiente di compilazione 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:

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 warmup

Cloud Run esegue automaticamente l'inizializzazione delle istanze utilizzando il comando entrypoint del contenitore, pertanto non è necessario attivare manualmente le richieste di preriscaldamento o configurare un gestore /_ah/warmup. Se hai del codice che vuoi eseguire nell'istanza prima che le richieste vengano elaborate, puoi:

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 di gestore per la pubblicazione di contenuti statici, pertanto puoi pubblicare i contenuti dal servizio Cloud Run (come per i contenuti dinamici) o da Cloud Storage.

Ruolo Cloud Run Invoker

Cloud Run offre anche 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 pubblico il servizio consentendo le richieste non autenticate. Può essere impostato al momento del deployment o aggiornando le associazioni di criteri IAM su un servizio esistente.

Deployment

Utilizza il flag di deployment --allow-unauthenticated:

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

Servizio esistente

Usa il comando gcloud run services add-iam-policy-binding:

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

dove SERVICE_NAME è il nome del servizio Cloud Run.

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.

Deployment

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

dove SERVICE_NAME è il nome del servizio e MEMBER_TYPE è il tipo di entità. Ad esempio: user:email@domain.com.

Per un elenco dei valori accettabili per MEMBER_TYPE, consulta la pagina dei concetti IAM.

Servizio esistente

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

dove SERVICE_NAME è il nome del servizio e MEMBER_TYPE è il tipo principale. Ad esempio: user:email@domain.com.

Per un elenco dei valori accettabili per MEMBER_TYPE, consulta la pagina dei concetti IAM.

Variabili di ambiente e metadati

Sia App Engine che Cloud Run hanno determinate variabili di ambiente che vengono impostate automaticamente. La tabella seguente mostra le variabili di ambiente di App Engine, insieme ai relativi equivalenti di 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

Nome App Engine Nome Cloud Run Descrizione
GAE_SERVICE K_SERVICE Il nome del servizio attuale. In App Engine, questo valore è impostato su "default" se non specificato.
GAE_VERSION K_REVISION L'etichetta della versione corrente del servizio.
PORT PORT La porta che riceve le richieste HTTP.
N/D K_CONFIGURATION Il nome della configurazione Cloud Run che ha creato la revisione.
GOOGLE_CLOUD_PROJECT N/D L'ID del progetto Cloud associato alla tua applicazione.
GAE_APPLICATION L'ID della tua applicazione App Engine. Questo ID è preceduto da "codice regione~", ad esempio "e~" per le applicazioni di cui è stato eseguito il deployment in Europa.
GAE_DEPLOYMENT_ID L'ID del deployment attuale.
GAE_ENV L'ambiente App Engine. Imposta su "standard" se nell'ambiente standard.
GAE_INSTANCE L'ID dell'istanza su cui è attualmente in esecuzione il servizio.
GAE_MEMORY_MB La quantità di memoria disponibile per il processo di richiesta, in MB.
NODE_ENV (disponibile solo nel runtime Node.js) Impostalo su produzione quando viene eseguito il deployment del servizio.
GAE_RUNTIME Il runtime specificato nel file app.yaml.

Percorsi comuni del server di metadati

Percorso Descrizione Esempio
/computeMetadata/v1/project/project-id ID del progetto a cui appartiene il servizio test_project
/computeMetadata/v1/project/numeric-project-id Numero del progetto a cui appartiene il servizio 12345678912
/computeMetadata/v1/instance/id Identificatore univoco dell'istanza del contenitore (disponibile anche nei log). 16a61494692b7432806a16
(stringa di caratteri alfanumerici)
/computeMetadata/v1/instance/region
** Non disponibile per l'ambiente flessibile di App Engine 		La regione di questo servizio restituisce projects/PROJECT_NUMBER/regions/REGION projects/12345678912/regions/us-central1
/computeMetadata/v1/instance/service-accounts/default/email Indirizzo email dell'account di servizio di runtime di questo servizio. account_servizio@test_project.iam.gserviceaccount.com
/computeMetadata/v1/instance/service-accounts/default/token Genera un token di accesso OAuth2 per l'account di servizio di questo servizio. Questo endpoint restituirà una risposta JSON con un attributo access_token. {
&quot;access_token&quot;:&quot;&lt;TOKEN&gt;&quot;,
"scadenza_in":1799,
&quot;token_type&quot;:&quot;Bearer&quot;
}

Passaggi successivi