Il deployment del progetto base dell'applicazione aziendale viene eseguito tramite una serie di sistemi e pipeline automatizzati. Ogni pipeline esegue il deployment di un aspetto specifico del progetto. Le pipeline forniscono un meccanismo controllabile, verificabile e ripetibile per la creazione del progetto base. Il seguente diagramma mostra l'interazione di varie pipeline, repository e utenti tipo.
Il progetto utilizza le seguenti pipeline:
- La pipeline dell'infrastruttura di base (parte del progetto di base delle fondamenta aziendali) esegue il deployment dell'applicazione fabbrica, della pipeline dell'infrastruttura multi-tenant e della pipeline Floepscope.
- La pipeline dell'infrastruttura multi-tenant esegue il deployment dei cluster GKE e degli altri servizi gestiti su cui si basa il progetto base dell'applicazione aziendale.
- La pipeline con l'ambito del parco risorse configura gli ambiti, gli spazi dei nomi del parco risorse, nonché i ruoli e le associazioni RBAC.
- Il fabbrica di applicazioni fornisce un meccanismo per il deployment di nuove pipeline delle applicazioni tramite un processo basato su modelli.
- La pipeline CI/CD dell'applicazione fornisce una pipeline CI/CD per il deployment dei servizi nei cluster GKE.
- Config Sync esegue il deployment e la gestione di configurazioni Kubernetes aggiuntive, inclusi i vincoli di Policy Controller.
Repository, collaboratori ai repository e approvatori delle modifiche ai repository
Le pipeline del progetto vengono attivate tramite modifiche ai repository Git. La seguente tabella descrive i repository utilizzati in tutto il progetto, chi contribuisce al repository, approva le modifiche al repository, quale pipeline utilizza il repository e la descrizione di ciò che contiene.
| Repository | Collaboratore repository | Approvatore modifiche del repository | Pipeline | Descrizione |
|---|---|---|---|---|
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma di sviluppo |
Pipeline dell'infrastruttura di base |
Repository contenente il codice per il deployment della pipeline di infrastruttura multi-tenant, dell'applicazione e dell'ambito del parco risorse |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma di sviluppo |
Infrastruttura multi-tenant |
I moduli Terraform utilizzati dai team di sviluppatori delle piattaforme durante la creazione dell'infrastruttura |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma di sviluppo |
Ambito del parco risorse |
Il repository che definisce gli ambiti dei team e gli spazi dei nomi del parco risorse nel parco risorse |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma di sviluppo |
Fabbrica di applicazioni |
Il codice che definisce il repository dell'applicazione e fa riferimento ai moduli
nel repository |
|
Sviluppatore di applicazioni |
Operatore dell'applicazione |
Fabbrica di applicazioni |
Il codice di base posizionato nel repository |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma di sviluppo |
Fabbrica di applicazioni Infrastruttura multi-tenant |
I moduli Terraform che definiscono l'applicazione e l'infrastruttura |
|
Sviluppatore di applicazioni |
Operatore dell'applicazione |
CI/CD applicazione |
Il codice dell'applicazione di cui è stato eseguito il deployment nei cluster GKE |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma di sviluppo |
Config Sync |
I criteri utilizzati dai cluster GKE per mantenere le configurazioni |
Le pipeline automatizzate contribuiscono a creare sicurezza, verificabilità, tracciabilità, ripetibilità, controllabilità e conformità nel processo di deployment. Utilizzando sistemi diversi con autorizzazioni diverse e l'inserimento di persone diverse in gruppi operativi diversi, crei una separazione delle responsabilità e segui il principio del privilegio minimo.
Pipeline dell'infrastruttura di base
La pipeline dell'infrastruttura di base è descritta nel progetto di base della piattaforma aziendale e viene utilizzata come punto di contatto generico per ulteriori deployment delle risorse. La seguente tabella descrive i componenti creati dalla pipeline.
| Componente | Descrizione |
|---|---|
Crea l'infrastruttura condivisa utilizzata da tutti i tenant della piattaforma di sviluppo. |
|
Crea spazi dei nomi e associazioni di ruoli RBAC. |
|
Crea le pipeline CI/CD dell'applicazione utilizzate per il deployment dei servizi. |
Pipeline dell'infrastruttura multi-tenant
La pipeline dell'infrastruttura multi-tenant esegue il deployment di parchi risorse, cluster GKE e risorse condivise correlate. Il seguente diagramma mostra i componenti della pipeline dell'infrastruttura multi-tenant.
La tabella seguente descrive i componenti creati dalla pipeline di infrastruttura multi-tenant.
| Componente | Descrizione |
|---|---|
Cluster GKE |
Fornisce l'hosting per i servizi dell'applicazione containerizzata. |
Policy Controller |
Fornisce criteri che contribuiscono a garantire la corretta configurazione dei cluster e dei servizi GKE. |
Config Sync |
Applica i criteri di Policy Controller ai cluster e mantiene un'applicazione coerente dei criteri. |
Crea la chiave di crittografia basata sulla chiave di crittografia gestita dal cliente (CMEK) per GKE, AlloyDB per PostgreSQL e Secret Manager. |
|
Secret di Secret Manager |
Fornisce un archivio secret per la coppia di chiavi RSA utilizzata per l'autenticazione degli utenti con i token web JSON (JWT). |
Criterio di sicurezza di Google Cloud Armor |
Fornisce il criterio utilizzato dal web application firewall di Google Cloud Armor. |
Pipeline con ambito parco risorse
La pipeline nell'ambito del parco risorse è responsabile della configurazione degli spazi dei nomi e dei collegamenti RBAC nei cluster GKE del parco risorse. La seguente tabella descrive i componenti creati dalla pipeline dell'ambito del parco risorse.
| Componente | Descrizione |
|---|---|
Definisce i cluster logici all'interno del cluster fisico. |
|
Definisce l'autorizzazione di un account di servizio Kubernetes a livello di cluster o di spazio dei nomi. |
Fabbrica di applicazioni
Il deployment della fabbrica di applicazioni viene eseguito dalla pipeline dell'infrastruttura di base e viene utilizzato per creare l'infrastruttura per ogni nuova applicazione. Questa infrastruttura include un progetto Google Cloud che contiene la pipeline CI/CD dell'applicazione.
Man mano che le organizzazioni di ingegneria scalano, il team dedicato alle applicazioni può integrare nuove applicazioni utilizzando la fabbrica di applicazioni. La scalabilità consente la crescita aggiungendo pipeline CI/CD di applicazioni discrete e supportando l'infrastruttura per il deployment di nuove applicazioni nell'architettura multi-tenant. Il seguente schema mostra la fabbrica dell'applicazione.
La fabbrica dell'applicazione ha i seguenti componenti:
- Repository di fabbrica delle applicazioni:un repository Git in cui è archiviata la definizione dell'applicazione dichiarativa.
- Pipeline per la creazione di applicazioni: pipeline che richiedono Cloud Build per completare quanto segue:
- Creare una definizione di applicazione dichiarativa e archiviarla nel catalogo delle applicazioni.
- Applica la definizione di applicazione dichiarativa per creare le risorse dell'applicazione.
- Repository di modelli di applicazione base: modelli per la creazione di un'applicazione semplice (ad esempio un microservizio Python, Golang o Java).
- Moduli condivisi: moduli Terraform creati con pratiche standard e utilizzati per più scopi, tra cui l'onboarding e il deployment delle applicazioni.
La seguente tabella elenca i componenti creati dal produttore dell'applicazione per ogni applicazione.
| Componente | Descrizione |
|---|---|
Repository di codice sorgente dell'applicazione |
Contiene il codice sorgente e la configurazione correlata utilizzati per creare ed eseguire il deployment di un'applicazione specifica. |
Pipeline CI/CD dell'applicazione |
Una pipeline basata su Cloud Build che viene utilizzata per la connessione al repository di codice sorgente e fornisce una pipeline CI/CD per il deployment dei servizi per le applicazioni. |
Pipeline CI/CD dell'applicazione
La pipeline CI/CD dell'applicazione consente la creazione e il deployment automatizzati di applicazioni basate su container. La pipeline è composta da passaggi di integrazione continua (CI) e deployment continuo (CD). L'architettura della pipeline si basa sul progetto CI/CD sicuro.
La pipeline CI/CD dell'applicazione utilizza immagini container immutabili nei tuoi ambienti. Le immagini container immutabili contribuiscono a garantire che il deployment della stessa immagine venga eseguito in tutti gli ambienti e non venga modificata mentre il container è in esecuzione. Se devi aggiornare il codice dell'applicazione o applicare una patch, devi creare una nuova immagine ed eseguirne nuovamente il deployment. L'utilizzo di immagini container immutabili richiede di esternalizzare la configurazione del container in modo che le informazioni di configurazione vengano lette durante il tempo di esecuzione.
Per raggiungere i cluster GKE su un percorso di rete privata e gestire l'autenticazione kubeconfig, la pipeline CI/CD dell'applicazione interagisce con i cluster GKE tramite il gateway Connect. La pipeline utilizza anche
pool privati
per l'ambiente CI/CD.
Ogni repository di codice sorgente dell'applicazione include configurazioni Kubernetes. Queste configurazioni consentono alle applicazioni di essere eseguite come servizi Kubernetes su GKE. La seguente tabella descrive i tipi di configurazioni Kubernetes a cui si applica la pipeline CI/CD dell'applicazione.
| Componente | Descrizione |
|---|---|
Definisce un insieme scalato di pod (container). |
|
Rende un deployment raggiungibile sulla rete di cluster. |
|
Rende un servizio parte del mesh di servizi. |
|
Definisce in che modo i peer sul mesh di servizi devono raggiungere un servizio virtuale. Utilizzato nel progetto per configurare il bilanciamento del carico delle località per il traffico da est-ovest. |
|
Imposta controllo dell'accesso tra i carichi di lavoro nel mesh di servizi. |
|
Definisce l'identità utilizzata da un servizio Kubernetes. Workload Identity definisce l'account di servizio Google Cloud utilizzato per accedere alle risorse Google Cloud. |
|
Consente al traffico in entrata esterno di raggiungere un servizio. Il gateway è richiesto solo dai deployment che ricevono traffico esterno. |
|
Configurare SSL, Google Cloud Armor, l'affinità sessione e lo svuotamento della connessione per i deployment che ricevono traffico esterno. GCPBackendPolicy viene utilizzato solo dai deployment che ricevono traffico esterno. |
|
Configura la raccolta di metriche Prometheus esportate da un'applicazione. |
Integrazione continua
Il seguente diagramma mostra il processo di integrazione continua.
La procedura è la seguente:
- Uno sviluppatore esegue il commit del codice dell'applicazione nel repository di codice sorgente dell'applicazione. Questa operazione attiva l'avvio della pipeline di integrazione da parte di Cloud Build.
- Cloud Build crea un'immagine container, invia l'immagine container ad Artifact Registry e crea un digest immagine.
- Cloud Build esegue test automatici per l'applicazione. A seconda del linguaggio dell'applicazione, potrebbero essere eseguiti pacchetti di test diversi.
- Cloud Build esegue le seguenti analisi sull'immagine container:
- Cloud Build analizza il container utilizzando il framework Container Structured Tests. Questo framework esegue test dei comandi, dell'esistenza dei file, del contenuto del file e dei metadati.
- Cloud Build utilizza l'analisi delle vulnerabilità per identificare eventuali vulnerabilità nell'immagine container rispetto a un database delle vulnerabilità gestito da Google Cloud.
- Cloud Build approva l'immagine in modo che continui nella pipeline dopo gli errori della scansione.
- Autorizzazione binaria firma l'immagine. Autorizzazione binaria è un servizio su Google Cloud che fornisce la sicurezza della catena di fornitura del software per le applicazioni basate su container utilizzando criteri, regole, note, attestations, attestatori e firmatari. Al momento del deployment, l'applicazione dei criteri di Autorizzazione binaria contribuisce a garantire la prova del container prima di consentire il deployment del container.
- Cloud Build crea una release in Cloud Deploy per avviare il processo di deployment.
Per visualizzare le informazioni sulla sicurezza di una build, vai al riquadro Insight sulla sicurezza. Questi insight includono le vulnerabilità rilevate utilizzando Artifact Analysis e il livello di sicurezza della build della build indicato dalle linee guida SLSA.
Quando crei la tua applicazione, segui le best practice per la creazione dei container.
Deployment continuo
Il seguente diagramma mostra il processo di deployment continuo.
La procedura è la seguente:
- Al termine del processo di compilazione, la pipeline CI/CD dell'applicazione crea una nuova release di Cloud Deploy per avviare progressivamente le immagini container appena create in ogni ambiente.
- Cloud Deploy avvia un'implementazione nel primo ambiente della pipeline di deployment, di solito in fase di sviluppo. Ogni fase del deployment è configurata in modo da richiedere l'approvazione manuale.
- Le pipeline di Cloud Deploy utilizzano un deployment sequenziale per eseguire il deployment di immagini in ogni cluster in un ambiente nell'ordine.
- Al termine di ogni fase di deployment, Cloud Deploy verifies la funzionalità dei container di cui è stato eseguito il deployment. Questi passaggi sono configurabili all'interno della configurazione Skaffold per le applicazioni.
Deployment di una nuova applicazione
Il seguente diagramma mostra in che modo la pipeline CI/CD dell'applicazione e quella dell'applicazione interagiscono per creare ed eseguire il deployment di una nuova applicazione.
La procedura per definire una nuova applicazione è la seguente:
- Un operatore dell'applicazione definisce una nuova applicazione all'interno del proprio tenant eseguendo un trigger di Cloud Build per generare la definizione dell'applicazione.
- Il trigger aggiunge una nuova voce per l'applicazione in Terraform ed esegue il commit della modifica nel repository di fabbrica dell'applicazione.
- La modifica impegnata attiva la creazione di repository e progetti specifici per le applicazioni.
- Cloud Build completa quanto segue:
- Crea due nuovi repository Git per ospitare il codice sorgente e IaC dell'applicazione.
- Esegue il push dei manifest Kubernetes per i criteri di rete e Workload Identity al repository di gestione della configurazione.
- Crea il progetto CI/CD dell'applicazione e il trigger IaC di Cloud Build.
- Il trigger IaC di Cloud Build per l'applicazione crea la pipeline CI/CD dell'applicazione e il repository Artifact Registry nel progetto CI/CD dell'applicazione.
- Config Sync esegue il deployment dei criteri di rete e delle configurazioni di Workload Identity nei cluster GKE multi-tenant.
- La pipeline di creazione dell'ambito del parco risorse crea l'ambito e lo spazio dei nomi del parco risorse per l'applicazione su cluster GKE multi-tenant.
- La pipeline CI/CD dell'applicazione esegue il deployment iniziale dell'applicazione nei cluster GKE.
- Facoltativamente, il team dell'applicazione utilizza il trigger IaC di Cloud Build per eseguire il deployment di progetti e risorse aggiuntive (ad esempio database e altri servizi gestiti) in progetti single-tenant dedicati, uno per ogni ambiente.
Configurazione e gestione dei criteri di GKE Enterprise
Nel progetto base, gli amministratori della piattaforma per sviluppatori utilizzano Config Sync per creare configurazioni a livello di cluster in ogni ambiente. Config Sync si connette a un repository Git che funge da fonte attendibile per lo stato scelto della configurazione del cluster. Config Sync monitora continuamente lo stato effettivo della configurazione nei cluster e riconcilia eventuali discrepanze applicando aggiornamenti per garantire la conformità allo stato scelto, nonostante le modifiche manuali. Le configurazioni vengono applicate agli ambienti (sviluppo, non di produzione e produzione) utilizzando una strategia di branching sul repository.
In questo progetto, Config Sync applica i vincoli di Policy Controller. Queste configurazioni definiscono i controlli di sicurezza e conformità come definiti dagli amministratori della piattaforma di sviluppo per l'organizzazione. Questo progetto si basa su altre pipeline per applicare altre configurazioni: le pipeline CI/CD dell'applicazione applicano una configurazione specifica per l'applicazione e la pipeline dell'ambito del parco risorse crea spazi dei nomi e associazioni di ruoli associate.
Passaggi successivi
- Scopri di più sull'architettura dell'applicazione Cymbal Bank (prossimo documento di questa serie).