Implementazioni sicure con Config Sync

Questo documento mostra agli operatori dei cluster e agli amministratori della piattaforma come implementare in modo sicuro le modifiche in più ambienti utilizzando Config Sync. Questo approccio può aiutarti a evitare errori che interessano tutti gli ambienti contemporaneamente.

Config Sync consente di gestire cluster singoli, cluster multi-tenant e configurazioni Kubernetes multi-cluster utilizzando i file archiviati in un repository Git.

Le configurazioni possono rappresentare diverse cose, tra cui:

• Oggetti GKE standard, ad esempio risorse NetworkPolicies, risorse DaemonSets o risorse RoleBindings.
• Google Cloud , ad esempio istanze Compute Engine o database Cloud SQL, tramite Config Connector.
• Vincoli alla configurazione stessa, tramite Policy Controller.

Config Sync è particolarmente adatto per il deployment di configurazioni, policy e workload necessari per eseguire la piattaforma che crei su Google Kubernetes Engine, ad esempio agent di sicurezza, agent di monitoraggio e gestori di certificati.

Sebbene tu possa eseguire il deployment di applicazioni rivolte agli utenti con Config Sync, non consigliamo di collegare il ciclo di vita di rilascio al ciclo di vita di rilascio dei carichi di lavoro amministrativi menzionati in precedenza. Ti consigliamo invece di utilizzare uno strumento dedicato all'implementazione delle applicazioni, ad esempio uno strumento di implementazione continua, in modo che i team delle applicazioni possano gestire la propria pianificazione delle release.

Config Sync è un prodotto potente in grado di gestire molti elementi, quindi hai bisogno di misure di salvaguardia per evitare errori che hanno un impatto importante. Questo documento descrive diversi metodi per creare guardrail. La prima sezione riguarda i lanci scaglionati, mentre la seconda si concentra su test e convalide. La terza sezione mostra come monitorare i deployment.

Nota: questo tutorial utilizza un repository Git per spiegare come implementare i rollout. Sono supportate anche le immagini OCI e i grafici Helm.

Implementare le implementazioni graduali con Config Sync

In un ambiente multicluster, non è consigliabile applicare una modifica alla configurazione in tutti i cluster contemporaneamente. Un rollout scaglionato, cluster per cluster, è molto più sicuro perché riduce il potenziale impatto di qualsiasi errore.

Esistono diversi modi per implementare i rollout scaglionati con Config Sync:

• Utilizza i commit o i tag Git per applicare manualmente le modifiche che vuoi ai cluster.
• Utilizza i rami Git per applicare automaticamente le modifiche quando vengono unite. Puoi utilizzare rami diversi per gruppi diversi di cluster.
• Utilizza gli oggetti ClusterSelector e NamespaceSelector per applicare in modo selettivo le modifiche a sottogruppi di cluster o spazi dei nomi.

Tutti i metodi per i lanci scaglionati presentano vantaggi e svantaggi. La tabella seguente mostra quali di questi metodi puoi utilizzare contemporaneamente:

Compatibilità	Commit o tag Git	Rami Git	Selettori di cluster	Selettori dello spazio dei nomi
Commit o tag Git		Non compatibile	Compatibile	Compatibile
Rami Git	Non compatibile		Compatibile	Compatibile
Selettori di cluster	Compatibile	Compatibile		Compatibile
Selettori dello spazio dei nomi	Compatibile	Compatibile	Compatibile

Il seguente albero decisionale può aiutarti a decidere quando utilizzare uno dei metodi di implementazione graduale.

Nota :Config Sync consente di sincronizzare le configurazioni da più repository: un repository per le configurazioni con ambito cluster e un repository facoltativo per spazio dei nomi. Anche se l'utilizzo dei selettori di spazi dei nomi è diverso quando si utilizzano più repository, puoi comunque applicare tutti gli altri metodi descritti in questa sezione ai repository da cui sincronizzi le configurazioni.

Utilizzare commit o tag Git

