Questo tutorial mostra come uno sviluppatore di servizi può risolvere i problemi di un servizio Cloud Run utilizzando gli strumenti di Google Cloud Observability per la rilevazione e un flusso di lavoro di sviluppo locale per le indagini.
Questo "case study" passo passo complementare alla guida alla risoluzione dei problemi utilizza un progetto di esempio che genera errori di runtime durante il deployment, che puoi risolvere per trovare e correggere il problema.
Obiettivi
- Scrivere, creare ed eseguire il deployment di un servizio in Cloud Run
- Utilizzare Error Reporting e Cloud Logging per identificare un errore
- Recupera l'immagine del contenitore da Container Registry per un'analisi della causa principale
- Correggi il servizio "produzione", quindi miglioralo per ridurre i problemi futuri
Costi
In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi basata sull'utilizzo previsto,
utilizza il Calcolatore prezzi.
Prima di iniziare
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
- Abilita l'API Cloud Run Admin
- Installa e inizializza la gcloud CLI.
- Aggiorna i componenti:
gcloud components update
- Segui le istruzioni per installare Docker localmente
Ruoli obbligatori
Per ottenere le autorizzazioni necessarie per completare il tutorial, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto:
-
Editor Cloud Build (
roles/cloudbuild.builds.editor
) -
Amministratore Cloud Run (
roles/run.admin
) -
Error Reporting Viewer (
roles/errorreporting.viewer
) -
Logs View Accessor (
roles/logging.viewAccessor
) -
Amministratore IAM del progetto (
roles/resourcemanager.projectIamAdmin
) -
Utente account di servizio (
roles/iam.serviceAccountUser
) -
Consumatore di utilizzo del servizio (
roles/serviceusage.serviceUsageConsumer
) -
Amministratore archiviazione (
roles/storage.admin
)
Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.
Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.
Configurare i valori predefiniti di gcloud
Per configurare gcloud con i valori predefiniti per il servizio Cloud Run:
Imposta il progetto predefinito:
gcloud config set project PROJECT_ID
Sostituisci PROJECT_ID con il nome del progetto che hai creato per questo tutorial.
Configura gcloud per la regione scelta:
gcloud config set run/region REGION
Sostituisci REGION con la regione di Cloud Run supportata che preferisci.
Località Cloud Run
Cloud Run è un servizio a livello di regione, il che significa che l'infrastruttura che gestisce i tuoi servizi Cloud Run si trova in una regione specifica ed è gestita da Google in modo da essere disponibile in modo ridondante in tutte le zone all'interno della regione.
Soddisfare i requisiti di latenza, disponibilità o durabilità è uno dei fattori principali per selezionare la regione in cui vengono eseguiti i servizi Cloud Run.
In genere puoi selezionare la regione più vicina ai tuoi utenti, ma devi prendere in considerazione la posizione degli altri prodotti Google Cloud utilizzati dal servizio Cloud Run.
L'utilizzo combinato dei prodotti Google Cloud in più località può influire sulla latenza e sul costo del servizio.
Cloud Run è disponibile nelle seguenti regioni:
Soggetto ai prezzi di Livello 1
asia-east1
(Taiwan)asia-northeast1
(Tokyo)asia-northeast2
(Osaka)asia-south1
(Mumbai, India)europe-north1
(Finlandia) Bassi livelli di CO2europe-southwest1
(Madrid) Basso livello di CO2europe-west1
(Belgio) Bassi livelli di CO2europe-west4
(Paesi Bassi) Bassi livelli di CO2europe-west8
(Milano)europe-west9
(Parigi) Bassi livelli di CO2me-west1
(Tel Aviv)us-central1
(Iowa) Bassi livelli di CO2us-east1
(Carolina del Sud)us-east4
(Virginia del Nord)us-east5
(Columbus)us-south1
(Dallas) Bassi livelli di CO2us-west1
(Oregon) Bassi livelli di CO2
Soggetto ai prezzi di Livello 2
africa-south1
(Johannesburg)asia-east2
(Hong Kong)asia-northeast3
(Seul, Corea del Sud)asia-southeast1
(Singapore)asia-southeast2
(Giacarta)asia-south2
(Delhi, India)australia-southeast1
(Sydney)australia-southeast2
(Melbourne)europe-central2
(Varsavia, Polonia)europe-west10
(Berlino) Bassi livelli di CO2europe-west12
(Torino)europe-west2
(Londra, Regno Unito) Bassi livelli di CO2europe-west3
(Francoforte, Germania) Bassi livelli di CO2europe-west6
(Zurigo, Svizzera) Bassi livelli di CO2me-central1
(Doha)me-central2
(Dammam)northamerica-northeast1
(Montreal) Bassi livelli di CO2northamerica-northeast2
(Toronto) Bassi livelli di CO2southamerica-east1
(San Paolo, Brasile) Bassi livelli di CO2southamerica-west1
(Santiago, Cile) Bassi livelli di CO2us-west2
(Los Angeles)us-west3
(Salt Lake City)us-west4
(Las Vegas)
Se hai già creato un servizio Cloud Run, puoi visualizzare la regione nella dashboard di Cloud Run nella console Google Cloud.
Assemblaggio del codice
Crea un nuovo servizio di saluto Cloud Run passo passo. Ti ricordiamo che questo servizio crea intenzionalmente un errore di runtime per l'esercizio di risoluzione dei problemi.
Crea un nuovo progetto:
Node.js
Crea un progetto Node.js definendo il pacchetto del servizio, le dipendenze iniziali e alcune operazioni comuni.Crea una nuova directory
hello-service
:mkdir hello-service cd hello-service
Crea un nuovo progetto Node.js generando un file
package.json
:npm init --yes npm install --save express@4
Apri il nuovo file
package.json
nell'editor e configura uno scriptstart
per eseguirenode index.js
. Al termine, il file avrà il seguente aspetto:
Se continui a sviluppare questo servizio oltre il tutorial immediato, ti consigliamo di compilare la descrizione, l'autore e valutare la licenza. Per ulteriori dettagli, consulta la documentazione di package.json.
Python
Crea una nuova directory
hello-service
:mkdir hello-service cd hello-service
Crea un file requirements.txt e copia le dipendenze al suo interno:
Vai
Crea una nuova directory
hello-service
:mkdir hello-service cd hello-service
Crea un progetto Go inizializzando un nuovo modulo Go:
go mod init example.com/hello-service
Puoi aggiornare il nome specifico come preferisci: devi aggiornarlo se il codice viene pubblicato in un repository di codice accessibile tramite il web.
Java
Crea un nuovo progetto Maven:
mvn archetype:generate \ -DgroupId=com.example.cloudrun \ -DartifactId=hello-service \ -DarchetypeArtifactId=maven-archetype-quickstart \ -DinteractiveMode=false
Copia le dipendenze nell'elenco delle dipendenze
pom.xml
(tra gli elementi<dependencies>
):Copia l'impostazione di compilazione in
pom.xml
(sotto gli elementi<dependencies>
):
Crea un servizio HTTP per gestire le richieste in entrata:
Node.js
Python
Vai
Java
Crea un
Dockerfile
per definire l'immagine del container utilizzata per il deployment del servizio:Node.js
Python
Vai
Java
Questo esempio utilizza Jib per creare immagini Docker utilizzando strumenti Java comuni. Jib ottimizza le build dei container senza dover disporre di un Dockerfile o di Docker. Scopri di più sulla creazione di container Java con Jib.
Invio del codice
Il codice di spedizione è costituito da tre passaggi: creazione di un'immagine container con Cloud Build, caricamento dell'immagine container in Container Registry ed esecuzione del deployment dell'immagine container in Cloud Run.
Per spedire il codice:
Crea il contenitore e pubblicalo su Container Registry:
Node.js
gcloud builds submit --tag gcr.io/PROJECT_ID/hello-service
dove PROJECT_ID è l'ID progetto Google Cloud. Puoi controllare il tuo ID progetto corrente con
gcloud config get-value project
.In caso di esito positivo, dovresti visualizzare un messaggio di successo contenente l'ID, l'ora di creazione e il nome dell'immagine. L'immagine è archiviata in Container Registry e, se lo desideri, può essere riutilizzata.
Python
gcloud builds submit --tag gcr.io/PROJECT_ID/hello-service
dove PROJECT_ID è l'ID progetto Google Cloud. Puoi controllare il tuo ID progetto corrente con
gcloud config get-value project
.In caso di esito positivo, dovresti visualizzare un messaggio di successo contenente l'ID, l'ora di creazione e il nome dell'immagine. L'immagine è archiviata in Container Registry e, se lo desideri, può essere riutilizzata.
Vai
gcloud builds submit --tag gcr.io/PROJECT_ID/hello-service
dove PROJECT_ID è l'ID progetto Google Cloud. Puoi controllare il tuo ID progetto corrente con
gcloud config get-value project
.In caso di esito positivo, dovresti visualizzare un messaggio di successo contenente l'ID, l'ora di creazione e il nome dell'immagine. L'immagine è archiviata in Container Registry e, se lo desideri, può essere riutilizzata.
Java
- Utilizza l'assistente per le credenziali gcloud per autorizzare Docker a eseguire il push nel tuo Container Registry.
gcloud auth configure-docker
- Utilizza il plug-in Maven Jib per creare il container ed eseguirlo in Container Registry.
mvn compile jib:build -Dimage=gcr.io/PROJECT_ID/hello-service
dove PROJECT_ID è l'ID progetto Google Cloud. Puoi controllare il tuo ID progetto corrente con
gcloud config get-value project
.In caso di esito positivo, dovresti visualizzare il messaggio BUILD SUCCESS. L'immagine è archiviata in Container Registry e, se lo desideri, può essere riutilizzata.
- Utilizza l'assistente per le credenziali gcloud per autorizzare Docker a eseguire il push nel tuo Container Registry.
Esegui questo comando per eseguire il deployment dell'app:
gcloud run deploy hello-service --image gcr.io/PROJECT_ID/hello-service
Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.
hello-service
è sia il nome dell'immagine container sia il nome del servizio Cloud Run. Tieni presente che l'immagine del contenitore viene dispiattata nel servizio e nella regione che hai configurato in precedenza in Configurazione di gcloud.Rispondi
y
, "Sì", alla richiesta Consenti non autenticato. Per ulteriori dettagli sull'autenticazione basata su IAM, consulta la pagina Gestire l'accesso.Attendi il completamento del deployment, che potrebbe richiedere circa mezzo minuto. Se l'operazione riesce, la riga di comando visualizza l'URL del servizio.
Prova
Prova il servizio per verificare di averlo implementato correttamente. Le richieste dovrebbero non riuscire con un errore HTTP 500 o 503 (membri della classe Errori del server 5xx). Il tutorial illustra la procedura di risoluzione dei problemi relativi a questa risposta di errore.
Al servizio viene assegnato automaticamente un URL navigabile.
Vai a questo URL con il browser web:
Apri un browser web
Individua l'URL del servizio visualizzato dall'output del comando di deployment precedente.
Se il comando di deployment non ha fornito un URL, si è verificato un problema. Esamina il messaggio di errore e intervieni di conseguenza: se non sono presenti indicazioni utili, consulta la guida alla risoluzione dei problemi e, se necessario, riprova a eseguire il comando di deployment.
Vai a questo URL copiandolo nella barra degli indirizzi del browser e premendo ENTER.
Visualizza l'errore HTTP 500 o HTTP 503.
Se ricevi un errore HTTP 403, è possibile che tu abbia rifiutato
allow unauthenticated invocations
al prompt di deployment. Per risolvere il problema, concedi l'accesso non autenticato al servizio:gcloud run services add-iam-policy-binding hello-service \ --member="allUsers" \ --role="roles/run.invoker"
Per ulteriori informazioni, consulta Consentire l'accesso pubblico (non autenticato).
Indagine sul problema
Visualizza che l'errore HTTP 5xx riscontrato sopra in Provare è stato rilevato come errore di runtime in produzione. Questo tutorial illustra una procedura formale per la gestione. Sebbene le procedure di risoluzione degli errori di produzione varierino notevolmente, questo tutorial presenta una sequenza specifica di passaggi per mostrare l'applicazione di strumenti e tecniche utili.
Per esaminare questo problema, dovrai svolgere le seguenti fasi:
- Raccogli ulteriori dettagli sull'errore segnalato per supportare ulteriori indagini e impostare una strategia di mitigazione.
- Riduci l'impatto sugli utenti decidendo di applicare una correzione o di eseguire il rollback a una versione nota come sana.
- Riproduci l'errore per verificare che siano stati raccolti i dettagli corretti e che non si tratti di un problema temporaneo
- Esegui un'analisi delle cause principali del bug per trovare il codice, la configurazione o il processo che ha creato questo errore
All'inizio dell'indagine sono disponibili un URL, un timestamp e il messaggio "Internal Server Error".
Raccolta di ulteriori dettagli
Raccogliere ulteriori informazioni sul problema per capire cosa è successo e determinare i passaggi successivi.
Utilizza gli strumenti di Google Cloud Observability disponibili per raccogliere ulteriori dettagli:
Utilizza la console Error Reporting, che fornisce una dashboard con dettagli e monitoraggio della ricorrenza per gli errori con un'analisi dello stack riconosciuta.
Fai clic sull'errore per visualizzare i dettagli analisi dello stack, tenendo presente le chiamate di funzione eseguite poco prima dell'errore.
Utilizza Cloud Logging per esaminare la sequenza di operazioni che ha causato il problema, inclusi i messaggi di errore non inclusi nella console Error Reporting a causa della mancanza di una traccia dello stack degli errori riconosciuta:
Vai alla console Cloud Logging
Seleziona Revisione Cloud Run > hello-service dal primo menu a discesa. In questo modo, le voci di log verranno filtrate in base a quelle generate dal servizio.
Scopri di più sulla visualizzazione dei log in Cloud Run
Esegui il rollback a una versione sana
Se si tratta di un servizio consolidato, noto per funzionare, esisterà una revisione precedente del servizio su Cloud Run. Questo tutorial utilizza un nuovo servizio senza versioni precedenti, pertanto non puoi eseguire un rollback.
Tuttavia, se hai un servizio con versioni precedenti a cui puoi eseguire il rollback, segui la sezione Visualizzazione dei dettagli della revisione per estrarre il nome del contenitore e i dettagli di configurazione necessari per creare un nuovo deployment funzionante del servizio.
Riprodurre l'errore
Utilizzando i dettagli ottenuti in precedenza, verifica che il problema si verifichi in modo coerente nelle condizioni di test.
Invia la stessa richiesta HTTP provandola di nuovo e controlla se vengono segnalati gli stessi errori e dettagli. Potrebbe essere necessario del tempo prima che vengano visualizzati i dettagli dell'errore.
Poiché il servizio di esempio in questo tutorial è di sola lettura e non attiva effetti collaterali complicati, la riproduzione di errori in produzione è sicura. Tuttavia, per molti servizi reali non è così: potrebbe essere necessario riprodurre gli errori in un ambiente di test o limitare questo passaggio all'indagine locale.
La riproduzione dell'errore stabilisce il contesto per ulteriori operazioni. Ad esempio, se gli sviluppatori non riescono a riprodurre l'errore, ulteriori accertamenti potrebbero richiedere un'ulteriore strumentazione del servizio.
Eseguire un'analisi delle cause principali
L'analisi della causa principale è un passaggio importante per la risoluzione dei problemi in modo da risolvere il problema anziché un sintomo.
In precedenza in questo tutorial, hai riprodotto il problema su Cloud Run, confermando che il problema è attivo quando il servizio è ospitato su Cloud Run. Ora riproduci il problema localmente per determinare se è isolato nel codice o se si verifica solo nell'hosting di produzione.
Se non hai utilizzato Docker CLI localmente con Container Registry, autenticalo con gcloud:
gcloud auth configure-docker
Per approcci alternativi, consulta Metodi di autenticazione di Container Registry.
Se il nome dell'immagine container utilizzata più di recente non è disponibile, la descrizione del servizio contiene le informazioni sull'immagine container di cui è stato eseguito il deployment più di recente:
gcloud run services describe hello-service
Trova il nome dell'immagine del contenitore all'interno dell'oggetto
spec
. Un comando più mirato può recuperarlo direttamente:gcloud run services describe hello-service \ --format="value(spec.template.spec.containers.image)"
Questo comando mostra il nome di un'immagine container, ad esempio
gcr.io/PROJECT_ID/hello-service
.Estrai l'immagine container da Container Registry nel tuo ambiente. Questo passaggio potrebbe richiedere diversi minuti durante il download dell'immagine container:
docker pull gcr.io/PROJECT_ID/hello-service
Gli aggiornamenti successivi all'immagine del contenitore che riutilizzano questo nome possono essere recuperati con lo stesso comando. Se salti questo passaggio, il comando
docker run
riportato di seguito eseguirà il pull di un'immagine del contenitore se non è presente sulla macchina locale.Esegui l'app localmente per verificare che il problema non sia specifico di Cloud Run:
PORT=8080 && docker run --rm -e PORT=$PORT -p 9000:$PORT \ gcr.io/PROJECT_ID/hello-service
Se analizziamo gli elementi del comando riportato sopra,
- La variabile di ambiente
PORT
viene utilizzata dal servizio per determinare la porta su cui eseguire l'ascolto all'interno del contenitore. - Il comando
run
avvia il contenitore, utilizzando per impostazione predefinita il comando entrypoint definito nel Dockerfile o un'immagine container principale. - Il flag
--rm
elimina l'istanza del contenitore all'uscita. - Il flag
-e
assegna un valore a una variabile di ambiente.-e PORT=$PORT
propaga la variabilePORT
dal sistema locale al contenitore con lo stesso nome. - Il flag
-p
pubblica il contenitore come servizio disponibile su localhost sulla porta 9000. Le richieste a localhost:9000 verranno instradate al container sulla porta 8080. Ciò significa che l'output del servizio relativo al numero di porta in uso non corrisponderà al modo in cui si accede al servizio. - L'ultimo argomento
gcr.io/PROJECT_ID/hello-service
è un'immagine contenitoretag
, un'etichetta leggibile per l'identificatore dell'hash SHA256 di un'immagine contenitore. Se non è disponibile localmente, Docker tenta di recuperare l'immagine da un registry remoto.
Nel browser, apri http://localhost:9000. Controlla l'output del terminale per verificare se sono presenti messaggi di errore corrispondenti a quelli su {ops_name}.
Se il problema non è riproducibile localmente, potrebbe essere specifico per l'ambiente Cloud Run. Consulta la guida alla risoluzione dei problemi di Cloud Run per individuare le aree specifiche da esaminare.
In questo caso, l'errore viene riprodotto localmente.
- La variabile di ambiente
Ora che l'errore è stato confermato come persistente e causato dal codice del servizio anziché dalla piattaforma di hosting, è il momento di esaminare più da vicino il codice.
Ai fini di questo tutorial, è possibile assumere che il codice all'interno del contenitore e il codice nel sistema locale siano identici.
Rivedi l'analisi dello stack del report sugli errori e esegui il confronto con il codice per trovare le righe specifiche in cui si è verificato l'errore.
Node.js
Individua l'origine del messaggio di errore nel fileindex.js
intorno al numero di riga indicato nella analisi dello stack mostrata nei log:
Python
Individua l'origine del messaggio di errore nel filemain.py
intorno al numero di riga indicato nella analisi dello stack mostrata nei log:
Vai
Individua l'origine del messaggio di errore nel file main.go
intorno al numero di riga indicato nella analisi dello stack mostrata nei log:
Java
Individua la fonte del messaggio di errore nel file App.java
intorno al numero di riga indicato nella analisi dello stack mostrata nei log:
Esaminando questo codice, quando la variabile di ambiente NAME
non è impostata vengono eseguite le seguenti azioni:
- Viene registrato un errore in Google Cloud Observability
- Viene inviata una risposta di errore HTTP
Il problema è causato da una variabile mancante, ma la causa principale è più specifica: la modifica del codice che aggiunge la dipendenza obbligatoria da una variabile di ambiente non includeva modifiche correlate agli script di deployment e alla documentazione dei requisiti di runtime.
Risolvere la causa principale
Ora che abbiamo raccolto il codice e identificato la potenziale causa principale, possiamo adottare le misure del caso per risolvere il problema.
Verifica se il servizio funziona localmente con l'ambiente
NAME
disponibile:Esegui il contenitore localmente con la variabile di ambiente aggiunta:
PORT=8080 && docker run --rm -e PORT=$PORT -p 9000:$PORT \ -e NAME="Local World!" \ gcr.io/PROJECT_ID/hello-service
Apri il browser e vai all'indirizzo http://localhost:9000
Visualizza "Hello Local World!" nella pagina
Modifica l'ambiente del servizio Cloud Run in esecuzione per includere questa variabile:
Esegui il comando di aggiornamento dei servizi per aggiungere una variabile di ambiente:
gcloud run services update hello-service \ --set-env-vars NAME=Override
Attendi qualche secondo mentre Cloud Run crea una nuova revisione in base alla revisione precedente con la nuova variabile di ambiente aggiunta.
Verifica che il servizio sia stato risolto:
- Vai all'URL del servizio Cloud Run nel browser.
- Nella pagina viene visualizzato il messaggio "Hello Override!".
- Verifica che non vengano visualizzati messaggi o errori imprevisti in Cloud Logging o Error Reporting.
Migliorare la velocità di risoluzione dei problemi futuri
In questo problema di produzione di esempio, l'errore era correlato alla configurazione operativa. Esistono modifiche al codice che ridurranno al minimo l'impatto di questo problema in futuro.
- Migliora il log degli errori in modo da includere dettagli più specifici.
- Anziché restituire un errore, il servizio deve eseguire il fallback a un valore predefinito sicuro. Se l'utilizzo di un valore predefinito rappresenta una modifica alla funzionalità normale, utilizza un messaggio di avviso per il monitoraggio.
Vediamo come rimuovere la variabile di ambiente NAME
come dipendenza obbligatoria.
Rimuovi il codice di gestione
NAME
esistente:Node.js
Python
Vai
Java
Aggiungi nuovo codice che imposta un valore alternativo:
Node.js
Python
Vai
Java
Esegui il test a livello locale ricostruendo ed eseguendo il container nei casi di configurazione interessati:
Node.js
docker build --tag gcr.io/PROJECT_ID/hello-service .
Python
docker build --tag gcr.io/PROJECT_ID/hello-service .
Vai
docker build --tag gcr.io/PROJECT_ID/hello-service .
Java
mvn compile jib:build
Verifica che la variabile di ambiente
NAME
funzioni ancora:PORT=8080 && docker run --rm -e PORT=$PORT -p 9000:$PORT \ -e NAME="Robust World" \ gcr.io/PROJECT_ID/hello-service
Verifica che il servizio funzioni senza la variabile
NAME
:PORT=8080 && docker run --rm -e PORT=$PORT -p 9000:$PORT \ gcr.io/PROJECT_ID/hello-service
Se il servizio non restituisce un risultato, verifica che la rimozione del codice nel primo passaggio non abbia rimosso righe aggiuntive, ad esempio quelle utilizzate per scrivere la risposta.
Esegui il deployment consultando la sezione Eseguire il deployment del codice.
Ogni deployment in un servizio crea una nuova revisione e avvia automaticamente il servizio quando è pronto.
Per cancellare le variabili di ambiente impostate in precedenza:
gcloud run services update hello-service --clear-env-vars
Aggiungi la nuova funzionalità per il valore predefinito alla copertura dei test automatici per il servizio.
Trovare altri problemi nei log
Potresti notare altri problemi nel visualizzatore log per questo servizio. Ad esempio, una chiamata di sistema non supportata viene visualizzata nei log come "Limitazione della sandbox del contenitore".
Ad esempio, a volte i servizi Node.js generano questo messaggio di log:
Container Sandbox Limitation: Unsupported syscall statx(0xffffff9c,0x3e1ba8e86d88,0x0,0xfff,0x3e1ba8e86970,0x3e1ba8e86a90). Please, refer to https://gvisor.dev/c/linux/amd64/statx for more information.
In questo caso, la mancanza di assistenza non influisce sul servizio di esempio hello-service.
Risoluzione dei problemi di Terraform
Per domande o risoluzione dei problemi relativi a Terraform, consulta la risoluzione dei problemi di convalida delle norme di Terraform o contatta l'assistenza Terraform.
Esegui la pulizia
Se hai creato un nuovo progetto per questo tutorial, eliminalo. Se hai utilizzato un progetto esistente e vuoi conservarlo senza le modifiche aggiunte in questo tutorial, elimina le risorse create per il tutorial.
Elimina il progetto
Il modo più semplice per eliminare la fatturazione è eliminare il progetto che hai creato per il tutorial.
Per eliminare il progetto:
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Eliminazione delle risorse dei tutorial
Elimina il servizio Cloud Run di cui hai eseguito il deployment in questo tutorial:
gcloud run services delete SERVICE-NAME
dove SERVICE-NAME è il nome del servizio scelto.
Puoi anche eliminare i servizi Cloud Run dalla console Google Cloud.
Rimuovi la configurazione della regione predefinita di gcloud che hai aggiunto durante la configurazione del tutorial:
gcloud config unset run/region
Rimuovi la configurazione del progetto:
gcloud config unset project
Elimina le altre risorse Google Cloud create in questo tutorial:
- Elimina l'immagine container denominata
gcr.io/<var>PROJECT_ID</var>/hello-service
da Container Registry.
- Elimina l'immagine container denominata
Passaggi successivi
- Scopri di più su come utilizzare Cloud Logging e Error Reporting per ottenere informazioni sul comportamento in produzione.
- Per ulteriori informazioni sulla risoluzione dei problemi di Cloud Run, consulta la guida alla risoluzione dei problemi.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.