Comunicazione tra servizi in una configurazione di microservizi

Last reviewed 2024-06-26 UTC

Questo documento è il terzo di una serie di quattro parti dedicata alla progettazione, alla costruzione e il deployment di microservizi. Questa serie descrive i vari elementi di un di microservizi. La serie include informazioni sui vantaggi e gli svantaggi del pattern dell'architettura di microservizi e come applicarlo.

  1. Introduzione ai microservizi
  2. Eseguire il refactoring di un monolite in microservizi
  3. Comunicazione tra servizi in una configurazione di microservizi (questo documento)
  4. Tracciamento distribuito in un'applicazione di microservizi

Questa serie è destinata a sviluppatori di applicazioni e architetti che progettano e implementare la migrazione per il refactoring di un'applicazione monolitica in una un'applicazione.

Questo documento descrive i compromessi tra la messaggistica asincrona e API sincrone nei microservizi. Il documento ti guida nella distruzione di un'applicazione monolitica e mostra come convertire una richiesta sincrona nell'applicazione originale al flusso asincrono nei nuovi servizi configurazione. Questa conversione include l'implementazione di transazioni distribuite tra i servizi di machine learning.

Applicazione di esempio

In questo documento viene utilizzata un'applicazione di e-commerce predefinita chiamata Online Boutique. L'applicazione implementa flussi di e-commerce di base come la navigazione articoli, l'aggiunta di prodotti a un carrello e il pagamento. L'applicazione include inoltre consigli e annunci basati sulla selezione dell'utente.

Separazione logica del servizio

In questo documento isoli il servizio di pagamento dal resto dei un'applicazione. Tutti i flussi nell'applicazione Online Boutique originale sono sincrono. Nell'applicazione sottoposta a refactoring, l'elaborazione del pagamento viene convertita un flusso asincrono. Pertanto, quando ricevi una richiesta di acquisto, invece di immediatamente, ci fornisce una "richiesta ricevuta" la conferma alle utente. In background, viene attivata una richiesta asincrona al pagamento per elaborare il pagamento.

Prima di trasferire i dati e la logica di pagamento in un nuovo servizio, devi isolare la logica e i dati di pagamento del monolite. Quando isoli i dati di pagamento e logica nel monolite, è più facile eseguire il refactoring del codice nello stesso codebase se ricevi limiti del servizio di pagamento errati (logica aziendale o dati).

I componenti dell'applicazione monolitica in questo documento sono già modularizzati, in modo da essere isolati tra loro. Se la tua applicazione ha interdipendenze più strette, è necessario isolare la logica di business e creare classi e moduli separati. Devi anche disaccoppiare qualsiasi database le dipendenze nelle proprie tabelle e creare classi di repository separate. Quando disaccoppia le dipendenze del database, possono esserci relazioni di chiave esterna tra le tabelle divise. Tuttavia, dopo aver completamente disaccoppiato il servizio, dal monolite, queste dipendenze cessano di esistere e il servizio interagisce esclusivamente tramite contratti API o RPC predefiniti.

Transazioni distribuite ed errori parziali

Dopo aver isolato il servizio e lo hai suddiviso dal monolite, viene eseguita una nel sistema monolitico originale viene distribuita tra più i servizi di machine learning. Nell'implementazione del monolite, la procedura di pagamento seguiva come mostrato nel diagramma seguente.

La sequenza di pagamento è distribuita tra più servizi.

Figura 1. Una sequenza della procedura di pagamento in un'implementazione monolite.

Nella figura 1, quando l'applicazione riceve un ordine di acquisto, il controller di pagamento chiama il servizio di pagamento e il servizio ordini per l'elaborazione pagamento e salva l'ordine. Se un passaggio ha esito negativo, della transazione può essere eseguito il rollback. Considera uno scenario di esempio in cui l'ordine è stata archiviata nella tabella degli ordini, ma il pagamento non va a buon fine. Nella In questo scenario, viene eseguito il rollback dell'intera transazione e la voce viene rimossa dalla tabella degli ordini.

Dopo aver disaccoppiato il pagamento nel proprio servizio, il flusso di pagamento modificato viene simile al seguente diagramma:

La procedura di pagamento comprende più servizi e database.

