Formazione
Percorso di apprendimento
Architetto di soluzioni: progettazione di soluzioni Microsoft Power Platform - Training
Informazioni su come un Architetto di soluzioni progetta le soluzioni.
Gestione del carico di lavoro in un ambiente multi-cluster con GitOps
Lo sviluppo di applicazioni moderne native del cloud spesso prevede la creazione, la distribuzione, la configurazione e la promozione di carichi di lavoro in un gruppo di cluster Kubernetes. Data la crescente diversità dei tipi di cluster Kubernetes e l'ampia gamma di applicazioni e servizi, il processo può diventare complesso e non impiegabile. Le organizzazioni aziendali possono avere maggiore successo in queste attività grazie a una struttura ben definita che organizza le persone e le relative attività e attraverso strumenti automatizzati.
Questo articolo illustra uno scenario aziendale tipico, delineando le persone coinvolte e le principali sfide spesso affrontate dalle organizzazioni durante la gestione dei carichi di lavoro nativi del cloud in un ambiente multi-cluster. L'articolo suggerisce anche un modello di architettura che può rendere questo processo complesso più semplice, osservabile e più scalabile.
Questo articolo descrive un'organizzazione che sviluppa applicazioni native del cloud. Tutte le applicazioni devono usare una risorsa di calcolo. Nel mondo nativo del cloud questa risorsa di calcolo è un cluster Kubernetes. Un'organizzazione può avere un singolo cluster o, come è più solito, più cluster. L'organizzazione deve quindi decidere quali applicazioni devono utilizzare quali cluster. In altre parole è necessario pianificare le applicazioni tra cluster. Il risultato di questa decisione, o pianificazione, è un modello dello stato desiderato dei cluster nel proprio ambiente. In questo caso è necessario in qualche modo fornire le applicazioni ai cluster assegnati in modo che possano trasformare lo stato desiderato nella realtà o, in altre parole, riconciliarlo.
Ogni applicazione passa attraverso un ciclo di vita di sviluppo software che la promuove all'ambiente di produzione. Ad esempio un'applicazione viene compilata, distribuita nell'ambiente di sviluppo, testata e promossa all'ambiente di gestione temporanea, testata e infine distribuita nell'ambiente di produzione. Nel caso di un'applicazione nativa del cloud, questa richiede e ha come destinazione diverse risorse del cluster Kubernetes per tutto il ciclo di vita. Inoltre per le applicazioni in genere è necessario che i cluster forniscano alcuni servizi della piattaforma, ad esempio Prometheus e Fluentbit, e le configurazioni dell'infrastruttura, ad esempio i criteri di rete.
A seconda dell'applicazione, potrebbe esserci una grande varietà di tipi di cluster in cui viene distribuita l'applicazione. La stessa applicazione con configurazioni diverse può essere ospitata in un cluster gestito nel cloud, in un cluster connesso in un ambiente locale, in un gruppo di cluster su dispositivi perimetrali semi-connessi su linee di fabbrica o droni militari e su un cluster isolato su una astronave. Un'altra complessità è che i cluster nelle fasi iniziali del ciclo di vita, ad esempio durante lo sviluppo e il controllo di qualità, vengono normalmente gestiti dallo sviluppatore, mentre la riconciliazione con i cluster di produzione effettivi può essere gestita dai clienti dell'organizzazione. In quest'ultimo caso lo sviluppatore può essere responsabile solo per promuovere e pianificare l'applicazione in diversi anelli.
In una piccola organizzazione con una singola applicazione e solo poche operazioni, la maggior parte di questi processi può essere gestita manualmente con una serie di script e pipeline. Tuttavia per le organizzazioni aziendali che operano su larga scala ciò può rappresentare una vera sfida. Queste organizzazioni producono spesso centinaia di applicazioni destinate a centinaia di tipi di cluster, di cui è stato eseguito il backup da migliaia di cluster fisici. In questi casi la gestione manuale di tali operazioni con gli script non è fattibile.
Per eseguire questo tipo di gestione del carico di lavoro su larga scala in un ambiente multi-cluster sono necessarie le funzionalità seguenti:
- Separazione dei compiti relativi alla pianificazione e alla riconciliazione
- Promozione dello stato multi-cluster tramite una catena di ambienti
- Utilità di pianificazione sofisticata, estendibile e sostituibile
- Flessibilità per l'uso di riconciliatori diversi per tipi di cluster che differiscono in base alla loro natura e connettività
- Gestione della configurazione della piattaforma su larga scala
Prima di descrivere lo scenario, è necessario fare chiarezza sulle persone coinvolte, sulle loro responsabilità e su come interagiscono tra di loro.
Il team della piattaforma è responsabile della gestione dei cluster che ospitano le applicazioni prodotte dai team delle applicazioni.
Le responsabilità principali del team della piattaforma sono:
- Definire gli ambienti di gestione temporanea (Dev, controllo qualità, test di accettazione utente, Prod, ovvero con le fasi di Dev, QA, UAT, Prod).
- Definire i tipi di cluster e la relativa distribuzione in ambienti diversi.
- Effettuare il provisioning di nuovi cluster.
- Gestire le configurazioni dell'infrastruttura nei cluster.
- Gestire i servizi della piattaforma usati dalle applicazioni.
- Pianificare le applicazioni e i servizi della piattaforma nei cluster.
Il team dell'applicazione è responsabile del ciclo di vita dello sviluppo software (SDLC) delle applicazioni. Il team fornisce manifesti Kubernetes che descrivono come distribuire l'applicazione in destinazioni diverse. Il team è responsabile della proprietà delle pipeline CI/CD che creano immagini contenitore e manifesti Kubernetes e promuovono gli artefatti di distribuzione tra le fasi dell'ambiente.
In genere il team dell'applicazione non ha alcuna conoscenza dei cluster in cui vengono distribuite. Non è consapevole della struttura dell'ambiente multi-cluster, delle configurazioni globali o delle attività eseguite da altri team. Per prima cosa il team dell'applicazione verifica il successo dell'implementazione dell'applicazione, come definito dall'esito positivo delle fasi della pipeline.
Le responsabilità principali del team dell'applicazione sono:
- Sviluppare, compilare, distribuire, testare, promuovere, rilasciare e supportare le applicazioni.
- Gestire e contribuire ai repository di origine e dei manifesti delle applicazioni.
- Definire e configurare le destinazioni di distribuzione dell'applicazione.
- Comunicare con il team della piattaforma richiedendo le risorse di calcolo desiderate per le operazioni SDLC riuscite.
Questo diagramma mostra come i membri della piattaforma e del team dell'applicazione interagiscono tra di loro durante l'esecuzione di attività regolari.
Il concetto principale di questo intero processo è la separazione dei compiti. Ci sono carichi di lavoro, ad esempio applicazioni e servizi della piattaforma, e c'è una piattaforma in cui vengono eseguiti questi carichi di lavoro. Il team dell'applicazione si occupa dei carichi di lavoro (che cosa), mentre il team della piattaforma si dedica alla piattaforma (dove).
Il team dell'applicazione esegue operazioni SDLC sulle applicazioni e promuove le modifiche in ambienti diversi. Il team non conosce i cluster in cui viene distribuita l'applicazione di ogni ambiente. Il team dell'applicazione opera invece con il concetto di destinazione di distribuzione, che è semplicemente un'astrazione denominata all'interno di un ambiente. Ad esempio le destinazioni di distribuzione potrebbero essere l'integrazione in Dev, i test funzionali e i test delle prestazioni sul controllo di qualità, gli early adopter, gli utenti esterni su Prod e così via.
Il team dell'applicazione definisce le destinazioni di distribuzione per ogni ambiente di implementazione e sa come configurare l'applicazione e come generare manifesti per ogni destinazione di distribuzione. Questo processo è automatizzato ed esiste nello spazio dei repository dell'applicazione. Vengono pertanto generati manifesti per ogni destinazione di distribuzione, quindi vengono archiviati in un archivio manifesti, ad esempio un repository Git, un repository Helm o un archivio OCI.
Il team della piattaforma ha una conoscenza limitata delle applicazioni, quindi non è coinvolto nel processo di configurazione e distribuzione dell'applicazione. Il team della piattaforma è responsabile dei cluster della piattaforma, raggruppati in tipi di cluster. Il team descrive i tipi di cluster con valori di configurazione, ad esempio nomi DNS, endpoint di servizi esterni e così via. Il team della piattaforma assegna o pianifica le destinazioni di distribuzione delle applicazioni a vari tipi di cluster. In questo modo il comportamento dell'applicazione in un cluster fisico è determinato dalla combinazione dei valori di configurazione della destinazione di distribuzione e dei valori di configurazione del tipo di cluster.
Il team della piattaforma usa un repository di piattaforma separato che contiene manifesti per ogni tipo di cluster. Questi manifesti definiscono i carichi di lavoro che devono essere eseguiti in ogni tipo di cluster e i valori di configurazione della piattaforma che devono essere applicati. I cluster possono recuperare tali informazioni dal repository della piattaforma con il riconciliatore preferito e quindi applicare i manifesti.
I cluster segnalano lo stato di conformità con la piattaforma e i repository dell'applicazione all'hub di osservabilità della distribuzione. I team della piattaforma e delle applicazioni possono eseguire query su queste informazioni per analizzare la distribuzione cronologica del carico di lavoro tra cluster. Queste informazioni possono essere usate nei dashboard, negli avvisi e nelle pipeline di distribuzione per applicare l'implementazione progressiva.
Ora si esaminerà ora l'architettura di soluzione di alto livello e si comprenderanno i componenti principali.
Il team della piattaforma modella l'ambiente multi-cluster nel piano di controllo. È progettato per essere di semplice utilizzo e facile da comprendere, aggiornare e rivedere. Il piano di controllo funziona con astrazioni, ad esempio tipi di cluster, ambienti, carichi di lavoro, criteri di pianificazione, configurazioni e modelli. Queste astrazioni vengono gestite da un processo automatizzato che assegna le destinazioni di distribuzione e i valori di configurazione ai tipi di cluster, quindi salva il risultato nel repository GitOps della piattaforma. Sebbene ci siano migliaia di cluster fisici, il repository della piattaforma opera a un livello superiore raggruppando i cluster in tipi di cluster.
Il requisito principale per l'archiviazione del piano di controllo è fornire una funzionalità di elaborazione delle transazioni affidabile e sicura, piuttosto che l'esecuzione di query complesse su una grande quantità di dati. È possibile usare varie tecnologie per archiviare i dati del piano di controllo.
Questa progettazione dell'architettura suggerisce un repository Git con un set di pipeline per archiviare e promuovere astrazioni della piattaforma in ambienti diversi. Questa progettazione offre alcuni vantaggi:
- Tutti i vantaggi dei principi di GitOps, ad esempio il controllo della versione, le approvazioni delle modifiche, l'automazione, la riconciliazione basata sul pull.
- I repository Git, ad esempio GitHub, offrono funzionalità predefinite per la creazione di rami, la sicurezza e la revisione della richiesta pull.
- Implementazione semplice dei flussi promozionali con i flussi di lavoro di GitHub Actions o agenti di orchestrazione simili.
- Non è necessario gestire ed esporre un servizio del piano di controllo separato.
Il repository del piano di controllo contiene due tipi di dati:
- Dati promossi in ambienti diversi, ad esempio un elenco di carichi di lavoro di cui è stato eseguito l'onboarding e vari modelli.
- Configurazioni specifiche dell'ambiente, ad esempio tipi di cluster di ambiente inclusi, valori di configurazione e criteri di pianificazione. Questi dati non vengono promossi perché sono specifici di ogni ambiente.
I dati da promuovere vengono archiviati nel ramo main. I dati specifici dell'ambiente vengono archiviati nei rami di ambiente corrispondenti, ad esempio dev, qa e prod. La trasformazione dei dati dal piano di controllo al repository GitOps è una combinazione dei flussi di promozione e di pianificazione. Il flusso di promozione sposta la modifica negli ambienti orizzontalmente; il flusso di pianificazione esegue la pianificazione e genera i manifesti verticalmente per ogni ambiente.
Un commit nel ramo main avvia il flusso di promozione che attiva il flusso di pianificazione per tutti gli ambienti, uno alla volta. Il flusso di pianificazione accetta i manifesti di base da main, applica i valori di configurazione di un flusso corrispondente a questo ramo di ambiente e crea una richiesta pull con i manifesti risultanti nel repository GitOps della piattaforma. Quando l'implementazione viene completata ed ha esito positivo in questo ambiente, il flusso di promozione procede ed esegue la stessa procedura nell'ambiente successivo. In ogni ambiente il flusso promuove lo stesso ID commit del ramo main in modo che il contenuto passi da main all'ambiente successivo solo dopo la sua corretta distribuzione nell'ambiente precedente.
Un commit nel ramo di ambiente nel repository del piano di controllo avvia il flusso di pianificazione per questo ambiente. Ad esempio è stato configurato l'endpoint cosmo-db nell'ambiente di controllo della qualità (QA). Si vuole aggiornare solo il ramo QA del repository GitOps della piattaforma senza modificare altro. La pianificazione accetta il contenuto main, corrispondente all'ID commit più recente promosso a questo ambiente, applica le configurazioni e promuove i manifesti risultanti al ramo GitOps della piattaforma.
Nel repository GitOps della piattaforma ogni assegnazione del carico di lavoro a un tipo di cluster è rappresentata da una cartella che contiene gli elementi seguenti:
- Spazio dei nomi dedicato a questo carico di lavoro in questo ambiente in un cluster di questo tipo.
- Criteri della piattaforma che limitano le autorizzazioni del carico di lavoro.
- La configurazione della piattaforma consolidata esegue il mapping con i valori che il carico di lavoro può usare.
- Risorse del riconciliatore che puntano a un archivio manifesti del carico di lavoro in cui sono archiviati i manifesti effettivi del carico di lavoro o i grafici Helm. Ad esempio Flux GitRepository e Flux Kustomization, ArgoCD Application, descrittori Zarf e così via.
Ogni tipo di cluster può usare un riconciliatore diverso (ad esempio Flux, ArgoCD, Zarf, Rancher Fleet e così via) per fornire manifesti dagli archivi dei manifesti del carico di lavoro. La definizione del tipo di cluster fa riferimento a un riconciliatore che definisce una raccolta di modelli di manifesto. L'utilità di pianificazione si serve di questi modelli per produrre risorse riconciliatori, ad esempio Flux GitRepository e Flux Kustomization, ArgoCD Application, descrittori Zarf e così via. Lo stesso carico di lavoro può essere pianificato per i tipi di cluster gestiti da riconciliatori diversi, ad esempio Flux e ArgoCD. L'utilità di pianificazione genera Flux GitRepository e Flux Kustomization per un cluster e un'applicazione ArgoCD per un altro cluster, ma entrambi puntano allo stesso archivio dei manifesti del carico di lavoro contenente i manifesti del carico di lavoro.
I servizi della piattaforma sono carichi di lavoro (ad esempio Prometheus, NGINX, Fluentbit e così via) gestiti dal team della piattaforma. Proprio come tutti i carichi di lavoro, i servizi della piattaforma hanno i repository di origine e l'archiviazione dei manifesti. I repository di origine possono contenere puntatori a grafici Helm esterni. Le pipeline CI/CD eseguono il pull dei grafici con contenitori ed eseguono le analisi di sicurezza necessarie prima di inviarle all'archiviazione dei manifesti, da dove vengono riconciliate con i cluster.
Hub di osservabilità della distribuzione è una risorsa di archiviazione centrale facile da eseguire con query complesse su una grande quantità di dati. Contiene i dati di distribuzione con informazioni cronologiche sulle versioni del carico di lavoro e il relativo stato di distribuzione tra cluster. I cluster si autoregistrano nell'archiviazione e aggiornano il proprio stato di conformità con i repository GitOps. I cluster operano solo a livello di commit Git. Le informazioni di alto livello, ad esempio le versioni dell'applicazione, gli ambienti e i dati del tipo di cluster, vengono trasferite all'archiviazione centrale dai repository GitOps. Queste informazioni di alto livello vengono correlate nell'archiviazione centrale con i dati di conformità del commit inviati dai cluster.
Il comportamento dell'applicazione in una destinazione di distribuzione è determinato dai valori di configurazione. Tuttavia i valori di configurazione non sono tutti uguali. Questi valori vengono forniti da utenti diversi in punti diversi del ciclo di vita dell'applicazione e hanno ambiti diversi. In genere sono disponibili configurazioni dell'applicazione e della piattaforma.
Le configurazioni dell'applicazione fornite dagli sviluppatori di applicazioni vengono astratte dai dettagli della destinazione di distribuzione. In genere gli sviluppatori di applicazioni non sono a conoscenza dei dettagli specifici dell'host, ad esempio gli host in cui verrà distribuita l'applicazione o il numero di host presenti. Tuttavia gli sviluppatori di applicazioni conoscono una catena di ambienti e anelli attraverso cui l'applicazione viene promossa fino alla produzione.
Un'applicazione può essere distribuita più volte in ogni ambiente per svolgere ruoli diversi. Ad esempio la stessa applicazione può fungere da dispatcher e da exporter. Gli sviluppatori di applicazioni possono configurare l'applicazione in modo diverso per vari casi d'uso. Se, ad esempio, l'applicazione è in esecuzione come dispatcher in un ambiente di controllo di qualità, essa deve essere configurata in questo modo indipendentemente dall'host effettivo. I valori di configurazione di questo tipo vengono forniti in fase di sviluppo, quando gli sviluppatori di applicazioni creano descrittori/manifesti di distribuzione per vari ambienti/anelli e ruoli di applicazione.
Oltre alle configurazioni in fase di sviluppo, per un'applicazione spesso sono necessari valori di configurazione specifici della piattaforma, ad esempio endpoint, tag o segreti. Questi valori possono essere diversi in ogni singolo host in cui viene distribuita l'applicazione. I descrittori/manifesti di distribuzione creati dagli sviluppatori di applicazioni fanno riferimento agli oggetti di configurazione contenenti questi valori, ad esempio mappe di configurazione o segreti. Gli sviluppatori di applicazioni si aspettano che questi oggetti di configurazione siano presenti nell'host e siano disponibili per l'utilizzo dell'applicazione. In genere questi oggetti e i relativi valori vengono forniti da un team della piattaforma. A seconda dell'organizzazione, l'utente tipo del team della piattaforma può essere preparato da reparti/persone diverse, ad esempio il reparto IT globale, quello del sito, i proprietari dei dispositivi e così via.
I compiti degli sviluppatori di applicazioni e del team della piattaforma sono completamente separati. Gli sviluppatori di applicazioni si dedicano all'applicazione; ne sono i proprietari e la configurano. Allo stesso modo il team della piattaforma è proprietario e configura la piattaforma. Il punto chiave è che il team della piattaforma non configura le applicazioni, configura gli ambienti per le applicazioni. In pratica fornisce valori di variabile di ambiente delle applicazioni da usare.
Le configurazioni della piattaforma spesso sono costituite da configurazioni comuni, irrilevanti per le applicazioni che le usano, e da configurazioni specifiche dell'applicazione che possono essere univoche per ogni applicazione.
Anche se il team della piattaforma potrebbe avere una conoscenza limitata delle applicazioni e del loro funzionamento, sa quale configurazione di piattaforma debba essere presente nell'host di destinazione. Queste informazioni vengono fornite dagli sviluppatori di applicazioni. Gli sviluppatori indicano i valori di configurazione necessari per l'applicazione, i relativi tipi e i vincoli. Uno dei modi per definire questo contratto consiste nell'usare uno schema JSON. Ad esempio:
JSON
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "patch-to-core Platform Config Schema",
"description": "Schema for platform config",
"type": "object",
"properties": {
"ENVIRONMENT": {
"type": "string",
"description": "Environment Name"
},
"TimeWindowShift": {
"type": "integer",
"description": "Time Window Shift"
},
"QueryIntervalSec": {
"type": "integer",
"description": "Query Interval Sec"
},
"module": {
"type": "object",
"description": "module",
"properties": {
"drop-threshold": { "type": "number" }
},
"required": ["drop-threshold"]
}
},
"required": [
"ENVIRONMENT",
"module"
]
}
Questo approccio è noto nella community degli sviluppatori perché lo schema JSON viene usato da Helm per definire i possibili valori da fornire per un grafico Helm.
Un contratto formale consente anche l'automazione. Il team della piattaforma usa il piano di controllo per fornire i valori di configurazione. Il piano di controllo analizza le applicazioni che devono essere distribuite in un host. Usa gli schemi di configurazione per consigliare quali valori devono essere forniti dal team della piattaforma. Il piano di controllo compone i valori di configurazione per ogni istanza dell'applicazione e li convalida sullo schema per verificare se sono presenti tutti i valori.
Il piano di controllo può eseguire la convalida in più fasi in momenti diversi. Ad esempio quando viene fornito un valore di configurazione dal team della piattaforma per controllare il tipo, il formato e i vincoli di base, il piano di controllo convalida il valore di configurazione. La convalida finale e la convalida più importante viene eseguita quando il piano di controllo compone tutti i valori di configurazione disponibili dell'applicazione nello snapshot di configurazione. Solo a questo punto è possibile verificare la presenza di valori di configurazione obbligatori e di vincoli di integrità che interessano più valori, provenienti da origini diverse.
Il piano di controllo compone gli snapshot del valore di configurazione delle istanze dell'applicazione nelle destinazioni di distribuzione. Esegue il pull dei valori da contenitori di configurazione diversi. La relazione di questi contenitori può rappresentare una gerarchia o un grafico. Il piano di controllo segue alcune regole per identificare quali valori di configurazione da quali contenitori debbano essere idratati nello snapshot di configurazione dell'applicazione. È responsabilità del team della piattaforma definire i contenitori di configurazione e stabilire le regole di idratazione. Gli sviluppatori di applicazioni non sono a conoscenza di questa struttura. Sono consapevoli dei valori di configurazione da fornire e non è compito loro conoscere la provenienza dei valori.
Un modo semplice e flessibile per implementare la composizione della configurazione è l'approccio di corrispondenza delle etichette.
In questo diagramma i valori di configurazione dei contenitori raggruppano i valori di configurazione a livelli diversi, ad esempio Sito, Riga, Ambiente e Area. A seconda dell'organizzazione, i valori in questi contenitori possono essere forniti da utenti diversi, ad esempio dal reparto IT globale, dal reparto IT del sito, dai proprietari dei dispositivi o semplicemente dal team della piattaforma. Ogni contenitore è contrassegnato con un set di etichette che definiscono dove sono applicabili i valori di questo contenitore. Oltre ai contenitori di configurazione, sono presenti astrazioni che rappresentano l'applicazione e l'host in cui deve essere distribuita l'applicazione. Entrambi sono contrassegnati anche con le etichette. La combinazione delle etichette dell'applicazione e dell'host compone il set di etichette dell'istanza. Questo set determina i valori dei contenitori di configurazione di cui eseguire il pull nello snapshot di configurazione dell'applicazione. Questo snapshot viene fornito all'host e inviato all'istanza dell'applicazione. Il piano di controllo esegue l'iterazione sui contenitori e valuta se le etichette del contenitore corrispondono al set di etichette dell'istanza. In tal caso i valori del contenitore vengono inclusi nello snapshot finale; in caso contrario il contenitore viene ignorato. Il piano di controllo può essere configurato con diverse strategie di override e unione per gli oggetti e le matrici complessi.
Uno dei principali vantaggi di questo approccio è la scalabilità. La struttura dei contenitori di configurazione viene astratta dall'istanza dell'applicazione che non conosce l'effettiva provenienza dei valori. Ciò consente al team della piattaforma di modificare facilmente i contenitori di configurazione, introdurre nuovi livelli e gruppi di configurazione senza riconfigurare centinaia di istanze dell'applicazione.
Il piano di controllo compone gli snapshot di configurazione per ogni istanza dell'applicazione in ogni host. La varietà di applicazioni, host, tecnologie sottostanti e modalità di distribuzione delle applicazioni può essere molto ampia. Inoltre la stessa applicazione può essere distribuita completamente, diversamente dall'ambiente di sviluppo agli ambienti di produzione. Il compito del piano di controllo consiste nel gestire le configurazioni, senza che ciò sia mirato alla loro distribuzione. Deve essere indipendente dalle tecnologie dell'applicazione/host sottostanti e generare snapshot di configurazione in un formato appropriato per ogni caso (ad esempio una mappa di configurazione Kubernetes, un file di proprietà, un catalogo Symphony o un altro formato).
Un'opzione consiste nell'assegnare modelli diversi a diversi tipi di host. Questi modelli vengono usati dal piano di controllo quando genera snapshot di configurazione per le applicazioni da distribuire nell'host. Sarebbe utile applicare un approccio standard per la creazione di modelli, che sia noto nella community degli sviluppatori. Ad esempio i modelli seguenti possono essere definiti con i modelli Go che sono diffusamente usati nel settore:
YAML
# Standard Kubernetes config map
apiVersion: v1
kind: ConfigMap
metadata:
name: platform-config
namespace: {{ .Namespace}}
data:
{{ toYaml .ConfigData | indent 2}}
YAML
# Symphony catalog object
apiVersion: federation.symphony/v1
kind: Catalog
metadata:
name: platform-config
namespace: {{ .Namespace}}
spec:
type: config
name: platform-config
properties:
{{ toYaml .ConfigData | indent 4}}
YAML
# JSON file
{{ toJson .ConfigData}}
Questi modelli vengono quindi assegnati rispettivamente all'host A, B e C. Supponendo che un'applicazione con gli stessi valori di configurazione venga distribuita in tutti e tre gli host, il piano di controllo genera tre snapshot di configurazione diversi per ogni istanza:
YAML
# Standard Kubernetes config map
apiVersion: v1
kind: ConfigMap
metadata:
name: platform-config
namespace: line1
data:
FACTORY_NAME: Atlantida
LINE_NAME_LOWER: line1
LINE_NAME_UPPER: LINE1
QueryIntervalSec: "911"
YAML
# Symphony catalog object
apiVersion: federation.symphony/v1
kind: Catalog
metadata:
name: platform-config
namespace: line1
spec:
type: config
name: platform-config
properties:
FACTORY_NAME: Atlantida
LINE_NAME_LOWER: line1
LINE_NAME_UPPER: LINE1
QueryIntervalSec: "911"
JSON
{
"FACTORY_NAME" : "Atlantida",
"LINE_NAME_LOWER" : "line1",
"LINE_NAME_UPPER": "LINE1",
"QueryIntervalSec": "911"
}
Il piano di controllo opera con contenitori di configurazione che raggruppano i valori di configurazione a livelli diversi in una gerarchia o in un grafo. Questi contenitori devono essere archiviati in un punto qualsiasi. L'approccio più ovvio consiste nell'usare un database. Potrebbe essere utilizzato un database etcd, relazionale, gerarchico o un database a grafo, offrendo l'esperienza più flessibile e affidabile. Il database consente di tenere traccia e gestire in modo granulare i valori di configurazione a livello di ogni singolo contenitore di configurazione.
Oltre alle funzionalità principali, ad esempio l'archiviazione e la possibilità di eseguire query e modificare gli oggetti di configurazione in modo efficace, è necessario che ci siano funzionalità correlate al rilevamento delle modifiche, alle approvazioni, alle promozioni, ai rollback, ai confronti delle versioni e così via. Il piano di controllo può implementare tutto ciò su un database e incapsulare tutti gli elementi in un servizio gestito monolitico.
In alternativa, questa funzionalità può essere delegata a Git per seguire il concetto di "configurazione come codice". Ad esempio Kalypso, essendo un operatore Kubernetes, considera i contenitori di configurazione come delle risorse Kubernetes personalizzate, essenzialmente archiviate nel database etcd. Ciò accade anche se il piano di controllo non stabilisce che sia una pratica comune originare valori di configurazione in un repository Git applicando tutti i vantaggi offerti. I valori di configurazione vengono quindi recapitati in un archivio Kubernetes etcd con un operatore GitOps in cui il piano di controllo può usarli per eseguire le composizioni.
Non è necessario disporre di un singolo repository Git con valori di configurazione per l'intera organizzazione. Un repository di questo tipo potrebbe diventare un collo di bottiglia su larga scala, considerate la varietà di utenti del tipo "team della piattaforma", le loro responsabilità e i relativi livelli di accesso. È invece possibile usare riferimenti agli operatori GitOps, ad esempio Flux GitRepository e Flux Kustomization, per creare una gerarchia di repository ed eliminare i punti di attrito:
Ogni volta che gli sviluppatori di applicazioni introducono una modifica nell'applicazione, producono una nuova versione dell'applicazione. Analogamente, un nuovo valore di configurazione della piattaforma porta a una nuova versione dello snapshot di configurazione. Il controllo delle versioni consente di tenere traccia delle modifiche, delle implementazioni esplicite e dei rollback.
Un punto chiave è che vengano effettuati i controlli delle versioni degli snapshot di configurazione dell'applicazione in modo indipendente l'uno dall'altro. Una singola modifica del valore di configurazione a livello globale o del sito non produce necessariamente nuove versioni di tutti gli snapshot di configurazione dell'applicazione; influisce solo sugli snapshot in cui questo valore viene idratato. Un modo semplice ed efficace per tenere traccia del valore consiste nell'usare un hash del contenuto dello snapshot come una versione di questo. In questo modo se il contenuto dello snapshot è stato modificato perché è stato modificato qualcosa nelle configurazioni globali, sarà disponibile una nuova versione. Questa nuova versione è un oggetto da applicare manualmente o automaticamente. In ogni caso si tratta di un evento rilevabile di cui può essere eseguito il rollback, se necessario.
- Esaminare un'implementazione di esempio per esplorare la gestione del carico di lavoro in un ambiente multi-cluster con GitOps.
- Esplorare un repository di esempio di gestione del carico di lavoro multi-cluster.
- Concetto: processo CD con GitOps.
- Implementazione di esempio: esplorare il flusso CI/CD con GitOps.