Rispetto agli altri metodi di implementazione graduale, l'utilizzo di commit o tag Git offre il massimo controllo ed è il più sicuro. Puoi utilizzare la pagina Config Sync nella Google Cloud console per aggiornare più cluster contemporaneamente. Utilizza questo metodo se vuoi applicare le modifiche ai cluster uno alla volta e controllare esattamente quando ciò avviene.

In questo metodo, "blocchi" ogni cluster a una versione specifica (un commit o un tag) del repository. Questo metodo è simile all'utilizzo del commit Git come tag dell'immagine container. Implementa questo metodo specificando il commit, il tag o l'hash nel campo spec.git.revision della risorsa personalizzata RootSync o RepoSync.

Se gestisci le risorse personalizzate RootSync o RepoSync con uno strumento come Kustomize, puoi ridurre la quantità di lavoro manuale necessaria per i rollout. Con questo strumento, devi solo modificare il parametro revision in un'unica posizione e poi applicare in modo selettivo la nuova risorsa personalizzata RootSync o RepoSync ai tuoi cluster nell'ordine e al ritmo che preferisci.

Inoltre, puoi utilizzare la console Google Cloud per aggiornare il parametro revision per più cluster appartenenti allo stesso parco risorse contemporaneamente. Tuttavia, se disponi di un sistema automatizzato per aggiornare le configurazioni, non ti consigliamo di utilizzare la console Google Cloud per apportare modifiche alla configurazione.

Ad esempio, la seguente definizione RootSync configura Config Sync per utilizzare il tag 1.2.3:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-sync-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: [e-mail]:gke/config-sync.git
    revision: 1.2.3
    auth: ssh

Se applichi questa configurazione al tuo cluster, Config Sync utilizzerà il tag 1.2.3 del repository example.com:gke/config-sync.git.

Per aggiornare un cluster, modifica il campo spec.git.revision con il nuovo valore per il cluster. In questo modo puoi definire quali cluster vengono aggiornati e quando. Se devi rollbacke una modifica, riporta il campo spec.git.revision al valore precedente.

Il seguente diagramma illustra la procedura di implementazione per questo metodo. Innanzitutto, esegui il commit delle modifiche al repository Config Sync, poi aggiorna le definizioni RootSync su tutti i cluster:

Consigliamo di eseguire queste operazioni:

• Utilizza gli ID commit Git anziché i tag. A causa del modo in cui funziona Git, hai la garanzia che non cambieranno mai. Ad esempio, un git push --force non può modificare il commit utilizzato da Config Sync. Questo approccio è utile ai fini del controllo e per monitorare quale commit stai utilizzando nei log. Inoltre, a differenza dei tag, non è previsto un passaggio aggiuntivo per eseguire il commit degli ID.
• Se preferisci utilizzare i tag Git anziché gli ID commit Git, puoi proteggere i tag se utilizzi una soluzione Git che supporta la protezione.
• Se vuoi aggiornare più cluster contemporaneamente, puoi farlo nella Google Cloud console. Per aggiornare più cluster contemporaneamente, devono far parte dello stesso parco risorse (e trovarsi nello stesso progetto).

Utilizzare i rami Git

Se vuoi che le modifiche vengano applicate ai cluster non appena vengono unite nel repository Git, configura Config Sync in modo che utilizzi i rami Git anziché i commit o i tag. In questo metodo, crei più rami di lunga durata nel repository Git e configuri Config Sync in cluster diversi per leggere la configurazione da rami diversi.

Ad esempio, un pattern semplice ha due rami:

• Un branch staging per i cluster non di produzione.
• Un branch main per i cluster di produzione.

Avviso: se hai a che fare con un numero elevato di cluster e ambienti, potresti aver bisogno di un numero elevato di rami. che può diventare rapidamente difficile da gestire. Per questo motivo, ti consigliamo di utilizzare i commit Git anziché i rami.

Per i cluster non di produzione, crea l'oggetto RootSync o RepoSync con il campo spec.git.branch impostato su staging. Per i cluster di produzione, crea l'oggetto RootSync o RepoSync con il parametro spec.git.branch impostato su main.

