Best practice per il controllo della versione

Questo documento fornisce le best practice per il controllo della versione da considerare quando si utilizza Terraform per Google Cloud.

Come per altre forme di codice, archivia il codice dell'infrastruttura nel controllo delle versioni per conservare la cronologia e consentire facili rollback.

Questa guida non è un'introduzione a Terraform. Per un'introduzione all'utilizzo Terraform con Google Cloud, consulta Inizia a utilizzare Terraform.

Utilizzare una strategia di ramificazione predefinita

Per tutti i repository che contengono codice Terraform, utilizza la strategia seguente: valore predefinito:

• Il ramo main è il ramo di sviluppo principale e rappresenta il codice approvato più recente. Il ramo main è protetto.
• Lo sviluppo avviene su rami di correzione di bug e funzionalità che si diramano dal Ramo main.
  • Assegna un nome ai rami della caratteristica feature/$feature_name.
  • Assegna un nome ai rami per la correzione di bug fix/$bugfix_name.
• Una volta completata la correzione di una funzionalità o di un bug, uniscila nuovamente al ramo main con una richiesta pull.
• Per evitare conflitti di unione, ribase i rami prima di unirli.

Utilizza i rami di ambiente per le configurazioni root

Per i repository che includono configurazioni di root di cui viene eseguito il deployment direttamente su Google Cloud, è necessaria una strategia di implementazione sicura. I nostri suggerimenti avere un ramo separato per ogni ambiente. Pertanto, le modifiche alla configurazione Terraform possono essere promosse combinando le modifiche tra i diversi branch.

Consenti ampia visibilità

Rendi il codice sorgente e i repository di Terraform ampiamente visibili e accessibili nelle organizzazioni di ingegneria, ai proprietari dell'infrastruttura (ad esempio gli SRE) e agli stakeholder dell'infrastruttura (ad esempio gli sviluppatori). Ciò garantisce che dell'infrastruttura possono avere una migliore comprensione dell'infrastruttura da cui dipendono.

incoraggiare gli stakeholder dell'infrastruttura a inviare richieste di unione nell'ambito procedura di richiesta di modifica.

Non eseguire mai il commit dei secret

Non eseguire mai il commit dei secret nel controllo del codice sorgente, anche nella configurazione di Terraform. Caricali invece su un sistema come Secret Manager e farvi riferimento utilizzando i dati fonti.

Tieni presente che questi valori sensibili potrebbero comunque essere inseriti nel file di stato. e potrebbero anche essere esposte come output.

Organizza i repository in base ai confini dei team

Sebbene tu possa utilizzare directory separate per gestire i confini logici tra le risorse, i confini organizzativi e la logistica determinano la struttura del repository. In generale, utilizza il principio di progettazione secondo cui le configurazioni con requisiti di approvazione e gestione diversi sono separate in diversi repository di controllo del codice sorgente. Per illustrare questo principio, di seguito sono riportate alcune possibili configurazioni del repository:

• Un repository centrale: in questo modello, tutto il codice Terraform è gestiti a livello centrale da un unico team sulla piattaforma. Questo modello funziona al meglio quando c'è un team di infrastruttura dedicato responsabile di tutta la gestione del cloud e approva eventuali modifiche richieste da altri team.

• Repository dei team: in questo modello, ogni team è responsabile il tuo repository Terraform, dove gestisce tutto ciò che riguarda dell'infrastruttura di cui si dispone. Ad esempio, il team di sicurezza potrebbe avere un repository in cui vengono gestiti tutti i controlli di sicurezza e i team di applicazioni hanno ciascuno il proprio repository Terraform per eseguire il deployment e gestire la propria applicazione.

  L'organizzazione dei repository lungo i confini dei team è la struttura migliore scenari aziendali.

• Repo decoupled: in questo modello, ogni componente Terraform logico è suddiviso in un proprio repository. Ad esempio, la rete potrebbe avere un repository dedicato e potrebbe esserci un repository distinto per la creazione e la gestione dei progetti. Funziona al meglio nelle ambienti decentralizzati in cui le responsabilità si spostano spesso i team di sicurezza.

Struttura del repository di esempio

Puoi combinare questi principi per suddividere la configurazione di Terraform tra diversi tipi di repository:

• Di base
• Specifici per l'applicazione e il team

Repository di base

Un repository fondamentale che contiene i principali componenti centrali, come cartelle o IAM dell'organizzazione. Questo repository puoi essere gestito dal team cloud centrale.

• In questo repository, includi una directory per ogni componente principale (ad esempio cartelle, reti e così via).
• Nelle directory dei componenti, includi una cartella separata per ogni ambiente (in base alle indicazioni sulla struttura della directory riportate in precedenza).

Repository specifici per applicazioni e team

Esegui il deployment di repository specifici per applicazione e team separatamente per ogni team in modo che possa gestire la propria configurazione Terraform specifica per l'applicazione.

Passaggi successivi

• Scopri le best practice per le operazioni di Terraform.
• Scopri le best practice per utilizzare Terraform in modo sicuro.