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 filialemain
è 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
.
- Assegna un nome ai rami della caratteristica
- 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.
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).
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.
Passaggi successivi
- Scopri le best practice per le operazioni di Terraform.
- Scopri le best practice per utilizzare Terraform in modo sicuro.