Ad esempio, la seguente definizione RootSync configura Config Sync per utilizzare il ramo main:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-sync-system
spec:
  git:
    repo: [e-mail]:gke/config-sync.git
    branch: main
    auth: ssh

Il seguente diagramma illustra la procedura di implementazione per questo metodo:

Puoi adattare questo pattern a esigenze specifiche, utilizzando più di due rami o rami mappati a elementi diversi dagli ambienti. Se devi rollback una modifica, utilizza il comando git revert per creare un nuovo commit sullo stesso ramo che annulla le modifiche del commit precedente.

Consigliamo di eseguire queste operazioni:

• Quando gestisci più cluster, utilizza almeno due rami Git per distinguere tra cluster di produzione e non di produzione.
• La maggior parte delle soluzioni Git consente di utilizzare la funzionalità dei rami protetti per impedire eliminazioni o modifiche non esaminate di questi rami. Per saperne di più, consulta la documentazione di GitHub, GitLab e Bitbucket.

Utilizza gli oggetti ClusterSelector e NamespaceSelector

I rami Git sono un buon modo per eseguire un'implementazione graduale delle modifiche in più cluster che alla fine avranno tutti le stesse norme. Tuttavia, se vuoi implementare una modifica solo in un sottoinsieme di cluster o di spazi dei nomi, utilizza gli oggetti ClusterSelector e NamespaceSelector. Questi oggetti hanno uno scopo simile: consentono di applicare oggetti solo a cluster o spazi dei nomi che hanno etichette specifiche.

Ad esempio:

• Utilizzando gli oggetti ClusterSelector, puoi applicare criteri diversi ai cluster, a seconda del paese in cui si trovano, per vari regimi di conformità.
• Utilizzando gli oggetti NamespaceSelector, puoi applicare policy diverse agli spazi dei nomi utilizzati da un team interno e da un collaboratore esterno.

Gli oggetti ClusterSelector e NamespaceSelector ti consentono anche di implementare metodologie avanzate di test e rilascio, ad esempio:

• Versioni canary delle policy, in cui implementi una nuova policy in un piccolo sottoinsieme di cluster e spazi dei nomi per un lungo periodo di tempo per studiarne l'impatto.
• Test A/B, in cui vengono implementate versioni diverse della stessa policy in cluster diversi per studiare la differenza di impatto delle versioni della policy e poi scegliere la migliore da implementare ovunque.

Ad esempio, immagina un'organizzazione con diversi cluster di produzione. Il team della piattaforma ha già creato due categorie di cluster di produzione, chiamate canary-prod e prod, utilizzando gli oggetti Cluster e ClusterSelector (vedi Utilizzare ClusterSelector).

Il team della piattaforma vuole implementare un criterio con Policy Controller per imporre la presenza di un'etichetta del team negli spazi dei nomi per identificare a quale team appartiene ogni spazio dei nomi. Hanno già implementato una versione di questa policy in modalità dry run e ora vogliono applicarla a un numero ridotto di cluster. Utilizzando gli oggetti ClusterSelector, creano due risorse K8sRequiredLabels diverse che vengono applicate a cluster diversi.

• La risorsa K8sRequiredLabels viene applicata ai cluster di tipo prod, con un parametro enforcementAction impostato su dryrun:

  apiVersion: constraints.gatekeeper.sh/v1beta1
  kind: K8sRequiredLabels
  metadata:
    name: ns-must-have-team
    annotations:
      configmanagement.gke.io/cluster-selector: prod
  Spec:
    enforcementAction: dryrun
    match:
      kinds:
        - apiGroups: [""]
          kinds: ["Namespace"]
    parameters:
      labels:
        - key: "team"
  

