Gestione dell'infrastruttura come codice con Terraform, Cloud Build e GitOps

Questo tutorial spiega come gestire l'infrastruttura come codice con Terraform e Cloud Build utilizzando la popolare metodologia GitOps. Il termine GitOps è stato coniato per la prima volta da Weaveworks e il suo concetto chiave è l'utilizzo di un repository Git per archiviare lo stato dell'ambiente desiderato. Terraform è uno strumento open source HashiCorp che ti consente di creare, modificare e migliorare in modo prevedibile la tua infrastruttura cloud utilizzando il codice. In questo tutorial utilizzerai Cloud Build, un servizio di integrazione continua di Google Cloud, per applicare automaticamente i manifest di Terraform al tuo ambiente.

Questo tutorial è destinato a sviluppatori e operatori che cercano una strategia elegante per apportare modifiche prevedibili all'infrastruttura. L'articolo presuppone che tu conosca Google Cloud, Linux e GitHub.

I report State of DevOps hanno identificato funzionalità che migliorano le prestazioni di distribuzione del software. Questo tutorial ti aiuterà con le seguenti funzionalità:

Architettura

Per dimostrare come questo tutorial applica le pratiche GitOps per la gestione delle esecuzioni Terraform, valuta il seguente diagramma di architettura. Tieni presente che utilizza i rami GitHub, dev e prod, per rappresentare gli ambienti effettivi. Questi ambienti sono definiti dalle reti virtual private cloud (VPC) dev e prod in un progetto Google Cloud.

Infrastruttura con ambienti di sviluppo e produzione.

Il processo inizia quando esegui il push del codice Terraform nel ramo dev o prod. In questo scenario, Cloud Build attiva e applica i manifest Terraform per ottenere lo stato desiderato nel rispettivo ambiente. D'altra parte, quando esegui il push del codice Terraform in qualsiasi altro ramo, ad esempio in un ramo di funzionalità, Cloud Build viene eseguito per eseguire terraform plan, ma non viene applicato nulla a nessun ambiente.

Idealmente, gli sviluppatori o gli operatori devono creare proposte di infrastruttura per rami non protetti e poi inviarle tramite richieste di pull. L'app GitHub di Cloud Build, di cui parleremo più tardi in questo tutorial, attiva automaticamente i job di build e collega i report terraform plan a queste richieste di pull. In questo modo, puoi esaminare ed esaminare le potenziali modifiche con i collaboratori e aggiungere gli impegni di follow-up prima che le modifiche vengano unite nel ramo di base.

In caso di dubbi, devi prima unire le modifiche al ramo dev. Questa unione attiva un deployment dell'infrastruttura nell'ambiente dev, consentendoti di testare questo ambiente. Dopo aver testato e verificato il deployment, devi unire il ramo dev nel ramo prod per attivare l'installazione dell'infrastruttura nell'ambiente di produzione.

Obiettivi

  • Configura il tuo repository GitHub.
  • Configura Terraform per archiviare lo stato in un bucket Cloud Storage.
  • Concedi le autorizzazioni al tuo account di servizio Cloud Build.
  • Connetti Cloud Build al repository GitHub.
  • Modifica la configurazione dell'ambiente in un ramo di funzionalità.
  • Promuovere modifiche all'ambiente di sviluppo.
  • Promuovere le modifiche all'ambiente di produzione.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prerequisiti

  1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

  2. Nella console di Google Cloud Console, nella pagina del selettore dei progetti, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  3. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  4. Nella console di Google Cloud Console, nella pagina del selettore dei progetti, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  5. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  6. In Google Cloud Console, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore di Google Cloud Console, viene avviata una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  7. In Cloud Shell, recupera l'ID del progetto appena selezionato: 
    gcloud config get-value project
    Se questo comando non restituisce l'ID progetto, configura Cloud Shell in modo che utilizzi il progetto. Sostituisci PROJECT_ID con l'ID progetto. 
    gcloud config set project PROJECT_ID
  8. Abilita le API richieste: 
    gcloud services enable cloudbuild.googleapis.com compute.googleapis.com
    Il completamento di questo passaggio potrebbe richiedere alcuni minuti.
  9. Se non hai mai utilizzato Git in Cloud Shell, configuralo con il tuo nome e indirizzo email: 
    git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
    Git utilizza queste informazioni per identificarti come autore dei commit che crei in Cloud Shell.

Configurazione del repository GitHub

