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 |
|
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 |
|
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
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
, doveREVISION_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: |
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 |
|
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:
- Massima contemporaneità
- Istanze Numero massimo e Minimo
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
- Guida rapida: 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: