Introduzione a GitOps per OpenShift

Oggi parleremo dei principi e dei modelli di GitOps, oltre a come questi modelli vengano implementati sulla piattaforma OpenShift. È disponibile una guida interattiva su questo argomento. al link.

In breve, GitOps è un insieme di pratiche per utilizzare le pull request di Git per gestire le configurazioni delle infrastrutture e delle applicazioni. In GitOps, il repository Git è visto come una fonte unica di verità sullo stato del sistema, con qualsiasi modifica a questo stato completamente tracciabile e auditabile.

L'idea di tracciare le modifiche in GitOps non è affatto nuova; questo approccio è già da tempo e praticamente universalmente utilizzato nella gestione del codice sorgente delle applicazioni. GitOps applica funzioni analoghe (review, pull request, tag, ecc.) nella gestione delle configurazioni delle infrastrutture e delle applicazioni, offrendo vantaggi simili a quelli della gestione del codice sorgente.

Per GitOps non esiste una definizione accademica o un insieme di regole formalmente approvate, ma solo un insieme di principi su cui si basa questa pratica:

• La descrizione dichiarativa del sistema è archiviata nel repository Git (configurazioni, monitoraggio, ecc.).
• Le modifiche di stato vengono eseguite tramite pull request.
• Lo stato dei sistemi operativi è allineato con i dati nel repository utilizzando push request di Git.

Principi di GitOps

• Le definizioni dei sistemi sono descritte come codice sorgente.

La configurazione dei sistemi è considerata codice, quindi può essere archiviata e versionata automaticamente nel repository Git, che funge da unica fonte di verità. Questo approccio consente un facile rollout e rollback delle modifiche nei sistemi.

• Lo stato desiderato e la configurazione dei sistemi sono specificati e versionati in Git.

Archiviando e versionando in Git lo stato desiderato dei sistemi, otteniamo la possibilità di effettuare facilmente rollout e rollback delle modifiche nei sistemi e nelle applicazioni. Possiamo anche sfruttare i meccanismi di sicurezza di Git per controllare la proprietà del codice e verificarne l'autenticità.

• Le modifiche alle configurazioni possono essere applicate automaticamente tramite pull request.

Utilizzando le pull request di Git, possiamo gestire facilmente come le modifiche vengano applicate alle configurazioni nel repository. Ad esempio, possono essere sottoposte a revisione da altri membri del team o eseguite tramite test CI e altro.

E non è necessario concedere diritti di amministratore a destra e a manca. Per effettuare il commit delle modifiche nella configurazione, gli utenti hanno bisogno solo delle autorizzazioni adeguate nel repository Git in cui sono conservate queste configurazioni.

• Risoluzione del problema del drift incontrollato delle configurazioni

Quando lo stato desiderato del sistema è conservato in un repository Git, dobbiamo solo trovare un software che controlli che lo stato attuale del sistema corrisponda al suo stato desiderato. Se non è così, questo software deve – a seconda delle impostazioni – correggere autonomamente la discrepanza oppure avvisarci del drift delle configurazioni.

Modelli GitOps per OpenShift

On-Cluster Resource Reconciller

Secondo questo modello, nel cluster è presente un controller che si occupa di confrontare le risorse Kubernetes (file YAML) nel repository Git con le risorse reali del cluster. In caso di discrepanze, il controller invia notifiche e, se necessario, adotta misure per risolvere le incongruenze. Questo modello GitOps è utilizzato in Anthos Config Management e Weaveworks Flux.

External Resource Reconciler (Push)

Questo modello può essere considerato una variante del precedente, in cui abbiamo uno o più controller che gestiscono la sincronizzazione delle risorse tra le coppie "repository Git – cluster Kubernetes". La differenza è che in ogni cluster gestito non è necessario avere un proprio controller separato. Le coppie "Git – cluster k8s" sono spesso definite come descrizioni CRD (custom resources definition), in cui è possibile specificare come il controller debba eseguire la sincronizzazione. In questo modello, i controller confrontano il repository Git specificato nel CRD con le risorse del cluster Kubernetes anch'esse definite nel CRD, e intraprendono le azioni appropriate sulla base del risultato del confronto. In particolare, questo modello GitOps è utilizzato in ArgoCD.

GitOps sulla piattaforma OpenShift

Amministrazione di un'infrastruttura Kubernetes multicluster

Con la diffusione di Kubernetes e la crescente popolarità delle strategie multi-cloud e dell'edge computing, aumenta anche il numero medio di cluster OpenShift per cliente.

