Implementazioni sicure con Config Sync
Questo documento mostra agli operatori dei cluster e agli amministratori di piattaforma come implementare in modo sicuro le modifiche in più ambienti utilizzando Config Sync. Questo approccio può aiutarti a evitare errori che interessano tutti i tuoi ambienti contemporaneamente.
Config Sync consente di gestire singoli cluster, cluster multi-tenant e configurazioni Kubernetes multi-cluster utilizzando file archiviati in un repository Git.
Le configurazioni possono rappresentare diversi elementi, tra cui:
- Oggetti GKE standard, come le risorse NetworkPolicies, le risorse DaemonSets o RoleBindings.
- Risorse Google Cloud, ad esempio istanze di Compute Engine o database Cloud SQL, tramite Config Connector.
- Vincoli sulla configurazione stessi, tramite Policy Controller.
Config Sync è particolarmente adatto per il deployment di configurazioni, criteri e carichi di lavoro necessari per eseguire la piattaforma che crei sulla versione Google Kubernetes Engine (GKE) Enterprise, ad esempio agenti di sicurezza, agenti di monitoraggio e gestori di certificati.
Sebbene sia possibile eseguire il deployment di applicazioni rivolte agli utenti con Config Sync, non è consigliabile collegare il loro ciclo di vita della release al ciclo di vita della release dei carichi di lavoro amministrativi menzionati in precedenza. Ti consigliamo invece di utilizzare uno strumento dedicato al deployment delle applicazioni, ad esempio uno strumento di deployment continuo, in modo che i team delle applicazioni possano essere responsabili della pianificazione delle release.
Config Sync è un prodotto potente che può gestire molti elementi, pertanto sono necessari sistemi di protezione per evitare errori con un impatto significativo. Questo documento descrive diversi metodi per creare sistemi di protezione. La prima sezione riguarda le implementazioni graduali, mentre la seconda si concentra sui test e sulle convalide. La terza sezione mostra come monitorare i deployment.
Implementazione delle implementazioni graduali con Config Sync
In un ambiente multi-cluster, una situazione comune per gli utenti di GKE Enterprise, sconsigliamo di applicare contemporaneamente una modifica alla configurazione a tutti i cluster. Un'implementazione graduale, cluster per cluster, è molto più sicura perché riduce il potenziale impatto di qualsiasi errore.
Esistono diversi modi per implementare le implementazioni graduali con Config Sync:
- Utilizza i commit o i tag Git per applicare manualmente le modifiche da apportare ai cluster.
- Utilizza i rami Git per applicare automaticamente le modifiche quando vengono unite. Puoi utilizzare rami diversi per gruppi di cluster differenti.
- Usa gli oggetti
ClusterSelector
eNamespaceSelector
per applicare selettivamente le modifiche ai sottogruppi di cluster o spazi dei nomi.
Tutti i metodi per le implementazioni graduali 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.
Utilizzare commit o tag Git
Rispetto agli altri metodi dell'implementazione graduale, l'uso di commit o tag Git offre il massimo controllo ed è il più sicuro. Puoi utilizzare la pagina Config Sync nella console Google Cloud nella console per aggiornare più cluster contemporaneamente. Utilizza questo metodo se vuoi applicare le modifiche ai cluster uno alla volta e controllare esattamente quando succede.
In questo metodo, puoi "fissare" ogni cluster a una versione specifica (un commit o un tag) del tuo repository. Questo metodo è simile all'utilizzo del commit Git come tag dell'immagine container.
Puoi implementare questo metodo specificando il commit, il tag o l'hash nel campo spec.git.revision
della risorsa personalizzata RootSync
o RepoSync
.
Se gestisci le tue risorse personalizzate RootSync
o RepoSync
con uno strumento come
Kustomize,
puoi ridurre il lavoro manuale richiesto per le implementazioni. Con uno strumento di questo tipo, devi solo modificare il parametro revision
in una posizione e poi applicare selettivamente 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 contemporaneamente il parametro revision
per più cluster appartenenti allo stesso parco risorse. Tuttavia, se disponi di un sistema automatico per aggiornare le configurazioni, non ti consigliamo di utilizzare la console Google Cloud per apportare modifiche alla configurazione.
Ad esempio, la seguente definizione di RootSync configura Config Sync in modo da 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: git@example.com:gke/config-sync.git
revision: 1.2.3
auth: ssh
Se applichi questa configurazione al 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
impostandolo sul nuovo valore per il cluster. In questo modo puoi definire quali cluster vengono aggiornati e quando. Se devi eseguire il rollback di una modifica, ripristina il valore precedente del campo spec.git.revision
.
Il seguente diagramma illustra il processo di implementazione di questo metodo. Prima esegui il commit delle modifiche nel repository Config Sync, quindi aggiorni le definizioni di 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 a scopo di controllo e per tenere traccia del commit utilizzato nei log. Inoltre, a differenza dei tag, non è previsto alcun passaggio aggiuntivo per il commit degli ID. - Se preferisci utilizzare i tag Git anziché gli ID commit Git, puoi proteggere i tuoi tag se utilizzi una soluzione Git che supporta la protezione.
- Se vuoi aggiornare più cluster contemporaneamente, puoi farlo nella console Google Cloud. Per aggiornare più cluster contemporaneamente, devono far parte dello stesso parco risorse (e devono trovarsi nello stesso progetto).
Usa 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 tuo repository Git e configuri Config Sync in cluster diversi per leggerne la configurazione da diversi rami.
Ad esempio, un pattern semplice ha due rami:
- Un ramo
staging
per i cluster non di produzione. - Un ramo
main
per i cluster di produzione.
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 di RootSync configura Config Sync in modo da utilizzare il ramo main
:
apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
name: root-sync
namespace: config-sync-system
spec:
git:
repo: git@example.com:gke/config-sync.git
branch: main
auth: ssh
Il seguente diagramma illustra il processo di implementazione di questo metodo:
Puoi adattare questo pattern a esigenze specifiche, utilizzando più di due rami o usando rami mappati a qualcosa di diverso dagli ambienti. Se devi eseguire il rollback di una modifica, utilizza il comando git revert
per creare un nuovo commit nello stesso ramo che ripristina le modifiche dal commit precedente.
Consigliamo di eseguire queste operazioni:
- Quando hai a che fare con più cluster, usa almeno due rami Git per distinguere i cluster di produzione da quelli non di produzione.
- La maggior parte delle soluzioni Git consente di utilizzare la funzionalità dei rami protetti per impedire le eliminazioni o le modifiche non esaminate di questi rami. Per saperne di più, consulta la documentazione per GitHub, GitLab e Bitbucket.
Utilizzo degli 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 gli stessi criteri. Tuttavia, se vuoi implementare una modifica solo per un sottoinsieme di cluster o di spazi dei nomi, utilizza gli oggetti ClusterSelector
e NamespaceSelector
. Questi oggetti hanno un obiettivo simile: consentono di applicare oggetti solo a cluster o spazi dei nomi con 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à. - Con gli oggetti
NamespaceSelector
, puoi applicare criteri diversi agli spazi dei nomi utilizzati da un team interno e da un collaboratore esterno.
Gli oggetti ClusterSelector
e NamespaceSelector
ti consentono inoltre di implementare
metodo di test e rilascio avanzati, come le seguenti:
- Release canary di criteri, in cui esegui il deployment di un nuovo criterio in un piccolo sottoinsieme di cluster e spazi dei nomi per un lungo periodo di tempo per studiare l'impatto del criterio.
- Test A/B, in cui esegui il deployment di versioni diverse dello stesso criterio in cluster diversi per studiare la differenza dell'impatto delle versioni del criterio e quindi scegliere la migliore per il deployment ovunque.
Immagina ad esempio un'organizzazione con diversi cluster di produzione.
Il team della piattaforma ha già creato due categorie di cluster di produzione,
chiamati canary-prod
e prod
, utilizzando
Cluster
e ClusterSelector
oggetti (consulta
Utilizzare ClusterSelector).
Il team della piattaforma vuole implementare un criterio con Policy Controller per applicare la presenza di un'etichetta del team negli spazi dei nomi in modo da identificare a quale team appartiene ogni spazio dei nomi. Ha già implementato una versione di questo criterio in modalità di prova e ora vuole applicarlo a un numero limitato di cluster.
Utilizzando gli oggetti ClusterSelector
, creano due diverse risorse K8sRequiredLabels
applicate a cluster diversi.
La risorsa
K8sRequiredLabels
viene applicata ai cluster di tipoprod
, con un parametroenforcementAction
impostato sudryrun
: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 tipocanary-prod
, senza il parametroenforcementAction
, il che significa che il criterio viene effettivamente applicato: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 in cluster di tipo canary-prod
, impedendo che eventuali effetti collaterali involontari si estendano all'intero parco risorse di produzione. Per ulteriori informazioni sulla funzionalità di prova di Policy Controller, consulta Creazione di vincoli.
Consigliamo di eseguire queste operazioni:
- Utilizza gli oggetti
ClusterSelector
eNamespaceSelector
se devi applicare una modifica della configurazione solo a un sottoinsieme di cluster o spazi dei nomi indeterminato o per molto tempo. - Se implementi una modifica utilizzando i selettori, fai molta attenzione. Se utilizzi i commit Git, qualsiasi errore riguarda un solo cluster alla volta, perché stai implementando cluster per cluster. Tuttavia, se usi rami Git, qualsiasi errore può interessare tutti i cluster che utilizzano quel ramo. Se usi i selettori, l'errore può interessare tutti i cluster contemporaneamente.
Implementazione di revisioni, test e convalide
Un vantaggio 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 consente di implementare flussi di lavoro di sviluppo che già utilizzi per il codice sorgente di un'applicazione: revisioni e test automatici.
Implementa le revisioni
Poiché Config Sync è basato su Git, puoi utilizzare la tua soluzione Git preferita per ospitare il repository Config Sync. La tua soluzione Git probabilmente dispone di una funzionalità di revisione del codice, che puoi utilizzare per rivedere le modifiche apportate al repository Config Sync.
Le best practice per esaminare le modifiche apportate al repository sono le stesse di una normale revisione del codice, come segue:
- Esercitarsi nello sviluppo basato su trunk.
- Lavora in piccoli batch.
- Assicurati che la revisione del codice venga eseguita in modo sincrono o almeno tempestivamente.
- La persona che esamina e approva la modifica non deve essere la stessa persona che ha suggerito la modifica.
A causa della sensibilità del codebase di Config Sync, ti consigliamo inoltre di effettuare le seguenti configurazioni, se possibile con la tua soluzione Git:
- Proteggi i rami utilizzati direttamente dai cluster. Consulta la documentazione per GitHub, GitLab e Bitbucket. GitLab ti consente anche di proteggere i tag.
- Dopo aver protetto i rami, puoi perfezionare le approvazioni necessarie per unire una modifica:
- Su GitHub, abilita le revisioni richieste.
- Per GitLab, utilizza Proprietari di codice per delegare le autorizzazioni di approvazione in base a file o directory. Puoi utilizzare le approvazioni delle richieste di unione per richiedere a persone diverse di team diversi di approvare una richiesta prima dell'unione.
- Su Bitbucket, combina i revisori predefiniti con i controlli di unione predefiniti. Facoltativamente, utilizza un plug-in Proprietari di codice per Bitbucket Server disponibile su Atlassian Marketplace per controllare chi può approvare le modifiche alle 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 il parco risorse di cluster) e da un membro del team di sicurezza (che è incaricato della definizione e dell'implementazione dei criteri di sicurezza).
Ti consigliamo di eseguire queste operazioni:
- Applica le revisioni dei compagni nel 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 automatici da eseguire quando viene creata o aggiornata una richiesta di modifica. I test automatici possono rilevare molti errori prima che una persona esamini la richiesta di modifica. In questo modo il ciclo di feedback per lo sviluppatore si stringe. Puoi implementare la stessa idea utilizzando gli stessi strumenti per il repository Config Sync.
Ad esempio, un buon punto di partenza è eseguire automaticamente il comando nomos vet
in caso di nuove modifiche. Questo comando verifica che la sintassi del repository
Config Sync sia valida. Puoi implementare questo test utilizzando Cloud Build seguendo il tutorial sulle configurazioni di convalida. Puoi integrare Cloud Build con le seguenti opzioni:
- Bitbucket, utilizzando i trigger di build.
- GitHub, utilizzando l'applicazione Google Cloud Build GitHub. I trigger di build sono disponibili anche per GitHub, ma l'applicazione GitHub è il metodo di integrazione preferito.
Come puoi vedere nel tutorial sulla convalida delle configurazioni, il test viene eseguito utilizzando un'immagine container. Di conseguenza, puoi implementare il test in qualsiasi soluzione di integrazione continua che esegue container, non solo in Cloud Build.
Per stringere ulteriormente il ciclo di feedback, puoi chiedere agli utenti di eseguire il comando nomos
vet
come
hook pre-commit 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 eseguire queste operazioni:
- 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 tutti i sistemi di protezione trattati in questo documento, possono comunque verificarsi errori. Di seguito sono riportati due tipi di errori comuni:
- Errori che non costituiscono alcun problema per Config Sync, ma impediscono il corretto funzionamento dei carichi di lavoro, ad esempio un criterio NetworkPolicy eccessivamente restrittivo che impedisce la comunicazione tra i componenti del carico di lavoro.
- Errori che impediscono a Config Sync di applicare modifiche a un cluster, ad esempio un manifest Kubernetes non valido o un oggetto rifiutato da un controller di ammissione. I metodi descritti 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é è necessario comprendere lo stato di ciascuno dei carichi di lavoro. Per questo motivo, il rilevamento di questi errori è preferibile mediante il tuo sistema di monitoraggio esistente, che ti avvisa quando un'applicazione funziona in modo anomalo.
Il rilevamento degli errori descritti nel secondo punto elenco precedente, che dovrebbe essere raro se hai implementato tutti i sistemi di protezione, 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 sono visualizzati anche nella pagina della console Google Cloud di Config Sync.
In genere né i log né la console sono sufficienti per rilevare errori, perché probabilmente non li monitori sempre. Il modo più semplice per automatizzare il rilevamento degli errori è eseguire il comando nomos status
, che indica se si è verificato un errore in un cluster.
Puoi anche configurare una soluzione più avanzata con avvisi automatici per errori. Config Sync espone le metriche nel formato Prometheus. Per ulteriori informazioni, consulta la sezione sul monitoraggio di Config Sync.
Dopo aver ottenuto 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 ulteriori informazioni, consulta la pagina relativa alla gestione dei criteri di avviso per Cloud Monitoring o le regole di avviso per Prometheus.
Riepilogo dei meccanismi per implementazioni sicure con Config Sync
La seguente tabella riassume i vari meccanismi descritti in precedenza in questo documento. Nessuno di questi meccanismi è esclusivo. Puoi scegliere di usarne alcuni o tutti, per scopi diversi.
Meccanismo | Per cosa è utile | Per cosa non è indicato | Esempio di caso d'uso |
---|---|---|---|
ID e tag commit Git | Utilizza ID o tag commit Git specifici per controllare con precisione a quali modifiche vengono applicate le modifiche al cluster. | Non utilizzare tag o ID commit Git per differenze di lunga durata tra i cluster. Utilizza i selettori di cluster. | Tutti i cluster sono configurati per applicare il commit Git 12345 . Apporta una modifica con un nuovo commit, abcdef , che vuoi testare. Cambi 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 riunirsi tra loro. | Prima unisci la modifica nel ramo di gestione temporanea, dove verrà
selezionata dai cluster di gestione temporanea. Poi unisci la modifica nel ramo master, dove verrà acquisita dai cluster di produzione. |
Selettori di cluster e selettori dello spazio dei nomi | Utilizza i selettori per differenze di lunga durata tra cluster e spazi dei nomi. | Non utilizzare i selettori per un'implementazione graduale in più ambienti. Se vuoi testare una modifica prima nella gestione temporanea, quindi eseguirne il deployment in produzione, utilizza rami Git separati. | Se i team che si occupano delle applicazioni hanno bisogno dell'accesso completo ai cluster di sviluppo, ma dell'accesso di 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 dei compagni per assicurarti che i team competenti approvino le modifiche. | I revisori non rilevano tutti gli errori, soprattutto elementi come gli errori di sintassi. | La tua organizzazione impone che il team per la sicurezza esamini le modifiche alla configurazione che interessano più sistemi. Chiedi a un membro del team di sicurezza di esaminare le modifiche. |
Test automatici nella pipeline di integrazione continua | Utilizza i test automatici per rilevare gli errori nelle modifiche suggerite. | I test automatici non possono sostituire del tutto un revisore. Usali entrambi. | L'esecuzione di un comando nomos vet su tutte le modifiche suggerite conferma che il repository sia una configurazione di Config Sync valida. |
Monitoraggio degli errori di sincronizzazione | Assicurati che Config Sync applichi effettivamente le modifiche ai 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 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 presentati nel resto di questo 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 separate per lo sviluppo, la gestione temporanea e la produzione (come mostrato in Esempio del parco risorse 1 - Approccio 1).
In questo scenario, configurerai ogni cluster per la sincronizzazione con il tuo repository Git utilizzando un commit Git specifico. Il deployment di una modifica a un determinato parco risorse è un processo in quattro passaggi:
- Aggiorna un singolo cluster (il "canary") nel parco risorse per utilizzare prima il nuovo commit.
- Per verificare che tutto funzioni come previsto, esegui dei test e monitora l'implementazione.
- Aggiorna gli altri cluster nel parco risorse.
- Verifica di nuovo che tutto funzioni come previsto.
Per eseguire il deployment di una modifica in tutti i cluster, ripeti questo processo per ogni parco risorse. Tecnicamente puoi applicare questo metodo con qualsiasi commit Git, da qualsiasi ramo. Tuttavia, ti consigliamo di adottare la seguente procedura per identificare i problemi nelle prime fasi del processo di revisione:
- Quando qualcuno apre una richiesta di modifica nel repository Git di Config Sync, esegui il deployment della modifica in uno dei cluster di sviluppo.
- Se la richiesta di modifica viene accettata e unita nel ramo principale, esegui il deployment completo su tutti i parchi risorse come descritto in precedenza.
Anche se alcune modifiche possono avere come target solo un parco risorse specifico, ti consigliamo di eseguire il deployment di tutte le modifiche su tutti i parchi risorse alla fine. Questa strategia elimina il problema di tenere traccia del parco risorse da sincronizzare con un determinato commit. Presta particolare attenzione alle modifiche che hanno come target solo il parco risorse di produzione, perché nei parchi risorse precedenti non sarebbe stato possibile eseguire test adeguati. Ad esempio, questo significa attendere più a lungo la comparsa di problemi tra il deployment nei cluster canary e il resto dei cluster.
Per riassumere, un deployment end-to-end completo ha il seguente aspetto:
- Qualcuno apre una richiesta di modifica.
- Vengono eseguiti test e convalide automatici ed è stata effettuata una revisione manuale.
- Puoi attivare manualmente un job per eseguire il deployment della modifica nel cluster canary nel parco risorse di sviluppo. Test automatici end-to-end eseguiti in questo cluster.
- Se non ci sono problemi, unisci la richiesta di modifica al ramo principale.
- L'unione attiva un job automatizzato per il deployment del nuovo commit di punta del ramo principale nel cluster canary nel parco risorse di sviluppo. In questo cluster vengono eseguiti test end-to-end automatici (per rilevare potenziali incompatibilità tra due richieste di modifica create e unite circa contemporaneamente).
- I seguenti job vengono eseguiti uno dopo l'altro (puoi attivarli manualmente o dopo un periodo di tempo predefinito per consentire la segnalazione di regressioni da parte degli utenti):
- Esegui il deployment in tutti i cluster del parco risorse di sviluppo.
- Esegui test e convalide nei cluster del parco risorse di sviluppo.
- Esegui il deployment nel cluster canary del parco risorse gestione temporanea.
- Esegui test e convalide nel cluster canary del parco risorse gestione temporanea.
- Esegui il deployment in tutti i cluster del parco risorse gestione temporanea.
- Esegui test e convalide nei cluster del parco risorse gestione temporanea.
- Esegui il deployment nel cluster canary del parco risorse di produzione.
- Esegui test e convalide nel cluster canary del parco risorse di produzione.
- Esegui il deployment in tutti i cluster del parco risorse di produzione.
- Esegui test e convalide nei cluster del parco risorse di produzione.
Passaggi successivi
- Ulteriori informazioni 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.