In questo tutorial utilizzerai un singolo repository Git per definire l'infrastruttura cloud. Per orchestrare questa infrastruttura, sono presenti rami diversi corrispondenti ad ambienti diversi:

  • Il ramo dev contiene le ultime modifiche applicate all'ambiente di sviluppo.
  • Il ramo prod contiene le ultime modifiche applicate all'ambiente di produzione.

Con questa infrastruttura, puoi sempre fare riferimento al repository per sapere quale configurazione è prevista in ogni ambiente e proporre nuove modifiche unendole prima nell'ambiente dev. Poi, promuovi le modifiche unendo il ramo dev nel ramo prod successivo.

Per iniziare, crea un fork del repository solutions-terraform-cloudbuild-gitops.

  1. Su GitHub, vai a https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git.

  2. Nell'angolo in alto a destra della pagina, fai clic su Fork.

    Fork di un repository.

    Ora hai una copia del repository solutions-terraform-cloudbuild-gitops con i file di origine.

  3. In Cloud Shell, clona questo repository creato con fork, sostituendo YOUR_GITHUB_USERNAME con il tuo nome utente GitHub:

    cd ~
git clone https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops.git
cd ~/solutions-terraform-cloudbuild-gitops

Il codice in questo repository è strutturato come segue:

  • La cartella environments/ contiene sottocartelle che rappresentano gli ambienti, come dev e prod, che forniscono una separazione logica tra i carichi di lavoro rispettivamente in diverse fasi di maturità, sviluppo e produzione. Anche se è buona pratica che questi ambienti siano simili come possibili, ogni sottocartella ha la propria configurazione Terraform per garantire che possano avere impostazioni univoche in base alle esigenze.

  • La cartella modules/ contiene moduli Terraform in linea. Questi moduli rappresentano raggruppamenti logici di risorse correlate e vengono utilizzati per condividere il codice in diversi ambienti.

  • Il file cloudbuild.yaml è un file di configurazione di compilazione che contiene istruzioni per Cloud Build, ad esempio come eseguire attività sulla base di un insieme di passaggi. Questo file specifica un'esecuzione condizionale a seconda del ramo da cui Cloud Build sta recuperando il codice, ad esempio:

    • Per i rami dev e prod, vengono eseguiti i seguenti passaggi:

      1. terraform init
      2. terraform plan
      3. terraform apply

    • Per qualsiasi altro ramo, vengono eseguiti i seguenti passaggi:

      1. terraform init per tutte le environments sottocartelle
      2. terraform plan per tutte le environments sottocartelle

Per garantire che le modifiche proposte siano appropriate per ogni ambiente, terraform init e terraform plan vengono eseguite per tutte le sottocartelle environments. Prima di unire la richiesta di pull, puoi rivedere i piani per assicurarti che l'accesso non venga concesso a un'entità non autorizzata, ad esempio.

Configurazione di Terraform per archiviare lo stato in un bucket Cloud Storage

Per impostazione predefinita, Terraform archivia lo stato localmente in un file denominato terraform.tfstate. Questa configurazione predefinita può rendere difficile l'utilizzo di Terraform per i team, in particolare quando molti utenti eseguono contemporaneamente Terraform e ogni macchina ha una propria comprensione dell'infrastruttura attuale.

Per aiutarti a evitare problemi di questo tipo, questa sezione configura uno stato remoto che rimanda a un bucket Cloud Storage. Lo stato remoto è una funzionalità dei backend e, in questo tutorial, viene configurato nei file backend.tf, ad esempio:

ambienti/dev/backend.tf 
# Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate"
    prefix = "env/dev"
  }
}

Nei passaggi seguenti, creerai un bucket Cloud Storage e modificherai alcuni file in modo che rimandino al nuovo bucket e al tuo progetto Google Cloud.

  1. In Cloud Shell, crea il bucket Cloud Storage:

    PROJECT_ID=$(gcloud config get-value project)
gsutil mb gs://${PROJECT_ID}-tfstate

  2. Abilita il controllo delle versioni degli oggetti per conservare la cronologia dei deployment:

    gsutil versioning set on gs://${PROJECT_ID}-tfstate

    L'attivazione del controllo delle versioni degli oggetti aumenta i costi di archiviazione, che puoi mitigare configurando la gestione del ciclo di vita degli oggetti per eliminare le versioni precedenti.

  3. Sostituisci il segnaposto PROJECT_ID con l'ID progetto nei file terraform.tfvars e backend.tf:

    cd ~/solutions-terraform-cloudbuild-gitops
sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf

    Su OS X/MacOS, potresti dover aggiungere due virgolette ("") dopo sed -i, in questo modo:

    cd ~/solutions-terraform-cloudbuild-gitops
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf

  4. Controlla se tutti i file sono stati aggiornati:

    git status

    L'output ha il seguente aspetto:

    On branch dev
Your branch is up-to-date with 'origin/dev'.
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)
       modified:   environments/dev/backend.tf
       modified:   environments/dev/terraform.tfvars
       modified:   environments/prod/backend.tf
       modified:   environments/prod/terraform.tfvars
no changes added to commit (use "git add" and/or "git commit -a")

  5. Esegui il commit e il push delle modifiche:

    git add --all
git commit -m "Update project IDs and buckets"
git push origin dev

    A seconda della configurazione GitHub, dovrai eseguire l'autenticazione per eseguire il push delle modifiche precedenti.

Concessione delle autorizzazioni per l'account di servizio Cloud Build

Per consentire all'account di servizio Cloud Build di eseguire script Terraform con l'obiettivo di gestire le risorse Google Cloud, devi concedere l'accesso appropriato al tuo progetto. Per semplicità, l'accesso come editor di progetto è concesso in questo tutorial. Tuttavia, quando il ruolo di Editor di progetto dispone di un'autorizzazione ad ampio raggio, in ambienti di produzione devi seguire le best practice per la sicurezza IT della tua azienda, in genere fornendo accesso con privilegi minimi.

  1. In Cloud Shell, recupera l'email per l'account di servizio Cloud Build del tuo progetto:

    CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \
    --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com"

  2. Concedi l'accesso richiesto al tuo account di servizio Cloud Build:

    gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:$CLOUDBUILD_SA --role roles/editor

Connessione diretta di Cloud Build al tuo repository GitHub

Questa sezione mostra come installare l'app GitHub di Cloud Build. Questa installazione consente di connettere il repository GitHub al tuo progetto Google Cloud in modo che Cloud Build possa applicare automaticamente i manifest di Terraform ogni volta che crei un nuovo ramo o push di codice a GitHub.

La procedura seguente fornisce le istruzioni per installare l'app solo per il repository solutions-terraform-cloudbuild-gitops, ma puoi scegliere di installare l'app per più o tutti i repository.

  1. Vai alla pagina GitHub Marketplace per l'app Cloud Build:

    Apri la pagina dell'app Cloud Build

    • Se è la prima volta che configuri un'app in GitHub: Fai clic su Configura con Google Cloud Build in fondo alla pagina. Quindi, fai clic su Concedi a questa app l'accesso al tuo account GitHub.
    • Se non è la prima volta che configuri un'app in GitHub: Fai clic su Configura accesso. Si apre la pagina Applicazioni del tuo account personale.

  2. Fai clic su Configura nella riga Cloud Build.

  3. Seleziona Seleziona solo i repository, quindi seleziona solutions-terraform-cloudbuild-gitops per connetterti al repository.

  4. Fai clic su Salva o Installa: l'etichetta del pulsante cambia a seconda del flusso di lavoro. Il sistema ti reindirizzerà a Google Cloud per continuare l'installazione.

  5. Accedi con il tuo account Google Cloud. Se richiesto, autorizza l'integrazione di Cloud Build con GitHub.

  6. Nella pagina Cloud Build, seleziona il progetto. Viene visualizzata una procedura guidata.

  7. Nella sezione Seleziona repository, seleziona il tuo account GitHub e il repository solutions-terraform-cloudbuild-gitops.

  8. Se accetti i Termini e condizioni, seleziona la casella di controllo e poi fai clic su Connetti.

  9. Nella sezione Crea un trigger, fai clic su Crea un trigger:

    1. Aggiungi un nome attivatore, ad esempio push-to-branch. Prendi nota del nome di questo trigger che ti servirà in un secondo momento.
    2. Nella sezione Evento, seleziona Push al ramo.
    3. Nella sezione Origine, seleziona .* nel campo Ramo.
    4. Fai clic su Crea.

L'app GitHub di Cloud Build è ora configurata e il tuo repository GitHub è collegato al tuo progetto Google Cloud. D'ora in poi, le modifiche al repository GitHub attivano le esecuzioni di Cloud Build, che segnalano i risultati a GitHub utilizzando i controlli GitHub.

Modifica della configurazione dell'ambiente in un nuovo ramo di funzionalità

