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

Questo tutorial spiega come gestire Infrastructure as Code con Terraform e Cloud Build utilizzando la popolare metodologia GitOps. Il termine GitOps era coniata per la prima volta da Weaveworks, e il suo concetto chiave è l'utilizzo di un repository Git per l'archiviazione dell'ambiente lo stato desiderato. Terraform è un HashiCorp che consente di creare, modificare e migliorare in modo prevedibile della tua infrastruttura cloud mediante il codice. In questo tutorial utilizzi Cloud Build un servizio di integrazione continua di Google Cloud, e applicare i manifest Terraform al tuo ambiente.

Questo tutorial è rivolto agli sviluppatori e agli operatori che cercano un modello elegante per apportare modifiche prevedibili all'infrastruttura. L'articolo presuppone che tu hanno familiarità con Google Cloud, Linux e GitHub.

Lo stato delle DevOps ha identificato funzionalità in grado di migliorare le prestazioni di distribuzione del software. Questo il tutorial ti aiuterà con le seguenti funzionalità:

Architettura

Per dimostrare come questo tutorial applica le pratiche GitOps per la gestione Nelle esecuzioni di Terraform, considera il seguente diagramma dell'architettura. Tieni presente che utilizza i rami GitHub, dev e prod, per rappresentare gli ambienti reali. Questi sono definiti dalle reti VPC (Virtual Private Cloud), dev e prod, rispettivamente, in un progetto Google Cloud.

Infrastruttura con ambienti di sviluppo e produzione.

Il processo si avvia quando esegui il push del codice Terraform sull'oggetto dev o prod ramo. In questo scenario, Cloud Build attiva e quindi applica dei manifest Terraform per ottenere lo stato desiderato nel rispettivo ambiente. Quando esegui il push del codice Terraform in qualsiasi altro ramo, ad esempio a un ramo di funzionalità: Cloud Build viene eseguito per eseguire terraform plan, non viene applicato nulla a nessun ambiente.

Idealmente, gli sviluppatori o gli operatori devono fare proposte di infrastruttura per rami non protetti e poi inviarli tramite richieste di pull. La App GitHub di Cloud Build, di cui abbiamo parlato più avanti in questo tutorial, attiva automaticamente i job di build collega i report terraform plan a queste richieste di pull. In questo modo puoi discutere e rivedere le potenziali modifiche con i collaboratori e aggiungere prima che le modifiche vengano unite nel ramo di base.

Se non vengono sollevati dubbi, devi prima unire le modifiche a dev ramo. Questa unione attiva un deployment dell'infrastruttura in dev che ti consente di testare questo ambiente. Dopo aver testato e di cosa è stato eseguito il deployment, devi unire il ramo dev al Ramo prod per attivare l'installazione dell'infrastruttura in produzione completamente gestito di Google Cloud.

Obiettivi

  • Configura il tuo repository GitHub.
  • Configurare Terraform per archiviare lo stato in un bucket Cloud Storage.
  • Concedi le autorizzazioni al tuo account di servizio Cloud Build.
  • Connetti Cloud Build al tuo repository GitHub.
  • Modifica la configurazione del tuo ambiente in un ramo di funzionalità.
  • Promuovere le 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 basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

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. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

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

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

    Go to project selector

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

  6. Nella console Google Cloud, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra 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 attuale. 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 per utilizzare il tuo progetto. Sostituisci PROJECT_ID con il tuo progetto ID. 
    gcloud config set project PROJECT_ID
  8. Abilita le API richieste: 
    gcloud services enable cloudbuild.googleapis.com compute.googleapis.com
    Potrebbero essere necessari alcuni minuti per completare questo passaggio.
  9. Se non hai mai utilizzato Git in Cloud Shell, configuralo con 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 da creare in Cloud Shell.

Configurazione del repository GitHub

In questo tutorial, utilizzerai un singolo repository Git per definire il tuo dell'infrastruttura. Puoi orchestrare questa infrastruttura avendo diverse rami corrispondenti a diversi ambienti:

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

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

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

  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.

    Crea il forking di un repository.

    Ora hai una copia di solutions-terraform-cloudbuild-gitops un repository con 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 ambienti, come dev e prod, che forniscono una separazione logica tra i carichi di lavoro nelle diverse fasi di maturità, sviluppo e produzione. Sebbene sia buona norma avere questi ambienti simili possibile, ogni sottocartella ha una propria configurazione Terraform per può avere impostazioni univoche in base alle esigenze.

  • La cartella modules/ contiene moduli Terraform incorporati. Questi moduli rappresentano raggruppamenti logici di risorse correlate e sono utilizzati per condividere 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à basate in una serie di passaggi. Questo file specifica un'esecuzione condizionale che dipende dal ramo 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 assicurarti che le modifiche proposte siano appropriate per ogni ambiente, terraform init e terraform plan vengono eseguite per tutte le environments sottocartelle. Prima di unire la richiesta di pull, puoi esaminare i piani verificare che non sia concesso l'accesso a un'entità non autorizzata, ad esempio esempio.

