Introduzione a GitOps per OpenShift

Oggi parleremo dei principi e dei modelli di GitOps, nonché di come questi modelli vengono implementati sulla piattaforma OpenShift. Una guida interattiva su questo argomento è disponibile al link.

In breve, GitOps è un insieme di metodi pratici per l'utilizzo delle pull request di Git per gestire le configurazioni dell'infrastruttura e delle applicazioni. Il repository Git all'interno di GitOps è considerato come un'unica fonte di informazioni sullo stato del sistema, con qualsiasi cambiamento di questo stato completamente tracciato e soggetto a audit.

L'idea di tracciare le modifiche in GitOps non è affatto nuova, questo approccio è già da tempo e praticamente universalmente applicato nel lavoro con il codice sorgente delle applicazioni. GitOps semplicemente implementa funzioni analoghe (verifica delle review, pull request, tag, ecc.) nella gestione delle configurazioni dell'infrastruttura e delle applicazioni, offrendo vantaggi simili a quelli della gestione del codice sorgente.

Non esiste una definizione accademica per GitOps o un insieme di regole approvato, ma solo un insieme di principi su cui si basa questa pratica:

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

Principi di GitOps

• Le definizioni dei sistemi sono descritte come codice sorgente

La configurazione dei sistemi è considerata come codice, pertanto può essere archiviata e versione automaticamente nel repository Git, che funge da unica fonte di verità. Questo approccio consente di applicare (rollout) e ripristinare (rollback) facilmente le modifiche nei sistemi.

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

Archiviando e versionando in Git lo stato desiderato dei sistemi, otteniamo la possibilità di applicare e ripristinare facilmente le modifiche nei sistemi e nelle applicazioni. Possiamo anche utilizzare 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 vengono applicate alle configurazioni nel repository. Ad esempio, possono essere sottoposte a revisione da altri membri del team o passate attraverso i test CI.

E non è necessario concedere privilegi di amministratore a destra e a manca. Per effettuare il commit delle modifiche alla configurazione, gli utenti devono avere i privilegi appropriati nel repository Git dove sono memorizzate queste configurazioni.

• Risoluzione del problema del drift incontrollato delle configurazioni

Quando lo stato desiderato del sistema è memorizzato nel repository Git, rimane solo da trovare il software che controlli se lo stato attuale del sistema corrisponde al suo stato desiderato. Se non è così, questo software deve - a seconda delle impostazioni - correggere autonomamente la divergenza o avvisarci in merito al drift delle configurazioni.

Modelli GitOps per OpenShift

On-Cluster Resource Reconciller

Secondo questo modello, nel cluster c'è un controller che si occupa di confrontare le risorse Kubernetes (file YAML) nel repository Git con le risorse reali del cluster. Al rilevamento delle discrepanze, il controller invia notifiche e, se necessario, prende misure per risolvere le non conformità. Questo modello GitOps è utilizzato in Anthos Config Management e Weaveworks Flux.

External Resource Reconciler (Push)

Questo modello può essere considerato una variazione del precedente, in cui abbiamo uno o più controller che si occupano della sincronizzazione delle risorse tra coppie 'repository Git – cluster Kubernetes'. La differenza è che in ogni cluster gestito non deve necessariamente esserci un controller separato. Le coppie 'Git – cluster k8s' vengono spesso definite come descrizioni CRD (custom resources definition), in cui è possibile specificare come il controller deve effettuare la sincronizzazione. Nell'ambito di questo modello, i controller confrontano il repository Git specificato nel CRD con le risorse del cluster Kubernetes, che sono anch'esse definite nel CRD, e compiono le azioni appropriate in base ai risultati del confronto. In particolare, questo modello GitOps è utilizzato in ArgoCD.

GitOps sulla piattaforma OpenShift

Amministrazione dell'infrastruttura Kubernetes multi-cluster

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

Ad esempio, nell'uso di calcoli periferici, i cluster di un singolo cliente possono essere distribuiti in centinaia o addirittura migliaia. Di conseguenza, è costretto a gestire più cluster OpenShift indipendenti o coordinati nel cloud pubblico e on-premise.

Questo implica dover affrontare una serie di problemi, tra cui:

• Controllare che i cluster siano in uno stato identico (configurazioni, monitoraggio, storage, ecc.)
• Ricreare (o ripristinare) i cluster a uno stato noto.
• Creare nuovi cluster da uno stato noto.
• Applicare modifiche a più cluster OpenShift.
• Annullare modifiche su più cluster OpenShift.
• Collegare configurazioni templated a vari ambienti.

