Questo documento mostra agli operatori dei cluster e agli amministratori di piattaforma come di implementare le modifiche in più ambienti utilizzando Config Sync. Questo approccio consente di evitare errori che interessano tutti i tuoi ambienti contemporaneamente.
Config Sync consente di gestire cluster singoli e multi-tenant cluster e configurazioni Kubernetes multi-cluster utilizzando i file Git repository Git.
Le configurazioni possono rappresentare diversi elementi, tra cui seguenti:
- Oggetti GKE standard, come NetworkPolicies di cloud computing, DaemonSets risorse o RoleBindings Google Cloud.
- alle risorse Google Cloud, Istanze di Compute Engine o Cloud SQL tramite Config Connector.
- Vincoli sulla configurazione stessa, tramite Policy Controller.
Config Sync è particolarmente adatto per il deployment di configurazioni, i criteri e i carichi di lavoro necessari per eseguire la piattaforma che crei su Versione Google Kubernetes Engine (GKE) Enterprise, ad esempio agenti di sicurezza, agenti di monitoraggio e certificati responsabili.
Sebbene sia possibile eseguire il deployment di applicazioni rivolte agli utenti Config Sync, non è consigliabile collegare la relativa release dal ciclo di vita al ciclo di rilascio dei carichi di lavoro amministrativi menzionati in precedenza. Ti consigliamo invece di utilizzare uno strumento dedicato all'applicazione come un deployment deployment continuo per consentire ai team delle applicazioni di gestire il loro programma di release.
Config Sync è un prodotto efficace che può gestire di sicurezza, perciò sono necessarie delle misure cautelative per evitare errori con un impatto significativo. Questo descrive diversi metodi per creare dei sistemi di protezione. La prima sezione le implementazioni graduali, mentre la seconda sezione si concentra su test e convalide. La terza sezione mostra come monitorare i deployment.
Implementazione delle implementazioni graduali con Config Sync
In un ambiente multi-cluster, che è una situazione comune Per gli utenti di GKE Enterprise, sconsigliamo di applicare una modifica alla configurazione in tutti i cluster contemporaneamente. Un'implementazione graduale, cluster è molto più sicuro perché riduce il potenziale impatto .
Esistono diversi modi per implementare le implementazioni graduali con Config Sync:
- Utilizza i commit o i tag Git per applicare manualmente le modifiche che vuoi tra i cluster.
- Utilizza i rami Git per applicare automaticamente le modifiche al momento dell'applicazione uniti. Puoi utilizzare rami diversi per gruppi di cluster diversi.
- Usa gli oggetti
ClusterSelector
eNamespaceSelector
per selezionare e applicare modifiche a sottogruppi di cluster o spazi dei nomi.
Tutti i metodi per le implementazioni graduali presentano vantaggi e svantaggi. La la seguente tabella 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.
Utilizzare commit o tag Git
Rispetto agli altri metodi di implementazione graduale, con commit o tag Git offre il massimo controllo ed è il più sicuro. Puoi utilizzare lo Pagina Config Sync nella console Google Cloud nella console per aggiornare più cluster contemporaneamente. Utilizza questo metodo se applicare le modifiche singolarmente ai cluster e controllare esattamente quando ciò accade.
Con questo metodo, devi "fissare" per ciascun cluster a una versione specifica (ovvero una
o un tag) del tuo repository. Questo metodo è
simile a
utilizzando il commit Git come tag immagine container.
Implementi questo metodo specificando il commit, il tag o l'hash nella
Campo spec.git.revision
di RootSync
o RepoSync
risorsa personalizzata.
Se gestisci le tue risorse personalizzate RootSync
o RepoSync
con uno strumento come
Kustomize
puoi ridurre la quantità di lavoro manuale necessario per le implementazioni. Con tali
uno strumento, devi solo modificare il parametro revision
in un posto e poi
di applicare selettivamente la nuova risorsa personalizzata RootSync
o RepoSync
ai cluster in
l'ordine e il ritmo che scegli.
Inoltre, puoi utilizzare la console Google Cloud per aggiornare il parametro revision
per più cluster appartenenti allo stesso parco risorse
contemporaneamente. Tuttavia, se hai un sistema automatico per aggiornare
di configurazione, sconsigliamo di utilizzare la console Google Cloud per apportare modifiche alla configurazione.
Ad esempio, la seguente definizione di 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: 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
di
Repository example.com:gke/config-sync.git
.
Per aggiornare un cluster, imposta il nuovo valore per il campo spec.git.revision
per
nel cluster. Questo ti consente di definire quali cluster aggiornare e quando. Se
devi eseguire il rollback di una modifica, reimposta il campo spec.git.revision
valore precedente.
Il seguente diagramma illustra la procedura di implementazione di questo metodo. Per prima cosa, esegui il commit delle modifiche nel repository di Config Sync, aggiorni le definizioni di RootSync su tutti i cluster:
Consigliamo di eseguire queste operazioni:
- Utilizza ID commit Git anziché tag. A causa del modo in cui Git
le funzioni, c'è
garantire
che non cambieranno mai. Ad esempio,
git push --force
non può cambiare il commit utilizzato da Config Sync. Questo approccio è utile per motivi di controllo e per tenere traccia del commit in uso nei log. Inoltre, a differenza dei tag, non c'è nessun passaggio aggiuntivo per eseguire il commit degli ID. - Se preferisci utilizzare tag Git anziché ID commit Git, puoi Proteggi i tuoi tag se utilizzi una soluzione Git che supporta la protezione.
- Se vuoi aggiornare più cluster contemporaneamente, puoi che nel Console Google Cloud. Per aggiornare più cluster contemporaneamente, questi devono far parte uguale parco (ed essere nella stessa progetto).
Utilizza rami Git
Se vuoi che le modifiche vengano applicate ai cluster non appena vengono unite nel tuo repository Git, configura Config Sync per utilizzare Git rami anziché commit o tag. Con questo metodo, crei più i rami a lunga durata nel tuo repository Git Config Sync in diversi cluster per leggerne la configurazione da rami diversi.
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
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 per 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 la procedura di implementazione di questo metodo:
Puoi adattare questo modello a esigenze specifiche, usando più di due rami,
utilizzando rami mappati a qualcosa di diverso dagli ambienti. Se hai bisogno
per eseguire il rollback di una modifica,
Comando git revert
di creare un nuovo commit sullo stesso ramo che ripristina le modifiche
sul commit precedente.
Consigliamo di eseguire queste operazioni:
- Quando hai a che fare con più cluster, utilizza almeno due rami Git per aiutare a 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 eliminazioni o modifiche non esaminate di questi rami. Per ulteriori informazioni, consulta la documentazione per GitHub GitLab e Bitbucket.
Utilizzare gli oggetti ClusterSelector e NamespaceSelector
I rami Git sono un buon modo per eseguire un'implementazione graduale delle modifiche
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,
quindi utilizza gli oggetti ClusterSelector
e NamespaceSelector
. Questi oggetti
hanno un obiettivo 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 di conformità. - Utilizzando gli oggetti
NamespaceSelector
, puoi applicare criteri diversi agli spazi dei nomi usati da un team interno e da un contraente esterno.
Gli oggetti ClusterSelector
e NamespaceSelector
consentono inoltre di implementare
metodologie di test e rilascio avanzate, come le seguenti:
- Release canary, in cui esegui il deployment di un nuovo criterio su un di cluster e spazi dei nomi per un lungo periodo di tempo per esaminare l'impatto del criterio.
- Test A/B, in cui esegui il deployment di versioni diverse dello stesso criterio in diversi cluster per studiare la differenza tra le versioni dei criteri impatto e poi scegliere quello migliore di cui eseguire 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 (vedi
Utilizza ClusterSelector).
Il team della piattaforma vuole implementare un criterio con Policy Controller per applicare
la presenza di un'etichetta team negli spazi dei nomi per identificare ogni team
a cui appartiene lo spazio dei nomi. Hanno già implementato una versione di questo criterio in
dry run e ora vuole applicarla su un numero limitato di cluster.
Utilizzando ClusterSelector
oggetti, vengono creati due K8sRequiredLabels
diversi
e risorse 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 a cluster di tipocanary-prod
, senza il parametroenforcementAction
, il che significa che 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
il criterio solo in cluster di tipo canary-prod
, impedendo qualsiasi
e non intenzionali della sua diffusione
sull'intero parco dispositivi di produzione. Per ulteriori informazioni
informazioni sulla funzionalità dry run di Policy Controller, consulta
la creazione di vincoli.
Consigliamo di eseguire queste operazioni:
- Usa gli oggetti
ClusterSelector
eNamespaceSelector
se necessario Applica una modifica alla configurazione solo a un sottoinsieme di cluster o spazi dei nomi a tempo indeterminato o per molto tempo. - Se implementi una modifica utilizzando i selettori, fai molta attenzione. Se utilizzi o commit Git, qualsiasi errore interessa un solo cluster alla volta, mediante l'implementazione di cluster per cluster. Ma se usi i rami Git, qualsiasi errore può influisce su tutti i cluster che utilizzano quel ramo. Se utilizzi i selettori, si verifica un errore possono interessare tutti i cluster contemporaneamente.
Implementazione di revisioni, test e convalide
Uno dei vantaggi di Config Sync è che gestisce tutto dichiarativamente: risorse Kubernetes, risorse cloud e criteri. Ciò significa i file in un sistema di gestione del controllo del codice sorgente rappresentano le risorse (Git (nel caso di Config Sync). Questa caratteristica consente di implementare i flussi di lavoro di sviluppo che già utilizzi codice sorgente dell'applicazione: revisioni e test automatici.
Implementa le recensioni
Poiché Config Sync si basa su Git, puoi utilizzare la soluzione Git preferita per l'hosting del repository Config Sync. La tua soluzione Git probabilmente include una funzionalità di revisione del codice, che puoi utilizzare per per esaminare le modifiche apportate al repository di Config Sync.
Le best practice per esaminare le modifiche al nel repository corrispondono a un codice normale revisione, come segue:
- Fai pratica sviluppo basato su trunk.
- Lavora in piccoli batch.
- Assicurati che la revisione del codice viene eseguita in modo sincrono o almeno prontamente.
- La persona che esamina e approva la modifica non deve essere la stessa la persona che ha suggerito la modifica.
Data la sensibilità del codebase Config Sync, inoltre, se possibile, con la tua soluzione Git consigliamo di eseguire quanto segue: configurazioni:
- Proteggi i rami utilizzati direttamente dai cluster. Consulta le documentazione di GitHub GitLab e Bitbucket. GitLab ti consente inoltre proteggere i tag.
- Quando le filiali sono state protette, puoi perfezionare le approvazioni
necessarie per unire una modifica:
- Su GitHub, attiva le revisioni obbligatorie.
- Per GitLab, utilizza Proprietari di codice delegare le autorizzazioni di approvazione a livello di file o di directory. Puoi utilizzare unire le approvazioni delle richieste per richiedere a persone diverse di team diversi di approvare una richiesta prima dell'unione.
- In Bitbucket, combina recensori predefiniti con controlli di unione predefiniti. Facoltativamente, è disponibile un plug-in Code Owners per Bitbucket Server il Marketplace Atlassian per controllare chi può approvare le modifiche alle sottosezioni del repository.
Utilizzando queste diverse funzionalità, puoi applicare le approvazioni per ogni modifica richiesta al codebase. Ad esempio, puoi Assicurarsi che ogni modifica venga approvata almeno da un membro del team della piattaforma (chi gestisce il parco risorse di cluster) e da un membro del team di sicurezza (che è responsabile della definizione e dell'implementazione delle policy di sicurezza).
Consigliamo di procedere nel seguente modo:
- Applica le revisioni dei compagni sul tuo il repository e proteggere i rami Git utilizzati dai cluster.
Implementa test automatici
Una best practice comune quando si lavora su un codebase è l'implementazione integrazione continua. Ciò significa che configuri i test automatici da eseguire quando viene richiesta una modifica creato o aggiornato. I test automatici possono rilevare molti errori prima che una revisione umana la richiesta di modifica. Questo restringe il ciclo di feedback per lo sviluppatore. Puoi di implementare la stessa idea, utilizzando gli stessi strumenti, per Config Sync.
Ad esempio, un buon punto di partenza è eseguire
Comando nomos vet
automaticamente alle nuove modifiche. Questo comando convalida che
La sintassi del repository di Config Sync è valida. Puoi implementare
questo test utilizzando
Cloud Build
seguendo le
convalida delle configurazioni
durante il tutorial. Puoi integrare Cloud Build con le opzioni seguenti:
- Bitbucket utilizzando trigger di build.
- GitHub, utilizzando Applicazione 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 nella convalida delle configurazioni il test viene eseguito utilizzando un'immagine container. Puoi quindi implementare il test in qualsiasi soluzione di integrazione continua che esegue container, e non solo in Cloud Build.
Per rafforzare ulteriormente il ciclo di feedback, puoi chiedere agli utenti di eseguire il comando nomos
vet
Hook pre-commit di Git.
Un'avvertenza è che alcuni utenti potrebbero non avere accesso ai cluster Kubernetes
gestiti da Config Sync e potrebbero non essere eseguiti
per la convalida completa dalla workstation. Esegui nomos vet --clusters ""
per limitare la convalida ai controlli semantici e sintattici.
Consigliamo di procedere nel seguente modo:
- Implementare 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 coperti da questo documento, gli errori possono continuano a verificarsi. Di seguito sono riportati due tipi di errori comuni:
- Errori che non rappresentano un problema per Config Sync, ma impediscono agli utenti dei carichi di lavoro non funzionino correttamente, ad esempio una NetworkPolicy che impedisce la comunicazione tra componenti del carico di lavoro.
- Errori che impediscono a Config Sync di applicare le modifiche a un ad esempio un manifest Kubernetes non valido oppure un oggetto rifiutato 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 precedente è quasi impossibile a livello di Config Sync perché richiede la comprensione dello stato di ciascuno dei tuoi carichi di lavoro. Per questo motivo, Il rilevamento di questi errori viene eseguito meglio dal tuo sistema di monitoraggio esistente, ti avvisa quando un'applicazione funziona in modo anomalo.
Rilevamento degli errori descritti nel secondo punto precedente, che dovrebbero essere
raro se hai implementato tutti i sistemi di protezione: è necessaria una configurazione specifica. Di
per impostazione predefinita, Config Sync scrive gli errori nei propri log (che
per impostazione predefinita,
Cloud Logging).
Gli errori vengono visualizzati anche nella
Pagina della console Google Cloud di Config Sync.
Né i log né la console di solito sono sufficienti per rilevare gli errori,
probabilmente non li monitorano sempre. Il modo più semplice per automatizzare gli errori
il rilevamento è l'esecuzione di nomos status
comando,
che indica se c'è un errore in un cluster.
Puoi anche configurare una soluzione più avanzata con avvisi automatici per gli errori. Config Sync espone le metriche Formato Prometheus. Per ulteriori informazioni, vedi il monitoraggio di Config Sync.
Dopo che le metriche di Config Sync sono disponibili
crea un avviso per ricevere una notifica quando la metrica gkeconfig_monitor_errors
è maggiore di 0. Per ulteriori informazioni, vedi
gestione dei criteri di avviso
per Cloud Monitoring
regole di avviso
per Prometheus.
Riepilogo dei meccanismi per implementazioni sicure con Config Sync
La seguente tabella riassume i vari meccanismi descritti in precedenza documento. Nessuno di questi meccanismi è esclusivo. Puoi scegliere di utilizzare alcuni solo per fare riferimento a tutti e per scopi diversi.
Meccanismo | Per cosa è utile | Cosa non è utile | Caso d'uso di esempio |
---|---|---|---|
ID e tag del commit Git | Usa ID o tag di commit Git specifici per controllare con precisione quale cluster a cui vengono applicate le modifiche. | Non utilizzare ID o tag di commit Git per differenze di lunga durata tra cluster. Utilizza i selettori di cluster. | Tutti i tuoi cluster sono configurati per applicare il Git 12345
eseguire il commit. Apporta una modifica con un nuovo commit, abcdef , che
che vuoi testare. Modifica la configurazione di un singolo cluster per utilizzare questo
un 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 le differenze di lunga durata tra cluster. Le filiali varieranno significativamente e sarà difficile da unire di nuovo insieme. | Innanzitutto unisci la modifica nel ramo di gestione temporanea, dove verrà
rilevato dai cluster di gestione temporanea. Quindi unisci la modifica nel ramo master, dove verrà essere selezionato dai cluster di produzione. |
Selettori di cluster e selettori dello spazio dei nomi | Utilizza i selettori per le differenze di lunga durata tra cluster e spazi dei nomi. | Non utilizzare selettori per un'implementazione graduale in più ambienti. Se devi prima testare una modifica nella gestione temporanea e poi eseguirne il deployment usare rami Git separati. | Se i team delle applicazioni hanno bisogno dell'accesso completo ai cluster
accesso di sola lettura ai cluster di produzione, utilizza
ClusterSelector oggetto per applicare i criteri RBAC corretti
solo ai cluster pertinenti. |
Revisioni dei compagni | Ricorri alle revisioni dei compagni per assicurarti che i team competenti approvino modifiche. | I revisori non rilevano tutti gli errori, in particolare elementi come la sintassi errori. | La tua organizzazione impone al team di sicurezza di rivedere la configurazione modifiche che interessano più sistemi. Chiedi a un membro del team di sicurezza di esaminarlo le modifiche. |
Test automatici nella pipeline di integrazione continua | Utilizza i test automatici per individuare gli errori nelle modifiche suggerite. | I test automatici non possono sostituire completamente un revisore. Utilizza entrambi. | Conferma dell'esecuzione di un comando nomos vet su tutte le modifiche suggerite
che il repository sia un Config Sync valido
configurazione. |
Monitorare gli errori di sincronizzazione | Assicurati che Config Sync applichi effettivamente le modifiche a nei 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 dei e del set di dati. | Un utente ignora tutti i test e le revisioni e applica una modifica non valida a nel repository di Config Sync. Questa modifica non può essere applicati ai tuoi cluster. Se monitori gli errori di sincronizzazione, avvisato se si verifica un errore. |
Esempio di strategia di implementazione
Questa sezione utilizza i concetti introdotti nel resto dell'articolo per aiutarti una strategia di implementazione end-to-end su tutti i cluster dell'organizzazione. Questa strategia presuppone che tu abbia parchi risorse separati per sviluppo, gestione temporanea e produzione (come mostrato Esempio 1 del parco risorse - Approccio 1).
In questo scenario, configurerai ogni cluster in modo che si sincronizzi con repository Git utilizzando un commit Git specifico. Il deployment di una modifica a un parco risorse specifico è un processo in quattro passaggi:
- Aggiorni un singolo cluster (il cluster "canary") nel parco risorse per utilizzare prima il nuovo commit.
- Verificherai che tutto funzioni come previsto eseguendo dei test e il monitoraggio dell'implementazione.
- Aggiorna il resto dei cluster nel parco risorse.
- Verifichi 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. Puoi applicare tecnicamente 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 Git di Config Sync repository, eseguire 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 potrebbero avere come target solo un parco risorse specifico, ti consigliamo di prima o poi eseguendo il deployment di tutte le modifiche a tutti i parchi risorse. Questa strategia elimina il problema del monitoraggio del parco risorse che deve essere sincronizzato con un determinato commit. Presta particolare attenzione alle modifiche che hanno come target solo la produzione parco risorse perché non erano possibili test corretti nei parchi risorse precedenti. Per Ciò significa attendere più a lungo che compaiano i problemi tra il deployment ai cluster canary e agli altri cluster.
Ricapitolando, un deployment end-to-end completo è simile al seguente:
- Qualcuno apre una richiesta di modifica.
- Vengono eseguiti test e convalide automatici e viene eseguita una revisione manuale.
- Puoi attivare manualmente un job per eseguire il deployment della modifica nel cluster canary nella di sviluppo software. In questo cluster vengono eseguiti test end-to-end automatici.
- Se è tutto a posto, unisci la richiesta di modifica nel ramo principale.
- L'unione attiva un job automatico per il deployment del nuovo commit della mancia del ramo principale nel cluster canary nel parco risorse di sviluppo. Test end-to-end automatici vengono eseguiti in questo cluster (per rilevare potenziali incompatibilità tra richieste che sono state create e unite contemporaneamente).
- I job seguenti vengono eseguiti uno dopo l'altro (vengono attivati manualmente oppure
dopo un periodo di tempo predefinito per consentire la generazione di report di regressione da parte degli utenti):
- Esegui il deployment su 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 su tutti i cluster del parco risorse di 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 su tutti i cluster del parco risorse di produzione.
- Esegui test e convalide nei cluster del parco risorse di produzione.
Passaggi successivi
- Informazioni il monitoraggio di Config Sync.
- Informazioni parchi risorse.
- Scopri come convalida la tua app in base ai criteri aziendali in una pipeline di integrazione continua.