Confronta App Engine e Cloud Run

ID regione

REGION_ID è un codice abbreviato assegnato da Google in base all'area geografica selezionata al momento della creazione dell'app. Il codice non corrisponde a un paese o a una provincia, anche se alcuni ID regione possono sembrare simili ai codici paese e provincia 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 aiutarti a prepararti alla migrazione dall'ambiente standard di App Engine o dall'ambiente flessibile di App Engine.

Panoramica

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

Cloud Run è progettato per migliorare l'esperienza di App Engine, incorporando molte delle migliori funzionalità dell'ambiente standard di App Engine e dell'ambiente flessibile di App Engine. I servizi Cloud Run possono 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 migliori integrazioni con i servizi Google Cloud e di terze parti, consente inoltre 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ù rilevanti 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/A
Servizio Servizio
Versione Revisione

Endpoint URL
URL app
(servizio default) 		https://PROJECT_ID.REGION_ID.r.appspot.com N/A
URL del servizio https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com https://SERVICE_IDENTIFIER.run.app
URL versione/revisione https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com https://TAG---SERVICE_IDENTIFIER.run.app

Scalabilità
Scalabilità automatica Sì Sì Sì
Scalabilità manuale Sì Sì Sebbene non esista un'impostazione specifica per la scalabilità manuale, lo stesso comportamento può essere replicato configurando il numero massimo di istanze uguale al numero minimo di istanze
Scalabilità fino a zero Sì No Sì
Richieste di riscaldamento Configurabile No Automatica
Timeout dell'istanza inattiva (al termine dell'ultima richiesta) Fino a 15 minuti Dipende dall'impostazione di allocazione della CPU. Usa la 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
Dall'origine Sì Yes
Immagine container No Sì (runtime personalizzati) Yes

Risorse di computing
vCPU
Classe istanza vCPU* Memoria
F/B1 0,25 384 MB
F/B2 .5 768 MB
F/B4 1 1,5 GB
F/B4_1G 1 3 GB
B8 2 3 GB
* Gli equivalenti delle 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, quando la CPU è sempre allocata.
Sì, quando la CPU viene allocata solo durante l'elaborazione delle richieste.
Numero minimo di istanze inattive Stesso costo delle istanze attive Costo inferiore per il numero minimo di istanze inattive (vedi Tempo di istanza di container fatturabile)
Sconti per impegno di utilizzo (CUD) No Sì

Sicurezza
Impostazioni traffico in entrata Yes Yes Yes
Ruolo di Invoker No Yes
IAP Yes Yes Configurazione con Cloud Load Balancing
Firewall Yes Yes Configurazione con Google Cloud Armor

Connettività
Domini personalizzati Yes Yes Configurazione con Cloud Load Balancing
Connettività VPC (incluso VPC condiviso) Yes N/A Yes
Impostazioni traffico in uscita VPC Yes N/A Yes
Bilanciamento del carico tra più regioni No Yes

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

Modello di risorsa

Diagramma dei modelli di risorse di App Engine e Cloud Run

Il modello di risorse di Cloud Run è molto simile ad App Engine, ma esistono 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 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 o viene 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 fai con le versioni di App Engine (utilizzando il flag di deployment --version=VERSION_ID).
  • Gli URL del servizio Cloud Run sono basati su un identificatore di servizio generato automaticamente al primo deployment del servizio. Gli identificatori di servizio utilizzano il formato SERVICE_NAME-<auto-generated identifier>. L'identificatore di servizio è univoco e non cambia durante il ciclo di vita del servizio.
  • In Cloud Run, vengono esposti solo gli URL dei servizi (SERVICE_IDENTIFIER.run.app) per impostazione predefinita. Per gestire una revisione specifica, devi configurare un tag di traffico. In App Engine, entrambi gli URL del servizio e della versione vengono esposti automaticamente.

Deployment e configurazione

In App Engine, la maggior parte delle configurazioni viene eseguita nel criterio app.yaml incluso in ogni deployment. Questa semplicità ha un costo in quanto, mentre alcune impostazioni possono essere aggiornate utilizzando l'API Admin, la maggior parte delle modifiche richiede di eseguire nuovamente il deployment del servizio.

Sebbene Cloud Run abbia il file di configurazione service.yaml, non viene utilizzato allo stesso modo di app.yaml. Non è possibile utilizzare Cloud Run service.yaml durante il deployment dall'origine, poiché uno degli elementi richiesti è il percorso dell'immagine container finale. Inoltre, service.yaml è conforme alle specifiche di Knative e può essere difficile da leggere per chi non ha familiarità con i file di configurazione di tipo 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'utilizzo dei flag di deployment dell'interfaccia a riga di comando gcloud è molto più strettamente collegato alla gestione della configurazione durante il 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 per ogni deployment (vedi Gestione delle configurazioni), puoi farlo per semplificare la gestione delle configurazioni.