• La risorsa K8sRequiredLabels viene applicata ai cluster di tipo canary-prod, senza il parametro enforcementAction, il che significa che la policy viene effettivamente applicata:

  apiVersion: constraints.gatekeeper.sh/v1beta1
  kind: K8sRequiredLabels
  metadata:
    name: ns-must-have-team
    annotations:
      configmanagement.gke.io/cluster-selector: canary-prod
  spec:
    match:
      kinds:
        - apiGroups: [""]
      kinds: ["Namespace"]
    parameters:
      labels:
        - key: "team"
  

L'annotazione configmanagement.gke.io/cluster-selector consente al team di applicare il criterio solo nei cluster di tipo canary-prod, impedendo la diffusione di eventuali effetti collaterali indesiderati all'intera flotta di produzione. Per ulteriori informazioni sulla funzionalità di prova di Policy Controller, consulta la sezione Creazione di vincoli.

Consigliamo di eseguire queste operazioni:

• Utilizza gli oggetti ClusterSelector e NamespaceSelector se devi applicare una modifica alla configurazione solo a un sottoinsieme di cluster o spazi dei nomi indefinitamente o per un lungo periodo di tempo.
• Se implementi una modifica utilizzando i selettori, fai molta attenzione. Se utilizzi i commit Git, qualsiasi errore interessa un solo cluster alla volta, perché l'implementazione viene eseguita cluster per cluster. Tuttavia, se utilizzi i rami Git, qualsiasi errore può influire su tutti i cluster che utilizzano quel ramo. Se utilizzi i selettori, l'errore può interessare tutti i cluster contemporaneamente.

Implementazione di revisioni, test e convalide

Uno dei vantaggi di Config Sync è che gestisce tutto in modo dichiarativo: risorse Kubernetes, risorse cloud e criteri. Ciò significa che i file in un sistema di gestione del controllo del codice sorgente rappresentano le risorse (file Git, nel caso di Config Sync). Questa caratteristica ti consente di implementare i flussi di lavoro di sviluppo che utilizzi già per il codice sorgente di un'applicazione: revisioni e test automatizzati.

Implementare le recensioni

Poiché Config Sync si basa su Git, puoi utilizzare la tua soluzione Git preferita per ospitare il repository Config Sync. La tua soluzione Git probabilmente ha una funzionalità di revisione del codice, che puoi utilizzare per esaminare le modifiche apportate al repository Config Sync.

Le best practice per la revisione delle modifiche al tuo repository sono le stesse di una normale revisione del codice, ovvero:

• Esercitati con lo sviluppo basato su trunk.
• Lavora in piccoli batch.
• Assicurati che la revisione del codice venga eseguita in modo sincrono o almeno tempestivo.
• La persona che esamina e approva la modifica non deve essere la stessa che l'ha suggerita.

A causa della sensibilità del codebase di Config Sync, ti consigliamo anche di eseguire le seguenti configurazioni, se possibile con la tua soluzione Git:

• Proteggi i rami utilizzati direttamente dai cluster. Consulta la documentazione di GitHub, GitLab e Bitbucket. GitLab ti consente anche di proteggere i tag.
• Una volta protette le filiali, puoi perfezionare le approvazioni necessarie per unire una modifica:
  • Su GitHub, attiva le revisioni obbligatorie.
  • Per GitLab, utilizza Proprietari del codice per delegare le autorizzazioni di approvazione in base a file o directory. Puoi utilizzare le approvazioni delle richieste di unione per richiedere l'approvazione di una richiesta da parte di persone diverse di team diversi prima che venga unita.
  • Su Bitbucket, combina i revisori predefiniti con i controlli di unione predefiniti. Se vuoi, puoi utilizzare un plug-in Code Owners per Bitbucket Server disponibile su Atlassian Marketplace per controllare chi può approvare le modifiche per le sottosezioni del repository.

Utilizzando queste diverse funzionalità, puoi applicare le approvazioni per ogni richiesta di modifica al tuo codebase. Ad esempio, puoi assicurarti che ogni modifica venga approvata almeno da un membro del team della piattaforma (che gestisce la flotta di cluster) e da un membro del team di sicurezza (che ha il compito di definire e implementare i criteri di sicurezza).

Ti consigliamo di procedere come segue:

