Il progetto dell'applicazione aziendale viene implementato tramite una serie di sistemi e pipeline automatizzati. Ogni pipeline esegue il deployment di un aspetto specifico del progetto base. Le pipeline forniscono un meccanismo controllabile, verificabile e ripetibile per la creazione del progetto. Il seguente diagramma mostra l'interazione tra le varie pipeline, i repository e le buyer persona.
Il progetto utilizza le seguenti pipeline:
- La pipeline dell'infrastruttura di base (parte del progetto di base aziendale) esegue il deployment della fabbrica di applicazioni, della pipeline dell'infrastruttura multi-tenant e della pipeline con ambito flotta.
- La pipeline dell'infrastruttura multi-tenant esegue il deployment dei cluster GKE e degli altri servizi gestiti su cui si basa il progetto base per le applicazioni aziendali.
- La pipeline fleet-scope configura ambiti del parco risorse, spazi dei nomi e ruoli e associazioni RBAC.
- La fabbrica di applicazioni fornisce un meccanismo per eseguire il deployment di nuove pipeline di 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 manutenzione di configurazioni Kubernetes aggiuntive, incluse le limitazioni di Policy Controller.
Repository, collaboratori del repository e approvatori delle modifiche al repository
Le pipeline dei blueprint vengono attivate tramite le modifiche ai repository Git. La tabella seguente descrive i repository utilizzati nel blueprint, chi contribuisce al repository, chi approva le modifiche al repository, quale pipeline utilizza il repository e la descrizione dei contenuti del repository.
| Repository | Collaboratore del repository | Approvatore modifica repository | Pipeline | Descrizione |
|---|---|---|---|---|
|
Sviluppatore di piattaforme per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Pipeline dell'infrastruttura di base |
Repository che contiene il codice per eseguire il deployment della pipeline dell'infrastruttura multi-tenant, dell'applicazione e della pipeline con ambito flotta |
|
Sviluppatore di piattaforme per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Infrastruttura multi-tenant |
I moduli Terraform utilizzati dai team della piattaforma per sviluppatori quando creano l'infrastruttura |
|
Sviluppatore di piattaforme per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Ambito del parco risorse |
Il repository che definisce gli ambiti e gli spazi dei nomi del team del parco risorse nel parco risorse |
|
Sviluppatore di piattaforme per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Application factory |
Il codice che definisce il repository dell'applicazione e fa riferimento ai
moduli nel repository |
|
Sviluppatore di applicazioni |
Operatore di applicazione |
Application factory |
Il codice di base inserito nel repository |
|
Sviluppatore di piattaforme per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Application factory Infrastruttura multi-tenant |
I moduli Terraform che definiscono l'applicazione e l'infrastruttura |
|
Sviluppatore di applicazioni |
Operatore di applicazione |
CI/CD dell'applicazione |
Il codice dell'applicazione di cui viene eseguito il deployment nei cluster GKE |
|
Sviluppatore di piattaforme per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Config Sync |
I criteri utilizzati dai cluster GKE per mantenere le configurazioni |
Le pipeline automatizzate contribuiscono a integrare sicurezza, controllabilità, tracciabilità, ripetibilità, controllabilità e conformità nel processo di deployment. Utilizzando sistemi diversi con autorizzazioni diverse e inserendo 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 della piattaforma aziendale e viene utilizzata come punto di ingresso generico per ulteriori deployment di risorse. La tabella seguente descrive i componenti creati dalla pipeline.
| Componente | Descrizione |
|---|---|
Crea l'infrastruttura condivisa utilizzata da tutti i tenant della piattaforma per sviluppatori. |
|
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 flotte, cluster GKE e risorse condivise correlate. Il seguente diagramma mostra i componenti della pipeline dell'infrastruttura multitenant.
La tabella seguente descrive i componenti creati dalla pipeline dell'infrastruttura multi-tenant.
| Componente | Descrizione |
|---|---|
Cluster GKE |
Fornisce l'hosting per i servizi dell'applicazione in container. |
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 ne mantiene l'applicazione coerente. |
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 dei secret per la coppia di chiavi RSA utilizzata per l'autenticazione utente con token web JSON (JWT). |
Criterio di sicurezza di Cloud Armor |
Fornisce il criterio utilizzato dal firewall per applicazioni web Cloud Armor. |
Pipeline nell'ambito del parco risorse
La pipeline con ambito a livello di parco risorse è responsabile della configurazione degli spazi dei nomi e dei binding RBAC nei cluster GKE del parco risorse. La tabella seguente descrive i componenti creati dalla pipeline ambito flotta.
| 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 spazio dei nomi. |
Application factory
La fabbrica di applicazioni viene implementata dalla pipeline dell'infrastruttura di base e viene utilizzata 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 crescono, il team di sviluppo delle applicazioni può integrare nuove applicazioni utilizzando la fabbrica di applicazioni. Lo scaling consente la crescita aggiungendo pipeline CI/CD di applicazioni discrete e supportando l'infrastruttura per il deployment di nuove applicazioni all'interno dell'architettura multi-tenant. Il seguente diagramma mostra la fabbrica di applicazioni.
La fabbrica di applicazioni è costituita dai seguenti componenti:
- Repository di fabbrica dell'applicazione:un repository Git che archivia la definizione dichiarativa dell'applicazione.
- Pipeline per creare applicazioni:pipeline che richiedono
a Cloud Build di completare le seguenti operazioni:
- Crea una definizione dichiarativa dell'applicazione e memorizzala nel catalogo delle applicazioni.
- Applica la definizione dichiarativa dell'applicazione per creare le risorse dell'applicazione.
- Repository di modelli di applicazioni iniziali: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 tabella seguente elenca i componenti creati dalla fabbrica di applicazioni per ogni applicazione.
| Componente | Descrizione |
|---|---|
Repository del codice sorgente dell'applicazione |
Contiene il codice sorgente e la configurazione correlata utilizzati per la creazione e il deployment di un'applicazione specifica. |
Pipeline CI/CD dell'applicazione |
Una pipeline basata su Cloud Build utilizzata per connettersi al repository di codice sorgente e che fornisce una pipeline CI/CD per il deployment dei servizi applicativi. |
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 è costituita da passaggi di integrazione continua (CI) e deployment continuo (CD). L'architettura della pipeline si basa sul blueprint CI/CD sicuro.
La pipeline CI/CD dell'applicazione utilizza immagini container immutabili in tutti gli ambienti. Le immagini container immutabili contribuiscono a garantire che la stessa immagine venga sottoposta a deployment in tutti gli ambienti e non venga modificata durante l'esecuzione del container. Se devi aggiornare il codice dell'applicazione o applicare una patch, crei una nuova immagine ed esegui 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 l'esecuzione.
Per raggiungere i cluster GKE tramite un percorso di rete privato 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 del codice sorgente dell'applicazione include le configurazioni di Kubernetes. Queste configurazioni consentono alle applicazioni di essere eseguite correttamente come servizi Kubernetes su GKE. La seguente tabella descrive i tipi di configurazioni Kubernetes applicate dalla pipeline CI/CD dell'applicazione.
| Componente | Descrizione |
|---|---|
Definisce un insieme scalato di pod (container). |
|
Rende un deployment raggiungibile tramite la rete del cluster. |
|
Rende un servizio parte del mesh di servizi. |
|
Definisce il modo in cui i peer sul mesh di servizi devono raggiungere un servizio virtuale. Utilizzato nel blueprint per configurare il bilanciamento del carico locale per il traffico est-ovest. |
|
Imposta controllo dell'accesso tra i workload nel mesh di servizi. |
|
Definisce l'identità utilizzata da un servizio Kubernetes. Workload Identity Federation for GKE definisce il service account Google Cloud utilizzato per accedere alle risorseGoogle Cloud . |
|
Consente al traffico in entrata esterno di raggiungere un servizio. Il gateway è richiesto solo dalle implementazioni che ricevono traffico esterno. |
|
Configura SSL, Cloud Armor, affinità sessione e svuotamento della connessione per i deployment che ricevono traffico esterno. GCPBackendPolicy viene utilizzato solo dai deployment che ricevono traffico esterno. |
|
Configura la raccolta delle 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 origine dell'applicazione. Questa operazione attiva Cloud Build per avviare la pipeline di integrazione.
- Cloud Build crea un'immagine container, ne esegue il push su Artifact Registry e crea un digest dell'immagine.
- Cloud Build esegue test automatizzati per l'applicazione. A seconda della lingua dell'applicazione, potrebbero essere eseguiti diversi pacchetti di test.
- Cloud Build esegue le seguenti scansioni sull'immagine container:
- Cloud Build analizza il container utilizzando il framework Container Structure Tests. Questo framework esegue test dei comandi, test di esistenza dei file, test dei contenuti dei file e test dei metadati.
- Cloud Build utilizza l'analisi delle vulnerabilità per identificare eventuali vulnerabilità nell'immagine container in base a un database delle vulnerabilità gestito da Google Cloud.
- Cloud Build approva l'immagine per continuare la pipeline dopo risultati della scansione riusciti.
- 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 norme, regole, note, attestazioni, attestatori, e firmatari. Al momento del deployment, l'enforcer dei criteri di Autorizzazione binaria contribuisce a garantire la provenienza del container prima di consentirne il deployment.
- Cloud Build crea una release in Cloud Deploy per iniziare il processo di deployment.
Per visualizzare le informazioni sulla sicurezza di una build, vai al pannello Approfondimenti sulla sicurezza. Questi approfondimenti includono le vulnerabilità rilevate utilizzando l'Artifact Analysis e il livello di garanzia di sicurezza della build indicato dalle linee guida SLSA.
Deployment continuo
Il seguente diagramma mostra la procedura 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, che di solito è lo sviluppo. Ogni fase di deployment è configurata in modo da richiedere l'approvazione manuale.
- Le pipeline Cloud Deploy utilizzano il deployment sequenziale per eseguire il deployment delle immagini in ogni cluster di un ambiente in ordine.
- Al termine di ogni fase di deployment, Cloud Deploy verifica la funzionalità dei container di cui è stato eseguito il deployment. Questi passaggi sono configurabili all'interno della configurazione di Skaffold per le applicazioni.
Deployment di una nuova applicazione
Il seguente diagramma mostra come la fabbrica di applicazioni e la pipeline CI/CD dell'applicazione collaborano per creare e implementare 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 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 della fabbrica di applicazioni.
- La modifica di cui è stato eseguito il commit attiva la creazione di repository e progetti specifici dell'applicazione.
- Cloud Build completa le seguenti operazioni:
- Crea due nuovi repository Git per ospitare il codice sorgente dell'applicazione e IaC.
- Esegue il push dei manifest Kubernetes per i criteri di rete e la federazione delle identità per i carichi di lavoro per GKE nel repository di gestione della configurazione.
- Crea il progetto CI/CD dell'applicazione e il trigger Cloud Build IaC.
- 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 delle policy di rete e delle configurazioni di Workload Identity Federation for GKE 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 sui 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.
Gestione delle configurazioni e delle policy di GKE Enterprise
Nel blueprint, 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 di riferimento per lo stato scelto della configurazione del cluster. Config Sync monitora continuamente lo stato effettivo della configurazione nei cluster e risolve eventuali discrepanze applicando aggiornamenti per garantire il rispetto dello stato scelto, nonostante le modifiche manuali. Le configurazioni vengono applicate agli ambienti (sviluppo, non di produzione e produzione) utilizzando una strategia di ramificazione sul repository.
In questo blueprint, Config Sync applica i vincoli di Policy Controller. Queste configurazioni definiscono i controlli di sicurezza e conformità come definiti dagli amministratori della piattaforma per sviluppatori per l'organizzazione. Questo blueprint si basa su altre pipeline per applicare altre configurazioni: le pipeline CI/CD dell'applicazione applicano la configurazione specifica dell'applicazione e la pipeline con ambito flotta crea spazi dei nomi e associazioni di ruoli associate.
Passaggi successivi
- Leggi l'articolo sull'architettura dell'applicazione Cymbal Bank (il prossimo documento di questa serie).