A questo punto, hai configurato la maggior parte del tuo ambiente. È ora di apportare alcune modifiche al codice nel tuo ambiente di sviluppo.

  1. Su GitHub, vai alla pagina principale del tuo repository creato con fork.

    https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

  2. Assicurati di trovarti nel ramo dev.

  3. Per aprire il file da modificare, vai al file modules/firewall/main.tf e fai clic sull'icona a forma di matita.

  4. Nella riga 30, correggi l'errore di ortografia "http-server2" nel campo target_tags.

    Il valore deve essere "http-server".

  5. Aggiungi un messaggio di commit in fondo alla pagina, ad esempio "Correzione del target http" di firewall, quindi seleziona Crea un nuovo ramo per questo commit e avvia una richiesta di pull.

  6. Fai clic su Proponi modifiche.

  7. Nella pagina seguente, fai clic su Crea richiesta di pull per aprire una nuova richiesta di pull con la tua modifica.

    Una volta aperta la richiesta di pull, viene avviato automaticamente un job Cloud Build.

  8. Fai clic su Mostra tutti i controlli e attendi che l'assegno diventi verde.

    Mostra tutti i controlli in una richiesta di pull.

  9. Fai clic su Dettagli per visualizzare ulteriori informazioni, incluso l'output del terraform plan al link Visualizza maggiori dettagli su Google Cloud Build.

Non unire ancora la tua richiesta di pull.

Tieni presente che il job Cloud Build ha eseguito la pipeline definita nel file cloudbuild.yaml. Come discusso in precedenza, questa pipeline ha un comportamento diverso a seconda del ramo recuperato. La build controlla se la variabile $BRANCH_NAME corrisponde a qualsiasi cartella dell'ambiente. In questo caso, Cloud Build esegue terraform plan per quell'ambiente. In caso contrario, Cloud Build esegue terraform plan per tutti gli ambienti per assicurarsi che la modifica proposta sia appropriata per tutti gli ambienti. Se uno di questi piani non viene eseguito, la build non riesce.

cloudbuild.yaml 
- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

Allo stesso modo, il comando terraform apply viene eseguito per i rami dell'ambiente, ma viene ignorato completamente in ogni altro caso. In questa sezione hai inviato una modifica del codice a un nuovo ramo, quindi non è stato applicato alcun deployment di infrastruttura al tuo progetto Google Cloud.

cloudbuild.yaml 
- id: 'tf apply'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform apply -auto-approve
      else
        echo "***************************** SKIPPING APPLYING *******************************"
        echo "Branch '$BRANCH_NAME' does not represent an official environment."
        echo "*******************************************************************************"
      fi

Applicazione del successo dell'esecuzione di Cloud Build prima dell'unione dei rami

Per assicurarti che le unioni possano essere applicate solo quando le rispettive esecuzioni di Cloud Build hanno esito positivo, procedi come segue:

  1. Su GitHub, vai alla pagina principale del tuo repository creato con fork.

    https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

  2. Sotto il nome del repository, fai clic su Impostazioni.

  3. Nel menu a sinistra, fai clic su Ramo.

  4. In Bra Protection rules (Regole per la protezione del ramo), fai clic su Add Rule (Aggiungi regola).

  5. In Pattern nome ramo, digita dev.

  6. Nella sezione Proteggi i rami corrispondenti, seleziona Richiedi che i controlli dello stato vengano superati prima dell'unione.

  7. Cerca il nome del trigger di Cloud Build creato in precedenza.

  8. Fai clic su Crea.

  9. Ripeti i passaggi da 3 a 7, impostando Ramo name pattern su prod.

Questa configurazione è importante per proteggere sia i rami dev che prod. In altri termini, i commit devono essere trasferiti a un altro ramo, ma solo dopo possono essere uniti al ramo protetto. In questo tutorial, la protezione richiede che l'esecuzione di Cloud Build sia riuscita per consentire l'unione.

Promozione delle modifiche all'ambiente di sviluppo

Hai una richiesta di pull in attesa di unione. È il momento di applicare lo stato che vuoi al tuo ambiente dev.

  1. Su GitHub, vai alla pagina principale del tuo repository creato con fork.

    https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

  2. Sotto il nome del repository, fai clic su Richieste di pull.

  3. Fai clic sulla richiesta di pull appena creata.

  4. Fai clic su Unisci richiesta di acquisto e poi su Conferma unione.

    Conferma unione.

  5. Verifica che sia stato attivato un nuovo Cloud Build:

    Vai alla pagina Cloud Build

  6. Apri la build e controlla i log.

    Al termine, verrà visualizzato un messaggio simile al seguente:

    Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
