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 con altre forme di codice, archivia il codice dell'infrastruttura nel controllo della versione per di conservare la cronologia e consentire rollback semplici.

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

Utilizza una strategia di diramazione 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 l'ultimo codice approvato. La filiale main è protetto.
  • Lo sviluppo avviene su rami per la 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.
  • Quando una funzionalità o una correzione di bug è completa, uniscila nuovamente al ramo main con una richiesta di 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 root di cui viene eseguito il deployment direttamente Google Cloud, è necessaria una strategia di lancio sicura. I nostri suggerimenti avere un ramo separato per ogni ambiente. Di conseguenza, le modifiche al file può essere promossa unire le modifiche tra i diversi rami.

Ramo separato per ogni ambiente

Consenti ampia visibilità

Rendi il codice sorgente e i repository Terraform ampiamente visibili e accessibili tra organizzazioni di ingegneria, a proprietari dell'infrastruttura (ad esempio, i tecnici SRE) e 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 sia possibile usare directory separate per gestire i confini logici risorse, confini organizzativi e logistica determinano un repository alla struttura del centro di costo. In generale, usa il principio di progettazione secondo cui le configurazioni i diversi requisiti di approvazione e gestione sono separati in repository di controllo del codice sorgente. Per illustrare questo principio, ecco alcune possibili configurazioni di 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 dedicato all'infrastruttura gestione e approva le 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 in cui vengono gestiti tutti i controlli di sicurezza e i team ognuno dispone di un proprio repository Terraform per il deployment un'applicazione.

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

  • Repository disaccoppiati: in questo modello, ogni Terraform logico è suddiviso in un repository dedicato. Ad esempio, il networking avere un repository dedicato e potrebbe esserci un progetto di fabbrica separato per la creazione e la gestione dei progetti. Funziona al meglio nelle ambienti decentralizzati in cui le responsabilità si spostano spesso 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
  • Specifico per l'applicazione e il team

Repository di base

Un repository di base che contiene i principali come cartelle o IAM dell'organizzazione. Questo repository può essere gestito dal team centrale del cloud.

  • In questo repository, includi una directory per ogni (ad esempio cartelle, reti e così via).
  • Nelle directory dei componenti, includi una cartella separata (riflette le linee guida sulla struttura delle directory menzionate in precedenza).

Struttura del repository di base

Repository specifici per applicazioni e team

Esegui il deployment di repository specifiche per l'applicazione e per il team separatamente per ciascun il team dedicato alla gestione della configurazione Terraform specifica per l'applicazione.

Struttura del repository specifica per applicazione e team

Passaggi successivi