Figura 2. Una sequenza della procedura di pagamento dopo che il pagamento è stato disaccoppiato nel suo il proprio servizio.

Nella Figura 2, la transazione ora abbraccia più servizi e i loro database corrispondenti, quindi si tratta di una transazione distribuita. Alla ricezione di richiesta di ordine, il controller di pagamento salva i dettagli dell'ordine nella sua e chiama altri servizi per completare l'ordine. Questi servizi, come servizio di pagamento, possono utilizzare il proprio database locale per memorizzare i dettagli ordine.

Nell'applicazione monolitica, il sistema di database garantisce che l'ambiente le transazioni sono atomiche. Tuttavia, per impostazione predefinita, il sistema basato su microservizi ha un database separato per ogni servizio non ha una transazione globale che copra i diversi database. Poiché le transazioni non sono coordinato a livello centrale, un errore nell'elaborazione di un pagamento non esegue il rollback le modifiche di cui è stato eseguito il commit nel servizio di ordini. Di conseguenza, il sistema si trova incoerente.

I seguenti pattern sono comunemente utilizzati per gestire le transazioni distribuite:

  • Protocollo di commit in due fasi (2PC): Fanno parte di una famiglia di protocolli di consenso, Il PC a due coordina il commit di una transazione distribuita e mantiene atomicità, coerenza, isolamento, durabilità (ACID) garantiti. Il protocollo è suddiviso in fasi di preparazione e commit. Il commit di una transazione viene eseguito solo se tutti i partecipanti hanno votato. Se i partecipanti non raggiungono un consenso, l'intera transazione viene eseguito il rollback.
  • Saga: Il pattern Saga consiste nell'eseguire transazioni locali all'interno di ogni che compongono la transazione distribuita. Un evento è viene attivato al termine di ogni operazione riuscita o non riuscita. Tutti i microservizi coinvolti nella transazione distribuita sottoscrivono questi eventi. Se i seguenti microservizi ricevono un evento con esito positivo, eseguire l'operazione. In caso di errore, i microservizi precedenti completare le azioni di compensazione per annullare le modifiche. Saga offre un'esperienza coerente vista del sistema, garantendo che, al termine di tutti i passaggi, tutte le operazioni hanno avuto esito positivo azioni compensative annullare tutto il lavoro.

Consigliamo Saga per le transazioni di lunga durata. In un ambiente basato su microservizi, un'applicazione, ti aspetti le chiamate tra i servizi e le comunicazioni con sistemi diversi. Pertanto, è meglio progettare per la coerenza finale: riprova per recuperabili ed esporre eventi di compensazione che alla fine si modificano e non recuperabili.

Esistono vari modi per implementare una Saga, ad esempio è possibile usano motori di attività e flussi di lavoro come Apache Airflow o Apache Camel. Puoi anche scrivere i tuoi gestori di eventi utilizzando sistemi basati su Kafka, RabbitMQ o ActiveMQ.

L'applicazione Online Boutique utilizza il servizio di pagamento per orchestrare i servizi di pagamento, spedizione e notifica via email. Il servizio di pagamento gestisce anche il flusso di lavoro dell'attività e degli ordini. In alternativa alla creazione di un tuo motore del flusso di lavoro, puoi utilizzare un componente di terze parti come Zeebe. Zeebe offre una piattaforma basata su UI modeler. Consigliamo di valutare attentamente le scelte per lo strumento di orchestrazione di microservizi in base ai requisiti della tua applicazione. Questa scelta è una parte fondamentale dell'esecuzione e della scalabilità dei microservizi.

Applicazione con refactoring

Per abilitare le transazioni distribuite nell'applicazione sottoposta a refactoring, il servizio di pagamento gestisce la comunicazione tra il pagamento, la spedizione e il servizio email. Il modello generico Flusso di lavoro del Business Process Model and Notation (BPMN) usa la seguente procedura:

Le transazioni in un'applicazione sottoposta a refactoring seguono un flusso di lavoro BPMN.

Figura 3. Un flusso di lavoro degli ordini che aiuta a garantire le transazioni distribuite nei microservizi tipici.