Step #3 - "tf apply": firewall_rule = dev-allow-http
Step #3 - "tf apply": instance_name = dev-apache2-instance
Step #3 - "tf apply": network = dev
Step #3 - "tf apply": subnet = dev-subnet-01

  7. Copia EXTERNAL_IP_VALUE e apri l'indirizzo in un browser web.

    http://EXTERNAL_IP_VALUE

    Il provisioning della VM potrebbe richiedere alcuni secondi per avviare la VM e propagare la regola firewall. Alla fine, vedrai Ambiente: sviluppatore nel browser web.

  8. Vai al tuo file di stato di Terraform nel tuo bucket Cloud Storage.

    https://storage.cloud.google.com/PROJECT_ID-tfstate/env/dev/default.tfstate

Promozione di modifiche all'ambiente di produzione

Ora che l'ambiente di sviluppo è stato completamente testato, puoi promuovere il codice dell'infrastruttura in produzione.

  1. Su GitHub, vai alla pagina principale del tuo repository creato con fork.

    https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

  2. Sotto il nome del repository, fai clic su Richieste di pull.

  3. Fai clic su Nuova richiesta di pull.

  4. Per il repository di base, seleziona il repository appena creato.

  5. Per base, seleziona prod dal tuo repository di base. Per confronta, seleziona dev.

    Confronta le modifiche.

  6. Fai clic su Crea richiesta di pull.

  7. In title, inserisci un titolo come Promoting networking changes, quindi fai clic su Crea richiesta di pull.

  8. Esamina le modifiche proposte, compresi i dettagli terraform plan di Cloud Build, quindi fai clic su Unisci richiesta di pull.

  9. Fai clic su Conferma unione.

  10. Nella console Google Cloud, apri la pagina Cronologia build per vedere le modifiche applicate all'ambiente di produzione:

    Vai alla pagina Cloud Build

  11. Attendi il completamento della build, quindi controlla i log.

    Alla fine dei log, viene visualizzato il seguente esempio:

    Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
Step #3 - "tf apply": firewall_rule = prod-allow-http
Step #3 - "tf apply": instance_name = prod-apache2-instance
Step #3 - "tf apply": network = prod
Step #3 - "tf apply": subnet = prod-subnet-01

  12. Copia EXTERNAL_IP_VALUE e apri l'indirizzo in un browser web.

    http://EXTERNAL_IP_VALUE

    Il provisioning della VM potrebbe richiedere alcuni secondi per avviare la VM e propagare la regola firewall. Alla fine, vedrai Ambiente: produzione nel browser web.

  13. Vai al tuo file di stato di Terraform nel tuo bucket Cloud Storage.

    https://storage.cloud.google.com/PROJECT_ID-tfstate/env/prod/default.tfstate

Hai configurato correttamente una pipeline Infrastructure as Code serverless su Cloud Build. In futuro, prova a procedere nel seguente modo:

  • Aggiungi deployment per casi d'uso distinti.
  • Crea ambienti aggiuntivi per riflettere le tue esigenze.
  • Utilizza un progetto per ambiente anziché un VPC per ambiente.

Esegui la pulizia

Dopo aver completato il tutorial, pulisci le risorse che hai creato in Google Cloud, in modo che non ti vengano più fatturati.

Elimina il progetto

  1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Eliminazione del repository GitHub

Per evitare di bloccare nuove richieste di pull sul tuo repository GitHub, puoi eliminare le tue regole di protezione del ramo:

  1. In GitHub, vai alla pagina principale del repository creato con fork.
  2. Sotto il nome del repository, fai clic su Impostazioni.
  3. Nel menu a sinistra, fai clic su Ramo.
  4. Nella sezione Regole per la protezione del ramo, fai clic sul pulsante Elimina per entrambe le righe dev e prod.

Facoltativamente, puoi disinstallare completamente l'app Cloud Build da GitHub:

  1. Vai alle impostazioni Applicazioni di GitHub.

    Vai alla pagina delle applicazioni GitHub

  2. Nella scheda App GitHub installate, fai clic su Configura nella riga Cloud Build. Nella sezione Zona pericolosa, fai clic sul pulsante Disinstalla nella riga Disinstalla Google Cloud Builder.

    Nella parte superiore della pagina viene visualizzato il messaggio "È tutto pronto. È stato messo in coda un job per disinstallare Google Cloud Build."

  3. Nella scheda App GitHub autorizzate, fai clic sul pulsante Revoca nella riga Google Cloud Build, quindi su Ho capito, revoca l'accesso nel popup.

Se non vuoi conservare il repository GitHub:

  1. In GitHub, vai alla pagina principale del tuo repository creato con fork.
  2. Sotto il nome del repository, fai clic su Impostazioni.
  3. Scorri verso il basso fino alla zona pericolosa.
  4. Fai clic su Elimina questo repository e segui i passaggi per la conferma.

Passaggi successivi