Il deployment del progetto base dell'applicazione aziendale viene eseguito attraverso una serie sistemi e pipeline. Ogni pipeline esegue il deployment di un particolare progetto. 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 progetto utilizza le seguenti pipeline:
- La pipeline dell'infrastruttura di base (parte degli elementi di base aziendali progetto) esegue il deployment della fabbrica delle applicazioni, l'infrastruttura multi-tenant e la pipeline con ambito del parco risorse.
- La pipeline di infrastruttura multi-tenant esegue il deployment dei cluster GKE e degli altri servizi gestiti su cui si basa il blueprint dell'applicazione aziendale.
- 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 di cui eseguire il deployment in cluster GKE.
- Config Sync esegue il deployment e gestisce ulteriori configurazioni Kubernetes, inclusi i vincoli di Policy Controller.
Repository, collaboratori dei repository e approvatori delle modifiche ai repository
Le pipeline dei blueprint vengono attivate tramite modifiche ai repository Git. La tabella seguente descrive i repository utilizzati in tutto il progetto, chi contribuisce al repository, chi approva modifiche al repository, quale pipeline utilizza il repository, del repository.
| Repository | Collaboratore del repository | Responsabile approvazione modifiche repository | Pipeline | Descrizione |
|---|---|---|---|---|
|
Sviluppatore piattaforma per sviluppatori |
Amministratore di 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 di piattaforma per sviluppatori |
Infrastruttura multi-tenant |
I moduli Terraform utilizzati dai team della piattaforma per sviluppatori quando creano infrastruttura |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore di piattaforma per sviluppatori |
Ambito parco risorse |
Il repository che definisce gli ambiti e gli spazi dei nomi dei team del parco risorse parco risorse |
|
Sviluppatore della piattaforma per sviluppatori |
Amministratore di 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 |
Fabbrica dell'applicazione |
Il codice di base inserito nel repository |
|
Sviluppatore piattaforma per sviluppatori |
Amministratore di piattaforma per sviluppatori |
Fabbrica dell'applicazione 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, verificabilità, 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 i tenant del Google Cloud. |
|
Crea spazi dei nomi e associazioni di ruoli RBAC. |
|
Crea le pipeline CI/CD dell'applicazione utilizzate per eseguire il deployment dei servizi. |
Pipeline dell'infrastruttura multi-tenant
La pipeline dell'infrastruttura dell'infrastruttura multi-tenant esegue il deployment di parchi risorse, cluster GKE e le relative risorse condivise. Il seguente diagramma mostra 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 un'applicazione coerente dei criteri. |
Crea la chiave di crittografia basata sul modello chiave di crittografia (CMEK) per GKE, AlloyDB per PostgreSQL e tramite 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 da Google Cloud Armor web application firewall. |
Pipeline a livello di parco risorse
La pipeline con ambito del parco risorse è responsabile della configurazione degli spazi dei nomi e dell'RBAC associazioni nei cluster GKE del parco risorse. La tabella seguente descrive i componenti che vengono generati dalla pipeline di ambito del 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. Questo infrastruttura include un progetto Google Cloud che contiene CI/CD dell'applicazione una pipeline o un blocco note personalizzato.
Man mano che le organizzazioni di ingegneria scalano, il team delle applicazioni può introdurre nuovi che utilizzano la fabbrica di applicazioni. Lo scaling 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 creare applicazioni: pipeline che richiedono
Cloud Build per completare quanto segue:
- Crea una definizione di applicazione dichiarativa e memorizzala nel catalogo dell'applicazione.
- Applicare la definizione di applicazione dichiarativa per creare l'applicazione Google Cloud.
- 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 procedure standard e che vengono usati per più scopi, tra cui l'onboarding delle applicazioni e e deployment continuo.
La tabella seguente 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 utilizzata per la compilazione e il deployment di un'applicazione specifica. |
Pipeline CI/CD dell'applicazione |
Una pipeline basata su Cloud Build utilizzata per la connessione di codice sorgente e fornisce una pipeline CI/CD per il deployment i servizi di machine learning. |
Pipeline CI/CD dell'applicazione
La pipeline CI/CD dell'applicazione consente la creazione e il deployment automatizzati basate su container. La pipeline è composta 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 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 privato e gestire kubeconfig
dell'autenticazione, la pipeline CI/CD dell'applicazione interagisce con
cluster GKE tramite il gateway Connect. La pipeline utilizza anche
pool privati
per l'ambiente CI/CD.
Ogni repository di codice sorgente delle applicazioni include le configurazioni di Kubernetes. Queste configurazioni consentono l'esecuzione corretta delle applicazioni come 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 sulla 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 progetto per configurare il bilanciamento del carico delle località per est-ovest per via del traffico. |
|
Imposta il controllo dell'accesso tra i carichi di lavoro nel mesh di servizi. |
|
Definisce l'identità utilizzata da un servizio Kubernetes. La federazione delle identità per i carichi di lavoro per GKE 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 è richiesta dai 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. Google CloudBackendPolicy viene utilizzato solo dai deployment che ricevono per via del traffico. |
|
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 di codice sorgente dell'applicazione. Questa operazione attiva Cloud Build per avviare la pipeline di integrazione.
- Cloud Build crea un'immagine container, push l'immagine container ad Artifact Registry e crea un digest 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 container:
- Cloud Build analizza il container utilizzando i test della struttura del container il modello di machine learning. Questo framework esegue test di comandi, test di esistenza dei file, dei contenuti 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 risultati della scansione riusciti.
- Autorizzazione binaria firma l'immagine. L'autorizzazione di codice binario è un servizio su Google Cloud che fornisce la sicurezza della catena di approvvigionamento del software per le applicazioni basate su container utilizzando criteri, 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 Insight sulla sicurezza. Queste informazioni includono vulnerabilità rilevati tramite Artifact Analysis e il livello di garanzia della sicurezza della build indicato dalle linee guida SLSA.
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 Cloud Deploy al lancio le immagini container appena create in modo progressivo.
- Cloud Deploy avvia un'implementazione nel primo ambiente della pipeline di deployment, che in genere è di sviluppo. Ogni fase del deployment configurate in modo da richiedere l'approvazione manuale.
- Le pipeline Cloud Deploy utilizzano il deployment sequenziale per di immagini a ciascun cluster in un ambiente.
- 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 applicazione definisce una nuova applicazione all'interno del proprio tenant eseguendo un trigger di Cloud Build per generare l'applicazione definizione di Kubernetes.
- Il trigger aggiunge una nuova voce per l'applicazione in Terraform ed esegue il commit della al repository di fabbrica delle applicazioni.
- La modifica di cui è stato eseguito il commit attiva la creazione di applicazioni repository e progetti.
- 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.
- Il trigger IaC di Cloud Build per l'applicazione crea 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 Federazione delle identità per i carichi di lavoro per le configurazioni GKE ai cluster GKE multi-tenant.
- La pipeline di creazione degli ambiti del parco risorse crea l'ambito e lo spazio dei nomi del parco risorse per per l'applicazione su cluster GKE multi-tenant.
- La pipeline CI/CD dell'applicazione esegue il deployment iniziale ai 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 progetto, gli amministratori della piattaforma per sviluppatori usano Configurazione Sync per creare configurazioni a livello di cluster in ciascun 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. Configurazioni vengono applicate agli ambienti (sviluppo, non di produzione e produzione) usando una strategia di ramificazione nel repository.
In questo blueprint, Config Sync applica le limitazioni di Policy Controller. Queste configurazioni definiscono i controlli di sicurezza e conformità definiti dagli amministratori della piattaforma sviluppatori dell'organizzazione. Questo blueprint si basa su altre pipeline per applicare altre configurazioni: le pipeline CI/CD dell'applicazione applicano una configurazione specifica dell'applicazione e la pipeline di ambito parco veicoli crea spazi dei nomi e associazioni di ruoli associati.
Passaggi successivi
- Scopri di più sull'architettura dell'applicazione Cymbal Bank (documento successivo di questa serie).