Il diagramma precedente mostra il seguente flusso di lavoro:

  • Il servizio frontend riceve una richiesta di ordine, quindi procede nel seguente modo:
    • Invia gli articoli dell'ordine al servizio del carrello. Il servizio del carrello salva quindi i dettagli dell'ordine (Redis).
    • Reindirizza alla pagina di pagamento. Il servizio di pagamento estrae gli ordini dal servizio di carrello, imposta lo stato dell'ordine su Pending e chiede al cliente il pagamento.
    • Conferma che l'utente ha pagato. Una volta confermato, il servizio di pagamento comunica al servizio email di generare un'email di conferma e inviarla al cliente.
  • Il servizio di pagamento elabora successivamente la richiesta.
    • Se la richiesta di pagamento ha esito positivo, il servizio di pagamento aggiorna lo stato dell'ordine in Complete.
    • Se la richiesta di pagamento non va a buon fine, il servizio di pagamento avvia una transazione di compensazione.
      • La richiesta di pagamento è stata annullata.
      • Il servizio di pagamento modifica lo stato dell'ordine in Failed.
    • Se il servizio di pagamento non è disponibile, la richiesta scade dopo N secondi e il servizio di pagamento avvia una transazione di compensazione.
    • Il servizio di pagamento modifica lo stato dell'ordine in Failed.

Obiettivi

  • Esegui il deployment dell'applicazione monolitica Online Boutique su Google Kubernetes Engine (GKE).
  • Convalida il flusso di pagamento monolitico.
  • Esegui il deployment della versione dei microservizi dell'applicazione monolitica sottoposta a refactoring
  • Verifica che il nuovo flusso di pagamento funzioni.
  • Verifica che le azioni di transazione distribuita e di compensazione funzionino nel caso in cui se si verifica un errore.

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. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Al termine di questo documento, per evitare che la fatturazione continui eliminando il le risorse che hai creato. Per maggiori informazioni, vedi Pulizia.

Prima di iniziare

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Make sure that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  4. Abilita le API per Compute Engine, Google Kubernetes Engine, Cloud SQL, Artifact Analysis e Container Registry:

     gcloud services enable \
     compute.googleapis.com \
     sql-component.googleapis.com \
     servicenetworking.googleapis.com\
     container.googleapis.com \
     containeranalysis.googleapis.com \
     containerregistry.googleapis.com \
     sqladmin.googleapis.com

  5. Esporta le seguenti variabili di ambiente:

    export PROJECT=$(gcloud config get-value project)
export CLUSTER=$PROJECT-gke
export REGION="us-central1"

Esegui il deployment del monolite e-commerce

In questa sezione eseguirai il deployment dell'applicazione monolitica Online Boutique in una cluster GKE. L'applicazione utilizza Cloud SQL come relazionale. Il seguente diagramma illustra il modello dell'applicazione:

Un'applicazione utilizza un'architettura monolitica.

Figura 4. Un client si connette all'applicazione in un e l'applicazione si connette a un database Cloud SQL.

Per eseguire il deployment dell'applicazione, completa questi passaggi:

  1. Clona il repository GitHub:

    git clone https://github.com/GoogleCloudPlatform/monolith-to-microservices-example

  2. Sostituisci il segnaposto PROJECT_ID nel manifest delle variabili Terraform file:

    cd monolith-to-microservices-example/setup && \
sed -i -e "s/\[PROJECT_ID\]/$PROJECT/g" terraform.tfvars

  3. Esegui gli script Terraform per completare la configurazione e il deployment dell'infrastruttura dell'infrastruttura. Per saperne di più su Terraform, consulta Introduzione a Terraform su Google Cloud:

    terraform init && terraform apply -auto-approve

    Lo script Terraform crea quanto segue:

    • Una rete VPC denominata PROJECT_ID-vpc
    • Cluster GKE denominato PROJECT_ID-gke
    • Un'istanza Cloud SQL denominata PROJECT_ID-mysql
      • Un database denominato ecommerce utilizzato dall'applicazione
      • Un utente root con la password impostata su password

    Puoi modificare lo script Terraform per generare automaticamente una password. Questa configurazione utilizza un esempio semplificato da non utilizzare in produzione.

    Il provisioning dell'infrastruttura può richiedere fino a 10 minuti. Quando lo script viene riuscito, l'output sarà simile al seguente:

    ...