Ad esempio, nell'uso dell'edge computing, i cluster di un singolo cliente possono essere distribuiti in centinaia e persino migliaia. Di conseguenza, si trova a dover gestire più cluster OpenShift indipendenti o collegati sia nel cloud pubblico che on-premise.

In questo contesto, è necessario affrontare una serie di problemi, in particolare:

• Controllare che i cluster siano in uno stato identico (configurazioni, monitoraggio, archiviazione, ecc.)
• Ricreare (o ripristinare) i cluster a uno stato noto.
• Creare nuovi cluster a partire da uno stato noto.
• Applicare modifiche a più cluster OpenShift.
• Ripristinare modifiche su più cluster OpenShift.
• Collegare configurazioni template a diversi ambienti.

Configurazioni dell'applicazione

Durante il ciclo di vita delle applicazioni, queste passano spesso attraverso una serie di cluster (sviluppo, staging, ecc.) prima di arrivare al cluster di produzione. Inoltre, a causa delle esigenze di disponibilità e scalabilità, i clienti spesso distribuiscono le applicazioni su più cluster on-premise o in diverse regioni di una piattaforma cloud pubblica.

In questo processo, è necessario affrontare le seguenti sfide:

• Assicurare il trasferimento delle applicazioni (file binari, configurazioni, ecc.) tra i cluster (sviluppo, staging, ecc.).
• Applicare modifiche alle applicazioni (file binari, configurazioni, ecc.) in diversi cluster OpenShift.
• Ripristinare le modifiche alle applicazioni a uno stato precedente conosciuto.

Casi d'uso di OpenShift GitOps

1. Applicazione di modifiche da un repository Git

L'amministratore del cluster può memorizzare le configurazioni del cluster OpenShift in un repository Git e applicarle automaticamente per creare nuovi cluster e portarli in uno stato identico a quello conosciuto memorizzato nel repository Git, senza sforzo eccessivo.

2. Sincronizzazione con Secret Manager

L'amministratore troverà utile avere la possibilità di sincronizzare gli oggetti secret di OpenShift con software corrispondenti come Vault, per gestirli tramite strumenti appositamente creati per questo scopo.

3. Controllo della deriva delle configurazioni

L'amministratore sarà favorevole se OpenShift GitOps rileverà e avviserà automaticamente sulle discrepanze tra le configurazioni reali e quelle definite nel repository, per poter reagire rapidamente alla deriva.

4. Notifiche sulla deriva delle configurazioni

Saranno utili nel caso in cui l'amministratore desideri essere informato prontamente su eventuali casi di deriva delle configurazioni, per poter adottare rapidamente le opportune misure personalmente.

5. Sincronizzazione manuale delle configurazioni in caso di deriva

Consente all'amministratore di sincronizzare il cluster OpenShift con il repository Git nel caso di deriva delle configurazioni, per riportare rapidamente il cluster a uno stato noto precedente.

6. Autosincronizzazione delle configurazioni in caso di deriva

L'amministratore può anche configurare il cluster OpenShift per la sincronizzazione automatica con il repository al rilevamento di una deriva, affinché la configurazione del cluster corrisponda sempre ai file di configurazione in Git.

7. Più cluster – un repository

L'amministratore può memorizzare in un único repository Git le configurazioni di più cluster OpenShift e applicarle selettivamente secondo necessità.

8. Gerarchia delle configurazioni dei cluster (ereditarietà)

L'amministratore può definire una gerarchia di configurazioni dei cluster nel repository (stage, prod, app portfolio, ecc. con ereditarietà). In altre parole, può determinare come devono essere applicate le configurazioni – a uno o più cluster.

Ad esempio, se l'amministratore definisce nel repository Git una gerarchia 'Cluster di produzione (prod) → Cluster del sistema X → Cluster di produzione del sistema X', allora ai cluster di produzione del sistema X viene applicata la combinazione delle seguenti configurazioni:

• Configurazioni comuni a tutti i cluster di produzione.
• Configurazioni per il cluster del sistema X.
• Configurazioni per il cluster di produzione del sistema X.

9. Modelli e override delle configurazioni

L'amministratore può sovrascrivere un insieme di configurazioni ereditate e i loro valori, ad esempio, per personalizzare ulteriormente la configurazione per specifici cluster a cui verranno applicate.

10. Include ed exclude selettivi per le configurazioni, configurazioni delle applicazioni

L'amministratore può definire le condizioni per l'applicazione o meno di determinate configurazioni ai cluster con specifiche caratteristiche.