• Applica revisioni tra pari al tuo repository e proteggi i rami Git utilizzati dai tuoi cluster.

Implementare test automatici

Una best practice comune quando si lavora su un codebase è implementare l'integrazione continua. Ciò significa che configuri i test automatizzati da eseguire quando viene creata o aggiornata una richiesta di modifica. I test automatici possono rilevare molti errori prima che un operatore esamini la richiesta di modifica. In questo modo, il ciclo di feedback per lo sviluppatore viene ristretto. Puoi implementare la stessa idea, utilizzando gli stessi strumenti, per il repository Config Sync.

Ad esempio, un buon punto di partenza è eseguire il comando nomos vet automaticamente in caso di nuove modifiche. Questo comando convalida la sintassi del repository Config Sync. Puoi implementare questo test utilizzando Cloud Build seguendo il tutorial Convalida delle configurazioni. Puoi integrare Cloud Build con le seguenti opzioni:

• Bitbucket, utilizzando i trigger di build.
• GitHub, utilizzando l'app GitHub di Google Cloud Build. I trigger di build sono disponibili anche per GitHub, ma l'applicazione GitHub è il metodo di integrazione preferito.

Come puoi vedere nell'esercitazione Convalida delle configurazioni, il test viene eseguito utilizzando un'immagine container. Pertanto, puoi implementare il test in qualsiasi soluzione di integrazione continua che esegue container, non solo Cloud Build.

Per rendere ancora più efficace il ciclo di feedback, puoi chiedere agli utenti di eseguire il comando nomos vet come hook pre-commit di Git. Un avvertimento è che alcuni utenti potrebbero non avere accesso ai cluster Kubernetes gestiti da Config Sync e potrebbero non essere in grado di eseguire la convalida completa dalla propria workstation. Esegui il comando nomos vet --clusters "" per limitare la convalida ai controlli semantici e sintattici.

Ti consigliamo di procedere come segue:

• Implementa i test in una pipeline di integrazione continua.
• Esegui almeno il comando nomos vet su tutte le modifiche suggerite.

Monitoraggio delle implementazioni

Anche se implementi tutte le misure di salvaguardia descritte in questo documento, possono comunque verificarsi errori. Di seguito sono riportati due tipi comuni di errori:

• Errori che non rappresentano un problema per Config Sync, ma impediscono il corretto funzionamento dei tuoi workload, ad esempio una NetworkPolicy eccessivamente restrittiva che impedisce la comunicazione dei componenti del tuo workload.
• Errori che impediscono a Config Sync di applicare le modifiche a un cluster, ad esempio un manifest Kubernetes non valido o un oggetto rifiutato da un admission controller. I metodi spiegati in precedenza dovrebbero rilevare la maggior parte di questi errori.

Il rilevamento degli errori descritti nel primo punto elenco precedente è quasi impossibile a livello di Config Sync perché ciò richiede la comprensione dello stato di ciascuno dei tuoi workload. Per questo motivo, il rilevamento di questi errori viene eseguito al meglio dal sistema di monitoraggio esistente che ti avvisa quando un'applicazione non funziona correttamente.

Il rilevamento degli errori descritti nel secondo punto elenco precedente, che dovrebbero essere rari se hai implementato tutte le misure di salvaguardia, richiede una configurazione specifica. Per impostazione predefinita, Config Sync scrive gli errori nei suoi log (che troverai, per impostazione predefinita, in Cloud Logging). Gli errori vengono visualizzati anche nella pagina della console Config Sync Google Cloud . Di solito, né i log né la console sono sufficienti per rilevare gli errori, perché probabilmente non li monitori in ogni momento. Il modo più semplice per automatizzare il rilevamento degli errori è eseguire il nomos status comando, che indica se si è verificato un errore in un cluster.

Puoi anche configurare una soluzione più avanzata con avvisi automatici per gli errori. Config Sync espone le metriche nel formato Prometheus. Per saperne di più, vedi Monitoraggio di Config Sync.