Apply complete! Resources: 8 added, 0 changed, 0 destroyed.

Outputs:

kubernetes_cluster_name = PROJECT_ID-gke
sql_database_name = PROJECT_ID-mysql
vpc_name = PROJECT_ID-vpc

  4. Connettiti al cluster e crea uno spazio dei nomi denominato monolith. Tu il deployment dell'applicazione nel proprio spazio di GKE cluster:

    gcloud container clusters get-credentials $CLUSTER \
   --region $REGION \
   --project $PROJECT && \
   kubectl create ns monolith

  5. L'applicazione in esecuzione su GKE utilizza Secret di Kubernetes per accedere al database Cloud SQL. Crea un secret che utilizza credenziali utente per il database:

    kubectl create secret generic dbsecret \
  --from-literal=username=root \
  --from-literal=password=password -n monolith

  6. Crea l'immagine monolite e caricala su Container Registry:

    cd ~/monolith
gcloud builds submit --tag gcr.io/$PROJECT_ID/ecomm

  7. Aggiorna il riferimento nel file deploy.yaml con l'immagine Docker appena creata:

    cd ~/monolith
sed -i -e "s/\[PROJECT_ID\]/$PROJECT/g" deploy.yaml

  8. Sostituisci i segnaposto nei file manifest di deployment, quindi esegui il deployment applicazione:

    cd .. && \
DB_IP=$(gcloud sql instances describe $PROJECT-mysql | grep "ipAddress:" | tail -1 | awk -F ":" '{print $NF}')

sed -i -e "s/\[DB_IP\]/$DB_IP/g" monolith/deploy.yaml
kubectl apply -f monolith/deploy.yaml

  9. Controlla lo stato del deployment:

    kubectl rollout status deployment/ecomm -n monolith

    L'output è simile al seguente.

    Waiting for deployment "ecomm" rollout to finish: 0 of 1 updated replicas are available...
deployment "ecomm" successfully rolled out

  10. Ottieni l'indirizzo IP dell'applicazione di cui è stato eseguito il deployment:

    kubectl get svc ecomm -n monolith \
        -o jsonpath="{.status.loadBalancer.ingress[*].ip}" -w

    Attendi che l'indirizzo IP del bilanciatore del carico venga pubblicato. Per uscire dal comando, premi Ctrl+C. Prendi nota dell'indirizzo IP del bilanciatore del carico e accedi all'URL http://IP_ADDRESS. L'operazione potrebbe occorre attendere un po' di tempo prima che il bilanciatore del carico diventi integro e inizi a trasferire il traffico.

Convalidare il flusso di pagamento del monolite

In questa sezione, creerai un ordine di prova per convalidare il flusso di pagamento.

  1. Vai all'URL che hai annotato nella sezione precedente. http://IP_ADDRESS.
  2. Nella home page dell'applicazione che viene visualizzata, seleziona un prodotto e poi fai clic su Aggiungi al carrello.
  3. Per creare un acquisto di prova, fai clic su Effettua l'ordine:
  4. Se il pagamento va a buon fine, viene visualizzata la finestra di conferma dell'ordine. mostra un ID conferma dell'ordine.

  5. Per visualizzare i dettagli dell'ordine, connettiti al database:

    gcloud sql connect $PROJECT-mysql --user=root

    Puoi anche utilizzare qualsiasi altro metodo supportato per la connessione al database. Quando richiesto, inserisci la password come password.

  6. Per visualizzare i dettagli degli ordini salvati, esegui questo comando:

    select cart_id from ecommerce.cart;

  7. L'output è simile al seguente:

    +--------------------------------------+
| cart_id                              |
+--------------------------------------+
| 7cb9ab11-d268-477f-bf4d-4913d64c5b27 |
+--------------------------------------+

Esegui il deployment dell'applicazione di e-commerce basata su microservizi