Configurazioni dell'applicazione

Nel corso del loro ciclo di vita, le applicazioni spesso passano attraverso una catena di cluster (sviluppo, collaudo, 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 più regioni di una piattaforma cloud pubblica.

In questo caso, si devono risolvere le seguenti problematiche:

• Garantire il movimento delle applicazioni (file binari, configurazioni, ecc.) tra i cluster (sviluppo, collaudo, ecc.).
• Applicare modifiche alle applicazioni (file binari, configurazioni, ecc.) in diversi cluster OpenShift.
• Annullare le modifiche delle applicazioni al livello del precedente stato noto.

Scenario d'uso di OpenShift GitOps

1. Applicazione delle modifiche dal repository Git

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

2. Sincronizzazione con Secret Manager

All'amministratore sarà utile la possibilità di sincronizzare oggetti secret di OpenShift con strumenti software come Vault per gestirli attraverso appositi strumenti.

3. Controllo delle divergenze delle configurazioni

L'amministratore sarebbe favorevole se OpenShift GitOps potesse rilevare autonomamente e avvisare delle discrepanze tra le configurazioni reali e quelle definite nel repository, in modo da poter reagire rapidamente alle divergenze.

4. Notifiche sul drift delle configurazioni

Utili nel caso in cui l'amministratore voglia essere informato tempestivamente su casi di drift delle configurazioni, affinché possa prendere rapidamente le misure appropriate autonomamente.

5. Sincronizzazione manuale delle configurazioni in caso di drift

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

6. Autosincronizzazione delle configurazioni in caso di drift

L'amministratore può anche configurare il cluster OpenShift per una sincronizzazione automatica con il repository al rilevamento di un drift, in modo che la configurazione del cluster sia sempre allineata con le configurazioni in Git.

7. Più cluster – un repository

L'amministratore può memorizzare in un unico repository Git le configurazioni di più cluster OpenShift diversi e applicarle selettivamente all'occorrenza.

8. Gerarchia delle configurazioni dei cluster (ereditarietà)

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

Ad esempio, se l'amministratore imposta nel repository Git la gerarchia "Cluster di produzione (prod) → Cluster del sistema X → Cluster di produzione del sistema X", allora ai cluster di produzione del sistema X vengono applicati 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 sovrascrittura delle configurazioni

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

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

L'amministratore può impostare condizioni per applicare o non applicare determinate configurazioni a cluster con caratteristiche specifiche.

11. Supporto per i modelli

Agli sviluppatori sarà utile poter scegliere come verranno definiti le risorse dell'applicazione (Helm Chart, yaml puro di Kubernetes ecc.), per utilizzare il formato più adatto per ogni specifica applicazione.

Strumenti GitOps sulla piattaforma OpenShift

ArgoCD

ArgoCD implementa il modello di riconciliazione delle risorse esterne 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 quando ArgoCD non è operativo.

Sito ufficiale

Flux

Flux implementa il modello di riconciliazione delle risorse on-cluster e, di conseguenza, non c'è un controllo centralizzato del repository delle definizioni, il che rappresenta un punto debole. D'altra parte, proprio a causa dell'assenza di centralizzazione, la possibilità di gestire le applicazioni rimane anche in caso di guasto di un cluster.

Sito ufficiale

Installazione di ArgoCD su OpenShift

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

Per distribuire ArgoCD sulla piattaforma OpenShift 4, segui i seguenti passaggi come amministratore del cluster:

Distribuzione 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}')

Modificare il server ArgoCD affinché venga visto dal Route di OpenShift

# 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

Distribuzione dello strumento CLI di ArgoCD

# 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 del server ArgoCD

# 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, sarà possibile lavorare con il server ArgoCD tramite la console web ArgoCD WebUI o lo strumento della riga di comando ArgoCD CLI.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps – non è mai troppo tardi

«Il treno è partito» – così si dice riguardo a una situazione in cui l'opportunità di fare qualcosa è stata persa. Nel caso di OpenShift, il desiderio di inziare immediatamente a utilizzare questa nuova piattaforma fantastica crea spesso una situazione simile nella gestione e manutenzione dei percorsi, dei deployment e di altri oggetti OpenShift. Ma c'è sempre la possibilità che l'occasione non sia completamente persa?