Configurazione di Terraform per l'archiviazione dello stato in un bucket Cloud Storage

Per impostazione predefinita, Terraform archivia state localmente in un file denominato terraform.tfstate. Questa configurazione predefinita può rendono difficile l'utilizzo di Terraform per i team, soprattutto quando molti utenti a Terraform nello stesso momento e ogni macchina ha una propria conoscenza del dell'infrastruttura attuale.

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

# 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 puntino al nuovo bucket e al 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. Attiva Controllo delle versioni degli oggetti per conservare la cronologia dei tuoi deployment:

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

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

  3. Sostituisci il segnaposto PROJECT_ID con il progetto ID in entrambi i 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, potrebbe essere necessario aggiungere due virgolette ("") dopo sed -i, come segue:

    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 avrà 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 di GitHub, dovrai eseguire l'autenticazione eseguire il push delle modifiche precedenti.

Concessione delle autorizzazioni all'account di servizio Cloud Build

Per consentire Account di servizio Cloud Build eseguire script Terraform con l'obiettivo di gestire le risorse Google Cloud, devi concedere l'accesso appropriato al tuo progetto. Per semplicità, editor progetto in questo tutorial. Ma quando il ruolo di Editor del progetto per un'autorizzazione ad ampio raggio, negli ambienti di produzione è necessario seguire best practice per la sicurezza IT, che di solito prevedono l'accesso con privilegi minimi.

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

    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 repository GitHub

Questa sezione illustra come installare App GitHub di Cloud Build. Questa installazione ti consente di connettere il tuo repository GitHub progetto Google Cloud in modo che Cloud Build possa applicare automaticamente i tuoi manifest Terraform ogni volta che crei un nuovo ramo o esegui il push del codice GitHub.

I passaggi che seguono forniscono istruzioni per installare l'app soltanto per solutions-terraform-cloudbuild-gitops repository, ma puoi scegliere di installare l'app per più o tutti i repository.

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

    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 l'accesso di questa app al tuo account GitHub.
    • Se non è la prima volta che configuri un'app in GitHub: fai clic su Configura l'accesso. La pagina Applicazioni del tuo account personale l'account si apre.

  2. Fai clic su Configura nella riga Cloud Build.

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

  4. Fai clic su Salva o Installa: l'etichetta del pulsante cambia in base al il tuo flusso di lavoro. Ti reindirizzeremo a Google Cloud per continuare con dell'installazione.

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

  6. Nella pagina Cloud Build, seleziona il tuo progetto. R viene visualizzata la procedura guidata.

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

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

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

    1. Aggiungi un nome per l'attivatore, ad esempio push-to-branch. Prendi nota del nome di questo trigger perché ne avrai bisogno in seguito.
    2. Nella sezione Evento, seleziona Esegui il push a un 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 GitHub sia collegato al tuo progetto Google Cloud. D'ora in poi, le modifiche il repository GitHub attiva le esecuzioni di Cloud Build, che segnalano i risultati a GitHub utilizzando Controlli GitHub.

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

A questo punto, la maggior parte dell'ambiente è configurata. È il momento di creare modifiche al codice nel tuo ambiente di sviluppo.

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

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

  2. Assicurati di essere nella filiale dev.

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

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

    Il valore deve essere "http-server".

  5. Aggiungi un messaggio di commit nella parte inferiore della pagina, ad esempio "Correzione di http target firewall" e seleziona Crea un nuovo ramo per questo commit avviare 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 richiesta con la tua modifica.

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

  8. Fai clic su Mostra tutti i controlli e attendi che il segno di spunta 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 altri dettagli su Google Cloud Build.

Non unire ancora la richiesta di pull.