In questa sezione eseguirai il deployment dell'applicazione sottoposta a refactoring. Solo questo documento è incentrato sul disaccoppiamento dei servizi di frontend e di pagamento. Il prossimo documento serie, Tracciamento distribuito in un'applicazione di microservizi, descrivono altri servizi, come consigli e servizi pubblicitari, che puoi disaccoppiarlo dal monolite. Il servizio di pagamento gestisce le transazioni distribuite tra il frontend e i servizi di pagamento, il cui deployment viene eseguito come servizio Kubernetes Cluster GKE, come mostrato nel diagramma seguente:

I servizi di frontend e di pagamento sono disaccoppiati dal monolite.

Figura 5. Il servizio di pagamento orchestra transazioni tra carrello, pagamento e servizi email.

esegui il deployment dei microservizi

In questa sezione viene utilizzata l'infrastruttura di cui hai eseguito il provisioning esegui il deployment di microservizi nel relativo spazio dei nomi microservice:

  1. Assicurati di soddisfare i seguenti requisiti:

    • Progetto Google Cloud
    • Ambiente shell con gcloud, git e kubectl

  2. In Cloud Shell, clona il repository di microservizi:

    git clone https://github.com/GoogleCloudPlatform/microservices-demo
cd microservices-demo/

  3. Imposta il progetto e la regione Google Cloud e assicurati che L'API GKE è abilitata:

    export PROJECT_ID=PROJECT_ID
export REGION=us-central1
gcloud services enable container.googleapis.com \
--project=${PROJECT_ID}

    Sostituisci PROJECT_ID con l'ID di del tuo progetto Google Cloud.

  4. Crea un cluster GKE e recupera le credenziali:

    gcloud container clusters create-auto online-boutique \
    --project=${PROJECT_ID} --region=${REGION}

    La creazione del cluster potrebbe richiedere alcuni minuti.

  5. Esegui il deployment di microservizi nel cluster:

    kubectl apply -f ./release/kubernetes-manifests.yaml

  6. Attendi che i pod siano pronti:

    kubectl get pods

    Dopo alcuni minuti, vedrai i pod in stato Running.

  7. Accedi al frontend web in un browser utilizzando l'indirizzo IP esterno del frontend:

    kubectl get service frontend-external | awk '{print $4}'

    Visita http://EXTERNAL_IP in un browser web per accedere alla tua istanza di Online Boutique.

Convalidare il nuovo flusso di pagamento

  1. Per verificare il flusso della procedura di pagamento, seleziona un prodotto e inserisci come descritto nella sezione precedente Convalida il flusso di pagamento del monolite.
  2. Una volta completato il pagamento, la finestra di conferma mostrare un ID di conferma. La finestra di conferma ti indirizza invece controlla la tua email per i dettagli di conferma.

  3. Per verificare che l'ordine sia stato ricevuto, che il servizio di pagamento elaborato il pagamento e che i dettagli dell'ordine siano stati aggiornati, esegui seguente comando:

    kubectl logs -f deploy/checkoutservice --tail=100

    L'output è simile al seguente:

    [...]
{"message":"[PlaceOrder] user_id=\"98828e7a-b2b3-47ce-a663-c2b1019774a3\" user_currency=\"CAD\"","severity":"info","timestamp":"2023-08-10T04:19:20.498893921Z"}
{"message":"payment went through (transaction_id: f0b4a592-026f-4b4a-9892-ce86d2711aed)","severity":"info","timestamp":"2023-08-10T04:19:20.528338189Z"}
{"message":"order confirmation email sent to \"someone@example.com\"","severity":"info","timestamp":"2023-08-10T04:19:20.540275988Z"}

    Per uscire dai log, premi Ctrl+C.

  4. Verifica che il pagamento sia andato a buon fine:

    kubectl logs -f deploy/paymentservice -n --tail=100

    L'output è simile al seguente:

    [...]
{"severity":"info","time":1691641282208,"pid":1,"hostname":"paymentservice-65cc7795f6-r5m8r","name":"paymentservice-charge","message":"Transaction processed: visa ending 0454     Amount: CAD119.30128260"}
{"severity":"info","time":1691641300051,"pid":1,"hostname":"paymentservice-65cc7795f6-r5m8r","name":"paymentservice-server","message":"PaymentService#Charge invoked with request {\"amount\":{\"currency_code\":\"USD\",\"units\":\"137\",\"nanos\":850000000},\"credit_card\":{\"credit_card_number\":\"4432-8015-6152-0454\",\"credit_card_cvv\":672,\"credit_card_expiration_year\":2039,\"credit_card_expiration_month\":1}}"}

    Per uscire dai log, premi Ctrl+C.

  5. Verifica di aver inviato l'email di conferma dell'ordine:

    kubectl logs -f deploy/emailservice -n --tail=100

    L'output è simile al seguente:

    [...]
{"timestamp": 1691642217.5026057, "severity": "INFO", "name": "emailservice-server", "message": "A request to send order confirmation email to kalani@examplepetstore.com has been received."}

    I messaggi di log per ogni microservizio indicano che la transazione distribuita i servizi di pagamento, email e pagamento sono stati completati correttamente.

