Ti consigliamo di utilizzare l'infrastruttura dichiarativa per eseguire il deployment della base in modo coerente e controllabile. Questo approccio consente di attivare una governance coerente applicando controlli dei criteri sulle configurazioni delle risorse accettabili nelle pipeline. Il blueprint viene implementato utilizzando un flusso GitOps, con Terraform utilizzato per definire l'infrastruttura come codice (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, consulta la sezione Gestione dell'infrastruttura come codice con Terraform, Cloud Build e GitOps.
Le sezioni seguenti descrivono come viene utilizzata la pipeline di deployment per gestire le risorse della tua organizzazione.
Livelli della pipeline
Per separare i team e la tecnologia responsabili della gestione di diversi livelli del tuo ambiente, consigliamo un modello che utilizzi pipeline e persone diverse responsabili di ogni livello dello stack.
Il seguente diagramma illustra il nostro modello consigliato per separare una pipeline di base, una pipeline di infrastruttura e una pipeline di applicazione.
Il diagramma mostra gli strati della pipeline in questo modello:
- La pipeline di base esegue il deployment delle risorse di base utilizzate nella piattaforma. Consigliamo di affidare a un unico team centrale la 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, ad esempio istanze VM o database. Il blueprint configura una pipeline di infrastruttura separata per ogni unità aziendale oppure puoi optare per una sola pipeline di infrastruttura utilizzata da più team.
- La pipeline di applicazioni esegue il deployment degli elementi per ogni carico di lavoro, ad esempio container o immagini. Potresti avere molti team di applicazioni diversi con singole pipeline di applicazioni.
Le sezioni seguenti illustrano 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 di infrastruttura utilizzata per eseguire il deployment dell'infrastruttura utilizzata dai carichi di lavoro.
Per creare la pipeline di base, devi prima clonare o eseguire il fork di terraform-example-foundation nel tuo repository Git. Segui i passaggi descritti nel
file README di 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 del blueprint 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 del file README per ogni fase e implementale 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 le VPC condivise 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 più pipeline di infrastruttura. Questa separazione tra la pipeline di base e la pipeline di infrastruttura consente di distinguere le risorse a livello di piattaforma da quelle specifiche del carico di lavoro.
Il seguente diagramma descrive come il blueprint configura più pipeline di infrastruttura destinate all'utilizzo da parte di team distinti.
Il diagramma descrive i seguenti concetti chiave:
- Ogni pipeline di infrastruttura viene utilizzata per gestire le risorse dell'infrastruttura indipendente dalle risorse di base.
- Ogni unità aziendale ha la propria pipeline di infrastruttura, gestita in un progetto dedicato nella cartella
common. - Ognuna delle pipeline di infrastruttura ha un account di servizio con l'autorizzazione per eseguire il deployment delle risorse solo nei progetti associati a quell'unità aziendale. Questa strategia crea una separazione dei compiti tra gli account di servizio con privilegi utilizzati per la pipeline di base e quelli utilizzati da ogni pipeline di infrastruttura
Questo approccio con più pipeline di infrastruttura è consigliato quando hai più entità all'interno della tua organizzazione che dispongono delle competenze e della volontà di gestire la propria infrastruttura separatamente, in particolare se hanno requisiti diversi, ad esempio i tipi di criteri di convalida della pipeline che vogliono applicare. In alternativa, potresti preferire avere 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 e la fase 5 mostra un esempio di utilizzo della pipeline per eseguire il deployment delle risorse di infrastruttura.
| Fase | Descrizione |
|---|---|
Configura una struttura di cartelle, progetti e una pipeline di infrastruttura. |
|
|
Esegue il deployment di progetti di carichi di lavoro con un'istanza Compute Engine utilizzando la pipeline di infrastruttura come esempio. |
La pipeline di applicazione
La pipeline di applicazioni è responsabile del deployment degli artefatti dell'applicazione per ogni singolo carico di lavoro, ad esempio immagini o container Kubernetes che eseguono la logica di business dell'applicazione. Questi elementi vengono implementati nelle risorse di infrastruttura di cui è stato eseguito il deployment tramite la pipeline di infrastruttura.
Il progetto della piattaforma aziendale configura la pipeline di base e la pipeline di infrastruttura, ma non esegue il deployment di una pipeline di applicazioni. Per un esempio di pipeline di applicazioni, consulta il blueprint dell'applicazione aziendale.
Automatizzare la pipeline con Cloud Build
Il blueprint utilizza Cloud Build per automatizzare i processi CI/CD. La tabella seguente descrive i controlli integrati nella pipeline di base e nella pipeline di 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.
| Controllo | Descrizione |
|---|---|
Configurazioni di compilazione separate per convalidare il codice prima del deployment |
Il blueprint utilizza due file di configurazione della build di Cloud Build per tutta la pipeline e ogni repository associato a una fase ha due trigger di Cloud Build associati a questi file di configurazione della build. Quando il codice viene inviato a un ramo del repository, i file di configurazione di compilazione vengono attivati per eseguire prima |
Controlli dei criteri di Terraform | Il blueprint include un insieme di vincoli di Open Policy Agent che vengono applicati dalla convalida dei criteri in Google Cloud CLI. Questi vincoli definiscono le configurazioni delle risorse accettabili che possono essere implementate dalla pipeline. Se una build non soddisfa i criteri nella prima configurazione della build, la seconda configurazione della build non esegue il deployment di alcuna risorsa. I criteri
applicati nel progetto base sono derivati 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 Cloud Build viene eseguito come account di servizio specifico per la fase in questione. L'utilizzo di account diversi consente di 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 codice Terraform |
Pool privati di Cloud Build | Il blueprint utilizza i pool privati di Cloud Build. I pool privati ti consentono, facoltativamente, di applicare controlli aggiuntivi, ad esempio limitare l'accesso ai repository pubblici o eseguire Cloud Build all'interno di un perimetro dei Controlli di servizio VPC. |
Costruttori personalizzati Cloud Build | Il blueprint crea il proprio compilatore personalizzato per eseguire Terraform. Per ulteriori informazioni, vedi |
Approvazione del deployment | Se vuoi, puoi aggiungere una fase di approvazione manuale a Cloud Build. Questa approvazione aggiunge un ulteriore punto di controllo dopo l'attivazione della build, ma prima dell'esecuzione, in modo che un utente con privilegi possa approvare manualmente la build. |
Strategia di ramificazione
Ti consigliamo una strategia di ramo permanente per inviare il codice al tuo sistema Git e implementare le risorse tramite la pipeline di base. Il seguente diagramma descrive la strategia di ramoscello persistente.
Il diagramma descrive tre branch permanenti in Git (sviluppo, non produzione e produzione) che riflettono gli ambienti Google Cloud corrispondenti. Esistono anche più ramificazioni di funzionalità effimere che non corrispondono alle risorse di cui è stato eseguito il deployment negli ambienti Google Cloud.
Ti consigliamo di applicare una procedura di pull request (PR) al tuo sistema Git in modo che qualsiasi codice unito a un ramo persistente abbia una PR approvata.
Per sviluppare il codice con questa strategia di ramo persistente, segui questi passaggi di alto livello:
- Quando sviluppi nuove funzionalità o stai lavorando a una correzione di 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 di funzionalità, apri una PR che abbia come target il ramo di sviluppo.
- Quando invii la PR, questa attiva la pipeline di base per eseguire
terraform planeterraform validateper eseguire il commit e verificare le modifiche. - Dopo aver convalidato le modifiche al codice, unisci la funzionalità o la correzione del bug al ramo di sviluppo.
- Il processo di unione attiva l'esecuzione della pipeline di base
terraform applyper eseguire il deployment delle ultime modifiche nel ramo di sviluppo nell'ambiente di sviluppo. - Esamina le modifiche nell'ambiente di sviluppo utilizzando revisioni manuali, test funzionali o test end-to-end pertinenti al tuo caso d'uso. Quindi, promuovi le modifiche nell'ambiente non di produzione aprendo una 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 nel ramo di produzione e esegui l'unione.
Passaggi successivi
- Leggi le best practice per le operazioni (documento successivo di questa serie).