Ti consigliamo di utilizzare un'infrastruttura dichiarativa per eseguire il deployment degli elementi di base in modo coerente e controllabile. Questo approccio consente una governance coerente applicando controlli dei criteri sulle configurazioni di risorse accettabili nelle tue pipeline. Il deployment del progetto base viene eseguito utilizzando un flusso GitOps, con Terraform utilizzato per definire Infrastructure as Code (IaC), un repository Git per il controllo della versione e l'approvazione del codice e Cloud Build per l'automazione CI/CD nella pipeline di deployment. Per un'introduzione a questo concetto, vedi Gestire l'infrastruttura come codice con Terraform, Cloud Build e GitOps.
Le seguenti sezioni descrivono come la pipeline di deployment viene utilizzata per gestire le risorse nella tua organizzazione.
Livelli pipeline
Per separare i team e gli stack tecnologici responsabili della gestione dei diversi livelli dell'ambiente, consigliamo un modello che utilizzi pipeline diverse e utenti tipo diversi responsabili di ogni livello dello stack.
Il seguente diagramma presenta il nostro modello consigliato per separare una pipeline di base, dell'infrastruttura e dell'applicazione.
Il diagramma presenta i livelli della pipeline in questo modello:
- La pipeline di base esegue il deployment delle risorse di base utilizzate nella piattaforma. Consigliamo di far sì che un unico team centrale sia responsabile della gestione delle risorse di base utilizzate da più unità aziendali e carichi di lavoro.
- La pipeline di infrastruttura esegue il deployment di progetti e infrastrutture utilizzati dai carichi di lavoro, come istanze VM o database. Il progetto configura una pipeline di infrastruttura separata per ogni unità aziendale oppure potresti preferire una singola pipeline di infrastruttura utilizzata da più team.
- La pipeline dell'applicazione esegue il deployment degli artefatti per ciascun carico di lavoro, ad esempio container o immagini. Potresti avere molti team applicativi diversi con pipeline di applicazioni individuali.
Le sezioni seguenti introducono l'utilizzo di ogni livello della pipeline.
La pipeline di base
La pipeline di base esegue il deployment delle risorse di base. Configura inoltre la pipeline dell'infrastruttura utilizzata per il deployment dell'infrastruttura utilizzata dai carichi di lavoro.
Per creare la pipeline di base, devi prima clonare o creare un fork di terraform-example-foundation nel tuo repository Git. Segui i passaggi nel file README 0-bootstrap per configurare la cartella e le risorse di bootstrap.
| Fase | Descrizione |
|---|---|
Esegue il bootstrap di un'organizzazione Google Cloud. Questo passaggio configura anche una pipeline CI/CD per il codice progetto nelle fasi successive.
|
Dopo aver creato la pipeline di base nella fase 0-bootstrap, le fasi seguenti eseguono il deployment delle risorse nella pipeline di base. Esamina le istruzioni relative al file README
per ogni fase e implementa ogni fase in sequenza.
| Fase | Descrizione |
|---|---|
Configura cartelle condivise di primo livello, progetti per servizi condivisi, logging a livello di organizzazione e impostazioni di sicurezza di base tramite i criteri dell'organizzazione. |
|
Configura gli ambienti di sviluppo, non di produzione e di produzione all'interno dell'organizzazione Google Cloud che hai creato. |
|
o |
Configura i VPC condivisi nella topologia scelta e le risorse di rete associate. |
La pipeline dell'infrastruttura
La pipeline di infrastruttura esegue il deployment dei progetti e dell'infrastruttura (ad esempio, le istanze VM e i database) utilizzati dai carichi di lavoro. La pipeline di base esegue il deployment di pipeline di infrastruttura multiple. Questa separazione tra la pipeline di base e la pipeline dell'infrastruttura consente una separazione tra risorse a livello di piattaforma e risorse specifiche per i carichi di lavoro.
Il seguente diagramma descrive in che modo il progetto configura più pipeline di infrastruttura destinate all'uso da parte di team separati.
Il diagramma descrive i seguenti concetti chiave:
- Ogni pipeline di infrastruttura viene utilizzata per gestire le risorse dell'infrastruttura in modo indipendente dalle risorse di base.
- Ogni business unit ha la propria pipeline di infrastruttura, gestita in un progetto dedicato nella cartella
common. - Ognuna delle pipeline dell'infrastruttura ha un account di servizio con l'autorizzazione per eseguire il deployment delle risorse solo nei progetti associati a quella business unit. Questa strategia crea una separazione dei compiti tra gli account di servizio con privilegi utilizzati per la pipeline di base e quelli utilizzati da ciascuna pipeline di infrastruttura
Questo approccio con più pipeline di infrastruttura è consigliato quando all'interno dell'organizzazione sono presenti più entità dotate delle competenze e dell'intenzione di gestire la propria infrastruttura separatamente, in particolare se hanno requisiti diversi, come i tipi di criteri di convalida della pipeline che vogliono applicare. In alternativa, potresti preferire un'unica pipeline di infrastruttura gestita da un unico team con criteri di convalida coerenti.
In terraform-example-foundation, la fase 4 configura una pipeline di infrastruttura, mentre la fase 5 mostra un esempio di utilizzo di questa pipeline per il deployment delle risorse dell'infrastruttura.
| Fase | Descrizione |
|---|---|
Configura una struttura di cartelle, progetti e una pipeline dell'infrastruttura. |
|
|
Esegue il deployment dei progetti dei carichi di lavoro con un'istanza Compute Engine utilizzando la pipeline di infrastruttura come esempio. |
Pipeline dell'applicazione
La pipeline dell'applicazione è responsabile del deployment degli artefatti delle applicazioni per ogni singolo carico di lavoro, ad esempio immagini o container Kubernetes che eseguono la logica di business della tua applicazione. Questi artefatti vengono sottoposti a deployment nelle risorse di infrastruttura di cui è stato eseguito il deployment dalla pipeline dell'infrastruttura.
Il progetto di base aziendale configura la pipeline di base e la pipeline di infrastruttura, ma non esegue il deployment di una pipeline dell'applicazione. Per una pipeline di applicazioni di esempio, vedi il progetto dell'applicazione aziendale.
Automazione della pipeline con Cloud Build
Il progetto utilizza Cloud Build per automatizzare i processi CI/CD. Nella tabella seguente vengono descritti i controlli integrati nella pipeline di base e nella pipeline dell'infrastruttura di cui viene eseguito il deployment dal repository terraform-example-foundation. Se stai sviluppando le tue pipeline utilizzando altri strumenti di automazione CI/CD, ti consigliamo di applicare controlli simili.
| Controlli | Descrizione |
|---|---|
Separa le configurazioni della build per convalidare il codice prima del deployment |
Il progetto utilizza due file di configurazione di build di Cloud Build per l'intera pipeline e ogni repository associato a una fase ha due attivatori di Cloud Build associati a questi file di configurazione. Quando il codice viene inviato a un ramo del repository, i file di configurazione della build vengono attivati per eseguire prima |
Controlli dei criteri Terraform | Il progetto include una serie di vincoli di Open Policy Agent che vengono applicati dalla convalida dei criteri in Google Cloud CLI. Questi vincoli definiscono le configurazioni di risorse accettabili di cui la pipeline può eseguire il deployment. Se una build non soddisfa i criteri nella configurazione della prima build, nella seconda non viene eseguito il deployment di risorse. I criteri applicati nel progetto base vengono copiati da |
Principio del privilegio minimo | La pipeline di base ha un account di servizio diverso per ogni fase con un criterio di autorizzazione che concede solo i ruoli IAM minimi per quella fase. Ogni trigger di Cloud Build viene eseguito come account di servizio specifico per quella fase. L'utilizzo di account diversi aiuta a ridurre il rischio che la modifica di un repository possa influire sulle risorse gestite da un altro repository. Per comprendere i ruoli IAM specifici applicati a ciascun account di servizio, consulta il |
Pool privati di Cloud Build | Il progetto utilizza i pool privati di Cloud Build. I pool privati consentono di applicare facoltativamente controlli aggiuntivi, come la limitazione dell'accesso ai repository pubblici o l'esecuzione di Cloud Build all'interno di un perimetro dei Controlli di servizio VPC. |
i builder personalizzati di Cloud Build | Il progetto crea il proprio generatore personalizzato per eseguire Terraform. Per saperne di più, visita |
Approvazione del deployment | Se vuoi, puoi aggiungere una fase di approvazione manuale a Cloud Build. Questa approvazione aggiunge un ulteriore checkpoint dopo l'attivazione della build, ma prima dell'esecuzione, in modo che un utente con privilegi possa approvare manualmente la build. |
Strategia di diramazione
Consigliamo una strategia di ramo persistente per inviare il codice al tuo sistema Git ed eseguire il deployment delle risorse tramite la pipeline di base. Il seguente diagramma descrive la strategia di ramo permanente.
Il diagramma descrive tre rami permanenti in Git (sviluppo, non produzione e produzione) che riflettono gli ambienti Google Cloud corrispondenti. Sono inoltre disponibili più rami di funzionalità temporanee che non corrispondono alle risorse di cui viene eseguito il deployment nei tuoi ambienti Google Cloud.
Ti consigliamo di applicare un processo di richiesta di pull (PR) al tuo sistema Git, in modo che qualsiasi codice unito a un ramo permanente abbia un PR approvato.
Per sviluppare il codice con questa strategia per i rami permanenti, segui questi passaggi generali:
- Quando sviluppi nuove funzionalità o lavori alla correzione di un bug, crea un nuovo ramo basato sul ramo di sviluppo. Utilizza una convenzione di denominazione per il ramo che includa il tipo di modifica, un numero di ticket o un altro identificatore e una descrizione leggibile, ad esempio
feature/123456-org-policies. - Quando completi il lavoro nel ramo della funzionalità, apri un PR che abbia come target il ramo di sviluppo.
- Quando invii il PR, quest'ultimo attiva la pipeline di base per eseguire
terraform planeterraform validateper organizzare e verificare le modifiche. - Dopo aver convalidato le modifiche al codice, unisci la correzione di bug o funzionalità nel ramo di sviluppo.
- Il processo di unione attiva la pipeline di base per eseguire
terraform applyper eseguire il deployment delle modifiche più recenti del ramo di sviluppo nell'ambiente di sviluppo. - Esamina le modifiche nell'ambiente di sviluppo utilizzando revisioni manuali, test funzionali o test end-to-end attinenti al tuo caso d'uso. Poi promuovi le modifiche all'ambiente non di produzione aprendo un PR che abbia come target il ramo non di produzione e unisci le modifiche.
- Per eseguire il deployment delle risorse nell'ambiente di produzione, ripeti la stessa procedura del passaggio 6: esamina e convalida le risorse di cui è stato eseguito il deployment, apri una PR al ramo di produzione e unisci le risorse.
Passaggi successivi
- Scopri le best practice per le operazioni (prossimo documento di questa serie).