Dopo aver inserito le metriche di Config Sync nel sistema di monitoraggio, crea un avviso per ricevere una notifica quando la metrica gkeconfig_monitor_errors è maggiore di 0. Per saperne di più, consulta la sezione relativa alla gestione delle norme di avviso per Cloud Monitoring o regole di avviso per Prometheus.

Riepilogo dei meccanismi per implementazioni sicure con Config Sync

La tabella seguente riassume i vari meccanismi descritti in precedenza in questo documento. Nessuno di questi meccanismi è esclusivo. Puoi scegliere di utilizzarne alcuni o tutti per scopi diversi.

Meccanismo	A cosa serve	Per cosa non è adatto	Caso d'uso di esempio
ID commit Git e tag	Utilizza ID commit Git o tag specifici per controllare con precisione a quali cluster vengono applicate le modifiche.	Non utilizzare ID commit o tag Git per differenze di lunga durata tra i cluster. Utilizza i selettori di cluster.	Tutti i tuoi cluster sono configurati per applicare il commit Git 12345. Apporti una modifica con un nuovo commit, abcdef, che vuoi testare. Modifica la configurazione di un singolo cluster per utilizzare questo nuovo commit per convalidare la modifica.
Rami Git	Utilizza più rami Git quando vuoi implementare la stessa modifica in più ambienti, uno dopo l'altro.	Non utilizzare più rami Git per differenze di lunga durata tra i cluster. I rami divergeranno in modo significativo e sarà difficile unirli di nuovo.	Innanzitutto, unisci la modifica nel ramo di staging, dove verrà recuperata dai cluster di staging. Poi unisci la modifica nel ramo master, dove verrà recuperata dai cluster di produzione.
Selettori di cluster e selettori di spazi dei nomi	Utilizza i selettori per le differenze a lungo termine tra cluster e spazi dei nomi.	Non utilizzare i selettori per un lancio graduale in più ambienti. Se vuoi testare una modifica prima in staging e poi eseguirne il deployment in produzione, utilizza rami Git separati.	Se i team di sviluppo delle applicazioni hanno bisogno dell'accesso completo ai cluster di sviluppo, ma dell'accesso in sola lettura ai cluster di produzione, utilizza l'oggetto ClusterSelector per applicare i criteri RBAC corretti solo ai cluster pertinenti.
Revisioni dei compagni	Utilizza le revisioni tra pari per assicurarti che i team pertinenti approvino le modifiche.	I revisori non rilevano tutti gli errori, in particolare quelli di sintassi.	La tua organizzazione impone che il team di sicurezza esamini le modifiche alla configurazione che interessano più sistemi. Chiedi a un membro del team di sicurezza di rivedere le modifiche.
Test automatizzati nella pipeline di integrazione continua	Utilizza i test automatici per rilevare gli errori nelle modifiche suggerite.	I test automatici non possono sostituire completamente un revisore umano. Utilizza entrambi.	L'esecuzione di un comando nomos vet su tutte le modifiche suggerite conferma che il repository è una configurazione Config Sync valida.
Monitorare gli errori di sincronizzazione	Assicurati che Config Sync applichi effettivamente le modifiche ai tuoi cluster.	Gli errori di sincronizzazione si verificano solo se Config Sync tenta di applicare un repository non valido o se il server API Kubernetes rifiuta alcuni degli oggetti.	Un utente ignora tutti i test e le revisioni e esegue il commit di una modifica non valida nel repository Config Sync. Questa modifica non può essere applicata ai tuoi cluster. Se monitori gli errori di sincronizzazione, riceverai un avviso in caso di errore.

Esempio di strategia di implementazione

Questa sezione utilizza i concetti introdotti nel resto dell'articolo per aiutarti a creare una strategia di implementazione end-to-end in tutti i cluster della tua organizzazione. Questa strategia presuppone che tu abbia parchi risorse separati per sviluppo, gestione temporanea e produzione (come mostrato in Esempio di parco risorse 1 - Approccio 1).