11. Supporto per i template

Gli sviluppatori troveranno utile la possibilità di scegliere come vengono definiti le risorse dell'applicazione (Helm Chart, yaml Kubernetes puro, ecc.) per utilizzare il formato più adatto per ogni specifica applicazione.

Strumenti GitOps sulla piattaforma OpenShift

ArgoCD

ArgoCD implementa il modello External Resource Reconcile e offre un'interfaccia utente centralizzata per orchestrare le relazioni tra cluster e repository Git secondo lo schema «uno a molti». Tra gli svantaggi di questo programma c'è l'impossibilità di gestire le applicazioni se ArgoCD non è attivo.

Sito ufficiale

Flux

Flux implementa il modello On-Cluster Resource Reconcile e, di conseguenza, qui non esiste una gestione centralizzata del repository delle definizioni, che rappresenta un punto debole. D'altra parte, proprio per la mancanza di centralizzazione, è possibile gestire le applicazioni anche in caso di guasto di un cluster.

Sito ufficiale

Installazione di ArgoCD su OpenShift

ArgoCD offre un'eccellente interfaccia a riga di comando e una web console, quindi qui non considereremo Flux e altre alternative.

Per implementare ArgoCD sulla piattaforma OpenShift 4, eseguire i seguenti passaggi come amministratore del cluster:

Implementazione dei componenti di ArgoCD sulla piattaforma OpenShift

# Create a new namespace for ArgoCD components
oc create namespace argocd
# Apply the ArgoCD Install Manifest
oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
# Get the ArgoCD Server password
ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

Modifica di ArgoCD Server affinché sia visibile tramite OpenShift Route

# Patch ArgoCD Server so no TLS is configured on the server (--insecure)
PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
oc -n argocd patch deployment argocd-server -p $PATCH
# Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

Implementazione dello strumento ArgoCD Cli

# Download the argocd binary, place it under /usr/local/bin and give it execution permissions
curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
chmod +x /usr/local/bin/argocd

Cambio della password di amministrazione di ArgoCD Server

# Get ArgoCD Server Route Hostname
ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
# Login with the current admin password
argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
# Update admin's password
argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

Dopo aver completato questi passaggi, è possibile lavorare su ArgoCD Server attraverso la web console ArgoCD WebUI o lo strumento a riga di comando ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – non è mai troppo tardi

«Il treno è partito» – si dice così quando l'opportunità di fare qualcosa è andata persa. Nel caso di OpenShift, il desiderio di iniziare subito a utilizzare questa nuova piattaforma fantastica crea spesso situazioni simili nella gestione e manutenzione di route, deployment e altri oggetti di OpenShift. Ma è sempre così che l'opportunità è definitivamente persa?

Continuando la serie di articoli su GitOps, oggi mostreremo come trasformare un'applicazione creata a mano e le sue risorse in un processo gestito dall'insieme di strumenti GitOps. Per fare ciò, prima distribuiremo manualmente l'applicazione httpd. Nello screenshot seguente è illustrato come creiamo uno spazio dei nomi, un deployment e un servizio, per poi esporre questo servizio e creare un percorso.

oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
oc expose svc/httpd -n simple-app

Quindi, abbiamo un'applicazione creata a mano. Ora deve essere migrata sotto la gestione di GitOps senza perdere accessibilità. In breve, questo si fa in questo modo:

• Creiamo un repository Git per il codice.
• Esportiamo i nostri oggetti correnti e li carichiamo nel repository Git.
• Selezioniamo e distribuiamo l'insieme di strumenti GitOps.
• Aggiungiamo il nostro repository a questo insieme di strumenti.
• Definiamo l'applicazione nel nostro insieme di strumenti GitOps.
• Eseguiamo un avvio di prova dell'applicazione utilizzando l'insieme di strumenti GitOps.
• Sincronizziamo gli oggetti con l'insieme di strumenti GitOps.
• Abilitiamo la pulizia (pruning) e l'autosincronizzazione degli oggetti.

Come già accennato in precedenza articolo, in GitOps esiste un solo e unico punto di riferimento per tutte le risorse nei cluster Kubernetes: il repository Git. Presupponiamo, quindi, che nella vostra organizzazione sia già in uso un repository Git. Può essere pubblico o privato, ma deve essere accessibile dai cluster Kubernetes. Questo può essere lo stesso repository utilizzato per il codice delle applicazioni o un repository separato creato appositamente per i deployment. È consigliabile avere permessi rigorosi nel repository, poiché conterrà oggetti secret, rotte e altre informazioni sensibili alla sicurezza.