Continuando la serie di articoli su GitOps, oggi mostreremo come trasformare un'applicazione creata manualmente e le sue risorse in un processo in cui tutto è gestito dallo strumento GitOps. Per questo, inizialmente distribuiremo manualmente l'applicazione httpd. Nello screenshot sottostante è mostrato come creiamo uno spazio dei nomi, un deployment e un servizio, e poi rendiamo esposto questo servizio per 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 manualmente. Ora deve essere trasferita sotto la gestione di GitOps senza perdere l'accessibilità. In breve, ecco come si fa:

• Creiamo un repository Git per il codice.
• Esportiamo i nostri oggetti attuali e li carichiamo nel repository Git.
• Selezioniamo e implementiamo gli strumenti GitOps.
• Aggiungiamo il nostro repository a questi strumenti.
• Definiamo l'applicazione nel nostro strumento GitOps.
• Eseguiamo un lancio di prova dell'applicazione utilizzando gli strumenti GitOps.
• Sincronizziamo gli oggetti utilizzando gli strumenti GitOps.
• Attiviamo la pulizia (pruning) e la sincronizzazione automatica degli oggetti.

Come già detto in precedenza abbiamo chiarito il corretto completamento dei programmi che utilizzano il mediastreamer., in GitOps c'è una sola fonte di informazioni su tutti gli oggetti nei cluster Kubernetes: il repository Git. Presumiamo quindi che nella vostra organizzazione sia già in uso un repository Git. Può essere pubblico o privato, ma deve necessariamente essere accessibile ai cluster Kubernetes. Può essere lo stesso repository usato per il codice delle applicazioni, o un repository separato creato espressamente per i deployment. Si consiglia di avere permessi rigidi nel repository, poiché conterrà oggetti secret, rotte e altre informazioni sensibili.

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

Se i file YAML degli oggetti non sono stati memorizzati localmente o in Git, sarà necessario utilizzare i binari oc o kubectl. Nello screenshot qui sotto chiediamo YAML per il nostro namespace, per il deployment, il servizio e la rotta. Prima di questo abbiamo clonata il repository appena creato e ci siamo spostati in esso 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 's/generation: .*//d' deployment.yaml

Inoltre, è necessario modificare la rotta. Prima imposteremo una variabile multi-linea e poi sostituiremo 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

Così, abbiamo sistemato i file; ora rimane da salvarli nel repository Git. Dopodiché, questo 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

Dopo partiamo dal presupposto che ArgoCD sia già implementato (come farlo – vedi sopra) post). Pertanto, aggiungeremo ad Argo CD il repository che abbiamo creato, contenente il codice dell'applicazione dal nostro esempio. Assicurati solo di specificare proprio quel repository che hai creato in precedenza.

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

Ora creiamo l'applicazione. L'applicazione specifica i valori affinché lo strumento GitOps comprenda quale repository e quali percorsi utilizzare, quale OpenShift è necessario per gestire gli oggetti, e quale specifico ramo del repository è necessario, e se la risincronizzazione delle risorse deve essere eseguita automaticamente.

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

Una volta che l'applicazione è stata definita in Argo CD, questo strumento inizia a controllare gli oggetti già implementati per verificarne la corrispondenza con le definizioni nel repository. Nel nostro esempio, la risincronizzazione e la pulizia sono disattivate, quindi gli elementi rimangono invariati per ora. Nota che nell'interfaccia di Argo CD la nostra applicazione avrà lo stato "Out of Sync" (Non sincronizzato), poiché non c'è alcun label che ArgoCD dovrebbe applicare.
Ecco perché, quando avvieremo la sincronizzazione più tardi, non ci sarà un reinvio degli oggetti.

Ora eseguiamo un tentativo di avvio per assicurarci che nei nostri file non ci siano errori.

argocd app sync simple-app --dry-run

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

argocd app sync simple-app

Dopo aver eseguito il comando argocd get sulla nostra applicazione, dovremmo vedere che lo stato dell'applicazione è cambiato in Healthy (In salute) o Synced (Sincronizzato). Questo significherà che tutte le risorse nel repository Git corrispondono ora alle risorse già implementate.

argocd app get simple-app
Name:               simple-app
Project:            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:        
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...   

Ora possiamo attivare la risincronizzazione automatica 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 la gestione di GitOps un'applicazione che inizialmente non utilizzava affatto GitOps.

Fonte: habr.com