Convalida dell'azione di compensazione in una transazione distribuita

Questa sezione simula uno scenario in cui un cliente effettua un ordine il servizio di pagamento non è disponibile.

  1. Per simulare l'indisponibilità del servizio, elimina il deployment del pagamento e servizio:

    kubectl delete deploy paymentservice && \
kubectl delete svc paymentservice

  2. Accedi di nuovo all'applicazione e completa il flusso di pagamento. In questo Ad esempio, se il servizio di pagamento non risponde, la richiesta si verifica un timeout e viene attivata un'azione di compensazione.

  3. Nel frontend dell'interfaccia utente, fai clic sul pulsante Effettua ordine. L'output è simile al seguente:

    HTTP Status: 500 Internal Server Error
rpc error: code = Internal desc = failed to charge card: could not charge the card: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp: lookup paymentservice on 34.118.224.10:53: no such host"
failed to complete the order
main.(*frontendServer).placeOrderHandler
    /src/handlers.go:360

  4. Esamina i log del servizio frontend:

    kubectl logs -f deploy/frontend --tail=100

    L'output è simile al seguente:

    [...]
{"error":"failed to complete the order: rpc error: code = Internal desc = failed to charge card: could not charge the card: rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp: lookup paymentservice on 34.118.224.10:53: no such host\"","http.req.id":"0a4cb058-ee9b-470a-9bb1-3a965636022e","http.req.method":"POST","http.req.path":"/cart/checkout","message":"request error","session":"96c94881-a435-4490-9801-c788dc400cc1","severity":"error","timestamp":"2023-08-11T18:25:47.127294259Z"}

  5. Esamina i log del servizio di pagamento:

    kubectl logs -f deploy/frontend --tail=100

    L'output è simile al seguente:

    [...]
{"message":"[PlaceOrder] user_id=\"96c94881-a435-4490-9801-c788dc400cc1\" user_currency=\"USD\"","severity":"info","timestamp":"2023-08-11T18:25:46.947901041Z"}
{"message":"[PlaceOrder] user_id=\"96c94881-a435-4490-9801-c788dc400cc1\" user_currency=\"USD\"","severity":"info","timestamp":"2023-08-11T19:54:21.796343643Z"}

    Tieni presente che non c'è alcuna chiamata successiva al servizio email da inviare notifica. Non è presente alcun log delle transazioni, payment went through (transaction_id: 06f0083f-fa47-4d91-8258-6d61edfab1ca).

  6. Esamina i log del servizio email:

    kubectl logs -f deploy/emailservice --tail=100

    Tieni presente che non sono presenti voci di log create per la transazione non riuscita nel servizio email.

In qualità di agente di orchestrazione, se una chiamata al servizio non va a buon fine, il servizio di pagamento restituisce uno stato di errore e chiude la procedura di pagamento.

Esegui la pulizia

Se prevedi di completare i passaggi nel prossimo documento di questa serie, Tracciamento distribuito in un'applicazione di microservizi, puoi riutilizzare il progetto e le risorse anziché eliminarli.

Elimina il progetto

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Elimina le risorse

Se vuoi conservare il progetto Google Cloud che hai utilizzato in questo documento, le singole risorse.

  1. In Cloud Shell, esegui questo comando:

    cd setup && terraform destroy -auto-approve

  2. Per eliminare il cluster di microservizi utilizzando Google Cloud CLI, esegui questo comando:

    gcloud container clusters delete online-boutique \
    --location $REGION

Passaggi successivi