Nel nostro esempio, creeremo un nuovo repository pubblico su GitHub. Può essere chiamato come si desidera; noi utilizziamo il nome blogpost.

Se i file YAML delle risorse non sono stati archiviati localmente o in Git, sarà necessario utilizzare i binari oc o kubectl. Nello screenshot qui sotto, richiediamo il YAML per il nostro namespace, deployment, servizio e rotta. Prima di ciò, abbiamo clonato il repository appena creato e vi abbiamo navigato con il comando cd.

oc get namespace simple-app -o yaml --export > namespace.yaml
oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
oc get service httpd -o yaml -n simple-app --export > service.yaml
oc get route httpd -o yaml -n simple-app --export > route.yaml

Ora modifichiamo il file deployment.yaml per rimuovere il campo che Argo CD non può sincronizzare.

sed -i '/sgeneration: .*\/d' deployment.yaml

Inoltre, è necessario modificare il percorso. Prima definiamo una variabile multilinea, quindi sostituiamo ingress: null con il contenuto di questa variabile.

export ROUTE="  ingress:                                                            
    - conditions:
        - status: 'True'
          type: Admitted"

sed -i "s\/  ingress: null\/$ROUTE\/g" route.yaml

Quindi, abbiamo sistemato i file, resta da salvarli nel repository Git. Dopo questo, il repository diventa l'unica fonte di informazioni e qualsiasi modifica manuale degli oggetti deve essere rigorosamente vietata.

git commit -am 'initial commit of objects'
git push origin master

Successivamente, partiamo dal presupposto che ArgoCD sia già stato distribuito (per sapere come fare, vedi il precedente un post). Quindi aggiungiamo ad Argo CD il repository che abbiamo creato, contenente il codice dell'applicazione dal nostro esempio. Assicurati solo di specificare esattamente quel repository che hai creato in precedenza.

argocd repo add https://github.com/cooktheryan/blogpost

Ora creiamo l'applicazione. L'applicazione imposta i valori affinché lo strumento GitOps comprenda quale repository e quali percorsi utilizzare, quale OpenShift sia necessario per gestire gli oggetti, quale specifica branch del repository sia necessaria e se debbano avvenire la sincronizzazione automatica delle risorse.

argocd app create --project default 
--name simple-app --repo https://github.com/cooktheryan/blogpost.git 
--path . --dest-server https://kubernetes.default.svc 
--dest-namespace simple-app --revision master --sync-policy none

Dopo aver configurato l'applicazione in Argo CD, questo strumento inizia a controllare gli oggetti già distribuiti per verificarne la conformità alle definizioni nel repository. Nel nostro esempio la sincronizzazione automatica e la pulizia sono disabilitate, quindi gli elementi non cambiano ancora. Si noti che nell'interfaccia di Argo CD la nostra applicazione avrà lo stato 'Out of Sync' (Non sincronizzato), poiché non è presente l'etichetta che ArgoCD applica.
È per questo che, quando avvieremo la sincronizzazione più avanti, la ridistribuzione degli oggetti non avverrà.

Ora eseguiamo un tentativo per assicurarci che i nostri file non contengano errori.

argocd app sync simple-app --dry-run

Se non ci sono errori, possiamo procedere con la sincronizzazione.

argocd app sync simple-app

Dopo aver eseguito il comando argocd get sul nostro applicativo, dovremmo vedere che lo stato dell'applicazione è cambiato in Healthy (Funzionante) o Synced (Sincronizzato). Ciò significa che tutte le risorse nel repository Git corrispondono ora a quelle già distribuite.

argocd app get simple-app
Nome:               simple-app
Progetto:           default
Server:             https://kubernetes.default.svc
Namespace:          simple-app
URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
Repo:               https://github.com/cooktheryan/blogpost.git
Target:             master
Path:               .
Sync Policy:        <nessuna>
Sync Status:        Sincronizzato con master (60e1678)
Health Status:      Healthy
...   

A questo punto, possiamo attivare l'autosincronizzazione e la pulizia, per garantire che nulla venga creato manualmente e che ogni volta che un oggetto viene creato o aggiornato nel repository, venga eseguita una distribuzione.

argocd app set simple-app --sync-policy automated --auto-prune

Quindi, abbiamo trasferito con successo sotto gestione GitOps un'applicazione che inizialmente non utilizzava affatto GitOps.

Fonte: habr.com