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. Copre 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 funziona su gran parte della stessa infrastruttura dell'ambiente standard di App Engine, quindi esistono 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 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 integrazioni migliorate con Google Cloud e servizi di terze parti, consente inoltre 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ù pertinenti 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
|
|
|||||||||||||||||||
| URL della versione/revisione |
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
|
|
|||||||||||||||||||
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 le istanze massime uguali alle istanze minime. | ||||||||||||||||||
| 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 |
|
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 |
|
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 | Costo inferiore per le istanze minime inattive (vedi Tempo di 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ì | Configurare utilizzando Cloud Load Balancing | ||||||||||||||||||
| Firewall | Sì | Sì | Configurare l'utilizzo di Google Cloud Armor | ||||||||||||||||||
Connettività |
|||||||||||||||||||||
| Domini personalizzati | Sì | Sì | Configurare utilizzando 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 su più regioni | 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
Il modello di risorse di Cloud Run è molto simile ad App Engine, ma presenta alcune differenze fondamentali:
- Cloud Run non dispone di una risorsa Application di primo livello o del servizio
defaultcorrispondente. - I servizi Cloud Run nello stesso progetto possono essere di cui è stato eseguito il deployment 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 Cloud Run utilizzano il formato
SERVICE_NAME-REVISION_SUFFIX, doveREVISION_SUFFIXviene generato automaticamente o impostato utilizzando il flag di deployment--revision-suffix=REVISION_SUFFIX. - Le revisioni Cloud Run sono immutabili, il che significa che non puoi riutilizzare i nomi come puoi fare con le versioni App Engine (utilizzando il flag di deployment
--version=VERSION_ID). - Gli URL dei servizi Cloud Run si basano su un identificatore 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 la vita del servizio. - In Cloud Run, per impostazione predefinita vengono esposti solo gli URL dei servizi (
SERVICE_IDENTIFIER.run.appehttps://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app). Per gestire una revisione specifica, devi configurare un tag di traffico. In App Engine, sia gli URL di servizio che 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.
Sebbene Cloud Run abbia il file di configurazione service.yaml, non viene utilizzato nello stesso modo di app.yaml. service.yaml di Cloud Run non può essere utilizzato per il deployment dal codice sorgente, poiché uno degli elementi richiesti è il percorso dell'immagine del contenitore finale. Inoltre, service.yaml è conforme alle specifiche di Knative e può essere difficile da leggere per chi non ha dimestichezza 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 App Engine che iniziano a utilizzare Cloud Run, l'utilizzo dei flag di deployment gcloud CLI è molto più in linea con la gestione della configurazione al momento del deployment di App Engine.
Per impostare la configurazione durante il deployment del 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 vengono 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: |
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.
Valori predefiniti della 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 |
| Contemporaneità massima (richieste) | 10 | Nessuno | 80 |
| Timeout richiesta |
|
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
Durante il deployment dall'origine, App Engine legge il comando entrypoint 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.
Consulta la documentazione dei buildpack per eventuali requisiti di configurazione specifici per la 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:
- Contemporaneità massima
- Istanze Massime e Minime
Per le istanze Cloud Run, l'utilizzo della CPU target non è configurabile ed è fissato 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, pertanto presenta 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 il riscaldamento delle istanze utilizzando il comando entrypoint del contenitore, pertanto non è necessario attivare manualmente le richieste di riscaldamento o configurare un gestore /_ah/warmup. Se hai del codice che vuoi eseguire 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 pubblicandoli da Cloud Storage o configurando gli handler. 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. Questo valore può essere impostato durante il deployment o aggiornando le associazioni dei criteri IAM in 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, che è configurabile per 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 principale. 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 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 corrente. 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 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 corrente. | |
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 applicazione, in MB. | |
NODE_ENV (disponibile solo nel runtime di Node.js)
|
Imposta 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 |
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. | 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
- Guida rapida: esegui il deployment di un servizio web con Cloud Run
- La mia app è adatta a Cloud Run?
- Eseguire la migrazione del mio dominio personalizzato App Engine a Cloud Load Balancing
- Altre risorse: