Il blueprint dell'applicazione aziendale viene implementato tramite una serie di sistemi e pipeline automatici. 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 blueprint. Il seguente diagramma mostra l'interazione tra le varie pipeline, i repository e le persone.
Il blueprint utilizza le seguenti pipeline:
- La pipeline dell'infrastruttura di base (parte del progetto della piattaforma aziendale) esegue il deployment della factory di applicazioni, della pipeline dell'infrastruttura multi-tenant e della pipeline di ambito parco risorse.
- La pipeline di 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 di ambito del parco risorse configura gli ambiti del parco risorse, gli spazi dei nomi, i ruoli e le associazioni RBAC.
- La factory di applicazioni fornisce un meccanismo per eseguire il deployment di nuove pipeline di applicazioni tramite una procedura basata su modelli.
- La pipeline CI/CD dell'applicazione fornisce una pipeline CI/CD per il deployment di servizi nei cluster GKE.
- Config Sync esegue il deployment e la gestione di configurazioni Kubernetes aggiuntive, inclusi i vincoli di Policy Controller.
Repository, collaboratori del repository e approvatori delle modifiche al repository
Le pipeline dei blueprint vengono attivate tramite 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 delle modifiche al repository | Pipeline | Descrizione |
|---|---|---|---|---|
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Pipeline dell'infrastruttura di base |
Repository contenente il codice per il deployment della pipeline di infrastruttura multi-tenant, dell'applicazione e della pipeline a livello di parco |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Infrastruttura multi-tenant |
I moduli Terraform utilizzati dai team della piattaforma per gli sviluppatori per creare l'infrastruttura |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Ambito parco risorse |
Il repository che definisce gli ambiti e gli spazi dei nomi dei team del parco risorse nel parco risorse |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Factory di applicazioni |
Il codice che definisce il repository dell'applicazione e fa riferimento ai moduli nel repository |
|
Sviluppatore di applicazioni |
Operatore di applicazioni |
Factory di applicazioni |
Il codice di base inserito nel repository |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Factory di applicazioni Infrastruttura multi-tenant |
I moduli Terraform che definiscono l'applicazione e l'infrastruttura |
|
Sviluppatore di applicazioni |
Operatore di applicazioni |
CI/CD delle applicazioni |
Il codice dell'applicazione di cui viene eseguito il deployment nei cluster GKE |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore della piattaforma per sviluppatori |
Config Sync |
I criteri utilizzati dai cluster GKE per gestire le proprie configurazioni |
Le pipeline automatizzate contribuiscono a creare sicurezza, auditabilità, tracciabilità, ripetibilità, controllabilità e conformità nel processo di deployment. Se utilizzi sistemi diversi con autorizzazioni diverse e inserisci persone diverse in gruppi di lavoro 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 contatto generico per ulteriori implementazioni di risorse. La tabella seguente descrive i componenti creati dalla pipeline.
| Componente | Descrizione |
|---|---|
Crea l'infrastruttura condivisa utilizzata da tutti gli utenti della piattaforma per gli sviluppatori. |
|
Crea spazi dei nomi e associazioni di ruoli RBAC. |
|
Crea le pipeline CI/CD dell'applicazione utilizzate per eseguire il deployment dei servizi. |
Pipeline di infrastruttura multi-tenant
La pipeline di infrastruttura multi-tenant esegue il deployment di parchi, cluster GKE e risorse condivise correlate. Il seguente diagramma mostra i componenti della pipeline dell'infrastruttura multi-tenant.
La tabella seguente descrive i componenti che vengono creati dalla pipeline dell'infrastruttura multi-tenant.
| Componente | Descrizione |
|---|---|
Cluster GKE |
Fornisce l'hosting per i servizi dell'applicazione con contenitore. |
Policy Controller |
Fornisce criteri che contribuiscono a garantire la configurazione corretta dei cluster e dei servizi GKE. |
Config Sync |
Applica i criteri di Policy Controller ai cluster e mantiene costante l'applicazione 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 di chiavi per la coppia di chiavi RSA utilizzata per l'autenticazione utente con i token web JSON (JWT). |
Criterio di sicurezza di Google Cloud Armor |
Fornisce il criterio utilizzato dal firewall per le applicazioni web di Google Cloud Armor. |
Pipeline a livello di parco risorse
La pipeline a livello di parco risorse è responsabile della configurazione degli spazi dei nomi e delle associazioni RBAC nei cluster GKE del parco risorse. La tabella seguente descrive i componenti che vengono generati dalla pipeline di ambito parco veicoli.
| 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. |
Factory di applicazioni
La factory 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 si espandono, il team delle applicazioni può eseguire l'onboarding di nuove applicazioni utilizzando la factory di applicazioni. La scalabilità consente la crescita aggiungendo pipeline CI/CD di applicazioni distinte e supportando l'infrastruttura per il deployment di nuove applicazioni all'interno dell'architettura multi-tenant. Il seguente diagramma mostra la factory dell'applicazione.
La factory dell'applicazione ha i seguenti componenti:
- Repository della factory dell'applicazione:un repository Git che memorizza la definizione dell'applicazione dichiarativa.
- Pipeline per la creazione di applicazioni:le pipeline che richiedono Cloud Build per completare quanto segue:
- Crea una definizione di applicazione dichiarativa e memorizzala nel catalogo dell'applicazione.
- Applica la definizione dell'applicazione dichiarativa 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 factory di applicazioni per ogni applicazione.
| Componente | Descrizione |
|---|---|
Repository del codice sorgente dell'applicazione |
Contiene il codice sorgente e la configurazione correlata utilizzata per compilare e implementare un'applicazione specifica. |
Pipeline CI/CD dell'applicazione |
Una pipeline basata su Cloud Build utilizzata per connettersi al repository del codice sorgente e fornire una pipeline CI/CD per il deployment dei servizi di 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 distribuzione continua (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 dispiata in tutti gli ambienti e non venga modificata mentre il contenitore è in esecuzione. Se devi aggiornare il codice dell'applicazione o applicare una patch, crea una nuova immagine e ridistribuiscila. L'utilizzo di immagini container immutabili richiede di esternalizzare la configurazione del container in modo che le informazioni di configurazione vengano lette durante il runtime.
Per raggiungere i cluster GKE tramite 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 del codice sorgente dell'applicazione include configurazioni Kubernetes. Queste configurazioni consentono alle applicazioni di essere eseguite correttamente come servizi Kubernetes su GKE. La tabella seguente descrive i tipi di configurazioni Kubernetes applicati dalla pipeline CI/CD dell'applicazione.
| Componente | Descrizione |
|---|---|
Definisce un insieme scalato di pod (container). |
|
Rende un deployment raggiungibile tramite la rete del cluster. |
|
Inserisce un servizio nella rete mesh di servizi. |
|
Definisce in che modo i peer nel mesh di servizi devono raggiungere un servizio virtuale. Utilizzato nel blueprint per configurare il bilanciamento del carico a livello di località 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 lo Google Cloud service account utilizzato per accedere alle risorseGoogle Cloud . |
|
Consente al traffico in entrata esterno di raggiungere un servizio. Il gateway è obbligatorio solo per i deployment che ricevono traffico esterno. |
|
Configura 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 delle metriche Prometheus esportate da un'applicazione. |
Integrazione continua
Il seguente diagramma mostra la procedura di integrazione continua.
La procedura è la seguente:
- Uno sviluppatore esegue il commit del codice dell'applicazione nel repository del codice sorgente dell'applicazione. Questa operazione attiva Cloud Build per avviare la pipeline di integrazione.
- Cloud Build crea un'immagine container, esegue il push dell'immagine container ad Artifact Registry e crea un digest dell'immagine.
- Cloud Build esegue test automatici per l'applicazione. A seconda della lingua dell'applicazione, possono essere eseguiti diversi pacchetti di test.
- Cloud Build esegue le seguenti analisi sull'immagine del contenitore:
- Cloud Build analizza il contenitore 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 la scansione delle vulnerabilità per identificare eventuali vulnerabilità nell'immagine container rispetto a un database delle vulnerabilità gestito da Google Cloud.
- Cloud Build approva l'immagine per continuare nella pipeline dopo risultati di scansione positivi.
- Autorizzazione binaria firma l'immagine. L'Autorizzazione binaria è un servizio su Google Cloud che fornisce la sicurezza della catena di approvvigionamento del software per le applicazioni basate su container tramite l'utilizzo di norme, regole, note, attestazioni, attestatori, e firmatari. Al momento del deployment, l'applicazione 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 avviare il processo di deployment.
Per visualizzare le informazioni sulla sicurezza di una build, vai al riquadro Approfondimenti sulla sicurezza. Questi approfondimenti includono vulnerabilità che sono state 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 lanciare progressivamente le immagini container appena create in ogni ambiente.
- Cloud Deploy avvia un'implementazione nel primo ambiente della pipeline di deployment, che in genere è di sviluppo. Ogni fase di implementazione è configurata per 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 factory di applicazioni e la pipeline CI/CD dell'applicazione collaborino per creare ed eseguire il deployment di una nuova applicazione.
La procedura per definire una nuova applicazione è la seguente:
- Un operatore di applicazioni definisce una nuova applicazione all'interno del proprio tenant eseguendo un attivatore Cloud Build per generare la definizione dell'applicazione.
- L'attivatore aggiunge una nuova voce per l'applicazione in Terraform e esegue il commit della modifica nel repository della factory dell'applicazione.
- La modifica committata attiva la creazione di progetti e repository specifici per l'applicazione.
- Cloud Build completa quanto segue:
- Crea due nuovi repository Git per ospitare il codice sorgente e la IaC dell'applicazione.
- 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 l'attivatore IaC di Cloud Build.
- L'attivatore IaC 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 Federation per 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.
- Se vuoi, il team di applicazioni utilizza l'attivatore IaC di Cloud Build per eseguire il deployment di progetti e risorse aggiuntive (ad esempio database e altri servizi gestiti) in progetti monoutente dedicati, uno per ogni ambiente.
Gestione della configurazione e delle norme di GKE Enterprise
Nel blueprint, gli amministratori della piattaforma per gli 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 l'adesione allo stato scelto, nonostante le modifiche manuali. Le configurazioni vengono applicate agli ambienti (sviluppo, non di produzione e di produzione) utilizzando una strategia di branching nel repository.
In questo blueprint, Config Sync applica le limitazioni di Policy Controller. Queste configurazioni definiscono i controlli di sicurezza e conformità come definiti dagli amministratori della piattaforma per gli sviluppatori dell'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 di ambito del parco veicoli crea gli spazi dei nomi e le associazioni di ruoli associati.
Passaggi successivi
- Scopri di più sull'architettura dell'applicazione Cymbal Bank (documento successivo di questa serie).