Avviso: questa strategia di implementazione è complessa. Ha senso implementarlo solo se hai un'infrastruttura complessa con almeno due parchi risorse e almeno tre cluster per parco risorse. Se hai un numero elevato di parchi veicoli, ma con un singolo cluster in ciascuno, puoi adattare questa strategia utilizzando "parchi veicoli canary" anziché "cluster canary".

In questo scenario, configuri ogni cluster in modo che si sincronizzi con il tuo repository Git utilizzando un commit Git specifico. L'implementazione di una modifica a un determinato parco risorse è una procedura in quattro passaggi:

1. Aggiorni un singolo cluster (il "canarino") nel parco risorse per utilizzare prima il nuovo commit.
2. Verifichi che tutto funzioni come previsto eseguendo test e monitorando l'implementazione.
3. Aggiorna il resto dei cluster nel parco risorse.
4. Verifica di nuovo che tutto funzioni come previsto.

Per implementare una modifica in tutti i cluster, ripeti questa procedura per ogni parco risorse. Tecnicamente, puoi applicare questo metodo a qualsiasi commit Git, da qualsiasi ramo. Tuttavia, ti suggeriamo di adottare la seguente procedura per identificare i problemi nelle prime fasi della procedura di revisione:

1. Quando qualcuno apre una richiesta di modifica nel repository Git di Config Sync, esegui il deployment della modifica in uno dei cluster di sviluppo.
2. Se la richiesta di modifica viene accettata e unita al ramo principale, esegui l'implementazione completa in tutte le flotte come descritto in precedenza.

Sebbene alcune modifiche possano essere destinate solo a una flotta specifica, ti consigliamo di implementare tutte le modifiche in tutte le flotte. Questa strategia elimina il problema di monitorare quale flotta deve essere sincronizzata con quale commit. Presta particolare attenzione alle modifiche che riguardano solo la flotta di produzione, perché non sarà stato possibile eseguire test adeguati nelle flotte precedenti. Ad esempio, ciò significa attendere più a lungo prima che vengano visualizzati i problemi tra il deployment nei cluster canary e nel resto dei cluster.

Per riassumere, un deployment end-to-end completo ha il seguente aspetto:

1. Qualcuno apre una richiesta di modifica.
2. Vengono eseguiti test e convalide automatici e viene effettuata una revisione manuale.
3. Attiva manualmente un job per eseguire il deployment della modifica nel cluster canary nel parco risorse di sviluppo. In questo cluster vengono eseguiti test automatici end-to-end.
4. Se tutto va bene, unisci la richiesta di modifica al ramo principale.
5. L'unione attiva un job automatizzato per eseguire il deployment del nuovo commit di punta del ramo principale nel cluster canary nel parco risorse di sviluppo. I test end-to-end automatici vengono eseguiti in questo cluster (per rilevare potenziali incompatibilità tra due richieste di modifica create e unite all'incirca nello stesso momento).
6. I seguenti job vengono eseguiti uno dopo l'altro (vengono attivati manualmente o dopo un periodo di tempo predefinito per consentire agli utenti di segnalare regressioni):
   1. Esegui il deployment in tutti i cluster del parco risorse di sviluppo.
   2. Esegui test e convalide nei cluster del parco risorse di sviluppo.
   3. Esegui il deployment nel cluster canary del parco risorse di staging.
   4. Esegui test e convalide nel cluster canary del parco risorse di gestione temporanea.
   5. Esegui il deployment in tutti i cluster del parco risorse di staging.
   6. Esegui test e convalide nei cluster del parco risorse di gestione temporanea.
   7. Esegui il deployment nel cluster canary del parco risorse di produzione.
   8. Esegui test e convalide nel cluster canary del parco risorse di produzione.
   9. Esegui il deployment su tutti i cluster del parco risorse di produzione.
   10. Esegui test e convalide nei cluster del parco risorse di produzione.

Passaggi successivi

• Scopri di più sul monitoraggio di Config Sync.
• Scopri di più sui parchi risorse.
• Scopri come convalidare la tua app in base ai criteri aziendali in una pipeline di integrazione continua.