In Cloud Run puoi anche aggiornare la configurazione senza ripetere 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 App Engine, è necessario specificare tutte le impostazioni per ogni deployment e a tutte le impostazioni non fornite vengono assegnati valori predefiniti. Prendi ad esempio App Engine service-a, con versioni che utilizzano i file app.yaml mostrati di seguito:

Servizio App Engine-a versione 1 Servizio App Engine-a 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 mantieni i valori esistenti. Devi fornire i valori solo per le impostazioni che vuoi modificare. Ad esempio:

Servizio Cloud Run-a revisione1 Servizio Cloud Run - A revisione 2
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, un 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, un deployment senza impostazioni di configurazione crea una revisione con 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, 512MB
Massima contemporaneità (richieste) 10 Nessuna esperienza 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 Nessuna esperienza 20 100
Numero minimo di istanze 0 2 0

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 del runtime. Cloud Run utilizza i buildpack di Google Cloud durante il deployment dal codice sorgente e alcuni linguaggi non hanno un entry point predefinito, quindi devi fornirne uno o 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.

Esamina la documentazione relativa ai buildpack per verificare la presenza di eventuali requisiti di configurazione specifici della lingua.

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 scaler automatico di Compute Engine, quindi ha caratteristiche di scalabilità molto diverse rispetto all'ambiente standard di App Engine e a Cloud Run.

Timeout dell'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 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, puoi usare la 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 il riscaldamento delle istanze utilizzando il comando del punto di ingresso del container, quindi non è necessario abilitare manualmente le richieste di warmup o configurare un gestore /_ah/warmup. Se vuoi eseguire il codice all'avvio dell'istanza, prima che vengano elaborate le richieste, puoi:

Contenuti statici

Nell'ambiente standard di App Engine, puoi pubblicare contenuti statici senza utilizzare risorse di calcolo eseguendo la pubblicazione da Cloud Storage o configurando i gestori. Cloud Run non dispone dell'opzione gestori per la pubblicazione di 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 anche la possibilità di controllare l'accesso a un servizio con Identity and Access Management (IAM). Le associazioni di 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 in fase di deployment oppure 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

Utilizza 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, 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 di entità. 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 sia Cloud Run hanno determinate variabili di ambiente che vengono impostate automaticamente. La tabella seguente mostra le variabili di ambiente di App Engine e i relativi equivalenti di Cloud Run. Cloud Run implementa solo alcune variabili di ambiente, rispetto ad App Engine, ma i dati disponibili dal server di 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, è 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/A K_CONFIGURATION Il nome della configurazione Cloud Run che ha creato la revisione.
GOOGLE_CLOUD_PROJECT N/A L'ID progetto Cloud associato alla tua applicazione.
GAE_APPLICATION L'ID della tua applicazione App Engine. Questo ID è preceduto dal prefisso "region code~", ad esempio "e~" per le applicazioni di cui è stato eseguito il deployment in Europa.
GAE_DEPLOYMENT_ID L'ID del deployment corrente.
GAE_ENV L'ambiente App Engine. Impostalo su "standard" se nell'ambiente standard.
GAE_INSTANCE L'ID dell'istanza su cui il servizio è attualmente in esecuzione.
GAE_MEMORY_MB La quantità di memoria disponibile per il processo di richiesta, in MB.
NODE_ENV (disponibile solo nel runtime Node.js) Impostalo in produzione quando viene eseguito il deployment del servizio.
GAE_RUNTIME Il runtime specificato nel file app.yaml.

Percorsi comuni dei server di metadati

Percorso Descrizione Esempio
/computeMetadata/v1/project/project-id L'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 di container (disponibile anche nei log). 16a61494692b7432806a16
(stringa di caratteri alfanumerici)
/computeMetadata/v1/instance/region
** Non disponibile per l'ambiente flessibile di App Engine 		Regione di questo servizio; restituisce projects/PROJECT_NUMBER/regions/REGION projects/12345678912/regions/us-central1
/computeMetadata/v1/instance/service-accounts/default/email Email per l'account di servizio di runtime di questo servizio. service_account@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. {
"access_token":"<TOKEN>",
"expires_in":1799,
"token_type":"Bearer"
}

Passaggi successivi