Tieni presente che il job Cloud Build ha eseguito la pipeline definita nella cloudbuild.yaml. Come già detto, questa pipeline presenta a seconda del ramo recuperato. La build controlla se $BRANCH_NAME corrisponde a qualsiasi cartella di ambiente. Se sì, Cloud Build esegue terraform plan per quell'ambiente. In caso contrario, Cloud Build esegue terraform plan per tutti gli ambienti per assicurarti che la modifica proposta sia appropriata per tutti. Se uno di questi piani non vengono eseguiti, la build non funziona.

- 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 "*************** TERRAFORM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

Analogamente, il comando terraform apply viene eseguito per i rami di ambiente, viene completamente ignorato in qualsiasi altro caso. In questa sezione, hai inviato una modifiche al codice in un nuovo ramo, per cui non sono stati applicati deployment dell'infrastruttura del tuo progetto Google Cloud.

- 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 forzata dell'esecuzione di Cloud Build prima dell'unione dei rami

Per fare in modo che le unioni possano essere applicate solo in relazione a Cloud Build sono riuscite, procedi con i seguenti passaggi:

  1. Su GitHub, vai alla pagina principale del 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 Filiale.

  4. In Regole di protezione dei rami, fai clic su Aggiungi regola.

  5. In Pattern nome ramo, digita dev.

  6. Nella sezione Proteggi i rami corrispondenti, seleziona Richiedi stato controlli da superare 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 Pattern nome ramo su prod.

Questa configurazione è importante protezione entrambi i rami dev e prod. il che significa che i commit devono prima essere inviati solo in un altro ramo, e solo allora potranno essere uniti a quello protetto. Nel questo tutorial, la protezione richiede che l'esecuzione di Cloud Build affinché l'unione sia consentita.

Promozione di modifiche all'ambiente di sviluppo

Hai una richiesta di pull in attesa di essere unita. È il momento di applicare lo stato vuoi il tuo ambiente dev.

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

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

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

  3. Fai clic sulla richiesta di pull appena creata.

  4. Fai clic su Unisci richiesta di pull, quindi su Conferma unione.

    Conferma unione.

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

    Vai alla pagina di Cloud Build

  6. Apri la build e controlla i log.

    Al termine della compilazione, vedrai qualcosa di simile a questo:

    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 una pagina web del browser.

    http://EXTERNAL_IP_VALUE

    Questo provisioning potrebbe richiedere alcuni secondi per l'avvio della VM e la propagazione la regola firewall. Alla fine, vedrai Ambiente: dev nella browser web.

  8. Passa al file di stato di Terraform nel bucket Cloud Storage.

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

Promozione di modifiche all'ambiente di produzione

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

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

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

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

  3. Fai clic su Nuova richiesta di pull.

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

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

    Confronta modifiche.

  6. Fai clic su Crea richiesta di pull.

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

  8. Esamina le modifiche proposte, inclusi i dettagli di 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 di Cloud Build

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

    Alla fine dei log, vedrai qualcosa di simile a questo:

    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 una pagina web del browser.

    http://EXTERNAL_IP_VALUE

    Questo provisioning potrebbe richiedere alcuni secondi per l'avvio della VM e la propagazione la regola firewall. Alla fine, vedrai Ambiente: prod nella browser web.

  13. Passa al file di stato di Terraform nel 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 in Cloud Build. In futuro, ti consigliamo di provare quanto segue:

  • Aggiungi deployment per casi d'uso separati.
  • Crea altri ambienti per soddisfare le tue esigenze.
  • Utilizza un progetto per ambiente anziché un VPC per ambiente.

Esegui la pulizia

Al termine del tutorial, esegui la pulizia delle risorse che hai creato Google Cloud, in modo che non ti vengano addebitati costi in futuro.

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 le nuove richieste di pull nel tuo repository GitHub, puoi eliminare le regole di protezione dei rami:

  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 Filiale.
  4. Nella sezione Regole di protezione dei rami, fai clic sul pulsante Elimina. per le righe dev e prod.

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

  1. Vai alle impostazioni di GitHub Applications (Applicazioni).

    Vai alla pagina delle applicazioni GitHub

  2. Nella scheda App GitHub installate, fai clic su Configura nel Riga Cloud Build. Quindi, nella sezione Zona di pericolo, Fai clic sul pulsante Disinstalla in Disinstalla Google Cloud Builder riga di comando.

    Nella parte superiore della pagina viene visualizzato il messaggio "Fatto. Un job è stato messo in coda per disinstallare Google Cloud Build."

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

Se non vuoi conservare il repository GitHub:

  1. In GitHub, vai alla pagina principale del 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 la procedura di conferma.

Passaggi successivi