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 di Terraform con Google Cloud, consulta Introduzione a Terraform.

Utilizza una strategia di ramificazione predefinita

Per tutti i repository che contengono codice Terraform, utilizza per impostazione predefinita la seguente strategia:

• Il ramo main è il ramo di sviluppo principale e rappresenta il codice approvato più recente. Il ramo main è protetto.
• Lo sviluppo avviene nei rami di funzionalità e correzione di bug che si diramano dal ramomain.
  • Assegna un nome ai rami delle funzionalità feature/$feature_name.
  • Assegna un nome ai rami di correzione dei 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, esegui la rebase dei rami prima di unirli.

Utilizzare i rami dell'ambiente per le configurazioni principali

Per i repository che includono configurazioni principali di cui viene eseguito il deployment direttamente inGoogle Cloud, è necessaria una strategia di implementazione sicura. Ti consigliamo di avere un ramo distinto per ogni ambiente. Pertanto, le modifiche alla configurazione Terraform possono essere promosse combinando le modifiche tra i diversi branch.

Consenti visibilità ampia

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). In questo modo, gli stakeholder dell'infrastruttura possono comprendere meglio l'infrastruttura di cui hanno bisogno.

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

Non eseguire mai il commit dei secret

Non eseguire mai il commit dei segreti nel controllo del codice sorgente, inclusa la configurazione di Terraform. Caricali invece in un sistema come Secret Manager e fai riferimento a queste informazioni utilizzando le origini dati.

Tieni presente che questi valori sensibili potrebbero comunque finire nel file dello stato e potrebbero anche essere esposti come output.

Organizzare i repository in base ai confini del 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 è gestito centralmente da un unico team della 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.

• Repositoi di gruppo: in questo modello, ogni team è responsabile del proprio repository Terraform, in cui gestisce tutto ciò che riguarda l'infrastruttura di sua proprietà. 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.

  Organizzare i repository in base ai confini dei team è la struttura migliore per la maggior parte degli scenari aziendali.

• Reposizienti disaccoppiati: 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. Questo approccio funziona meglio in ambienti altamente decentralizzati in cui le responsabilità passano spesso da un team all'altro.

Struttura del repository di esempio

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

• Fondamentali
• 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 l'utilizzo sicuro di Terraform.