🥇Introduzione à GitOps per OpenShift

Oghje parlemu di i principii è di i mudelli di GitOps, è ancu di cumu questi mudelli sò implementati nantu à a piattaforma OpenShift. Una guida interattiva nantu à questu tema hè dispunibule Member.

In poche parole, GitOps hè un inseme di pratiche per aduprà e richieste di pull Git per gestisce l'infrastruttura è e cunfigurazioni di l'applicazione. U repository Git in GitOps hè trattatu cum'è una sola fonte d'infurmazioni nantu à u statu di u sistema, è qualsiasi cambiamenti à questu statu sò cumpletamente tracciabili è auditabili.

L'idea di u seguimentu di u cambiamentu in GitOps ùn hè micca novu; stu approcciu hè statu longu usatu quasi universale quandu travaglia cù u codice fonte di l'applicazione. GitOps simpricimenti implementa funzioni simili (revisioni, pull requests, tags, etc.) in a gestione di l'infrastruttura è a cunfigurazione di l'applicazioni è furnisce benefici simili cum'è in u casu di gestione di codice fonte.

Ùn ci hè micca una definizione accademica o un set di reguli appruvati per GitOps, solu un inseme di principii nantu à quale sta pratica hè custruita:

A descrizzione dichjarazione di u sistema hè guardata in u repository Git (configs, monitoring, etc.).
I cambiamenti di u statu sò fatti attraversu e richieste di pull.
U statu di i sistemi in esecuzione hè purtatu in cunfurmità cù e dati in u repositoriu utilizendu e richieste push Git.

Principi di GitOps

Definizioni di u sistema sò descritti cum'è codice fonte

A cunfigurazione di i sistemi hè trattata cum'è codice per pudè esse guardatu è versione automaticamente in un repository Git, chì serve com'è una sola fonte di verità. Stu approcciu facilita u rollout è rollback cambiamenti in i sistemi.

U statu desideratu è a cunfigurazione di i sistemi sò stallati è versionati in Git

Almacenendu è versionendu u statu desideratu di i sistemi in Git, simu capaci di rializà facilmente è ritruvà i cambiamenti à i sistemi è l'applicazioni. Pudemu ancu aduprà i meccanismi di sicurezza di Git per cuntrullà a pruprietà di u codice è verificà a so autenticità.

I cambiamenti di cunfigurazione ponu esse applicati automaticamente via richieste di pull

Utilizendu e richieste di pull Git, pudemu cuntrullà facilmente cumu i cambiamenti sò applicati à e cunfigurazioni in u repository. Per esempiu, ponu esse datu à l'altri membri di a squadra per rivisione o eseguite per e teste CI, etc.

È à u listessu tempu, ùn ci hè bisognu di distribuisce i puteri amministrativi à manca è à diritta. Per fà cambiamenti di cunfigurazione, l'utilizatori solu bisognu di permessi adatti in u repositoriu Git induve queste cunfigurazioni sò almacenate.

Risolve u prublema di a deriva incontrollata di cunfigurazioni

Quandu u statu desideratu di u sistema hè guardatu in un repository Git, tuttu ciò chì avemu da fà hè di truvà un software chì assicurarà chì u statu attuale di u sistema currisponde à u so statu desideratu. Se questu ùn hè micca u casu, allora stu software duveria - sicondu i paràmetri - o eliminà a discrepanza per sè stessu, o avvisàci nantu à a deriva di cunfigurazione.

Modelli GitOps per OpenShift

Reconciliatore di risorse nantu à u cluster

Sicondu stu mudellu, u cluster hà un controller chì hè rispunsevuli di paragunà e risorse Kubernetes (fichi YAML) in u repository Git cù e risorse reali di u cluster. Se i discrepanzi sò rilevati, u controller manda notifiche è possibbilmente piglia l'azzione per correggere e discrepanze. Stu mudellu GitOps hè utilizatu in Anthos Config Management è Weaveworks Flux.

Reconciliatore di risorse esterne (Push)

Stu mudellu pò esse cunsideratu cum'è una variazione di u precedente, quandu avemu unu o più cuntrolli rispunsevuli di sincronizà e risorse in i coppie "Git repository - Kubernetes cluster". A diferenza quì hè chì ogni cluster gestionatu ùn hà micca necessariamente u so propiu controller separatu. Git - i coppie di cluster k8s sò spessu definiti cum'è CRD (definizioni di risorse persunalizate), chì ponu descriverà cumu u controller deve fà a sincronizazione. In questu mudellu, i cuntrolli paragunanu u repository Git specificatu in u CRD cù i risorse di u cluster Kubernetes, chì sò ancu specificati in u CRD, è eseguinu l'azzioni appropritate basatu nantu à i risultati di a comparazione. In particulare, stu mudellu GitOps hè utilizatu in ArgoCD.

GitOps nantu à a piattaforma OpenShift

Amministrazione di infrastruttura Kubernetes multi-cluster

Cù a diffusione di Kubernetes è a pupularità crescente di strategie multi-nuvola è edge computing, u numeru mediu di clusters OpenShift per cliente hè ancu crescente.

Per esempiu, quandu si usa l'edge computing, i clusters di un cliente ponu esse implementati in centinaie o ancu migliaia. In u risultatu, hè obligatu à gestisce parechji clusters OpenShift indipendenti o coordinati in u nuvulu publicu è in premisa.

In questu casu, assai prublemi anu da esse risolti, in particulare:

Cuntrolla chì i clusters sò in un statu identicu (configs, monitoring, storage, etc.)
Ricreate (o restaurà) clusters basatu annantu à un statu cunnisciutu.
Crea novi clusters basatu annantu à un statu cunnisciutu.
Impulsate i cambiamenti à parechji clusters OpenShift.
Ripristina i cambiamenti in più clusters OpenShift.
Ligà cunfigurazioni mudellu à diversi ambienti.

Cunfigurazioni di l'applicazione

Duranti u so ciclu di vita, l'applicazioni spessu passanu per una catena di clusters (dev, stage, etc.) prima di finisce in un cluster di produzzione. Inoltre, per via di a dispunibilità è di i requisiti di scalabilità, i clienti spessu implementanu applicazioni in più clusters on-premise o in parechje regioni di una piattaforma di nuvola publica.

In questu casu, i seguenti compiti anu da esse risolti:

Assicurà u muvimentu di l'applicazioni (binarii, configs, etc.) trà clusters (dev, stage, etc.).
Eseguite i cambiamenti à l'applicazioni (binarii, cunfigurazioni, etc.) in parechji clusters OpenShift.
Ritorna i cambiamenti à l'applicazioni à un statu cunnisciutu precedente.

OpenShift GitOps Casi d'usu

1. Applicà cambiamenti da u repositoriu Git

Un amministratore di cluster pò almacenà e cunfigurazioni di cluster OpenShift in un repository Git è l'applicà automaticamente per creà senza sforzu novi clusters è i mette in un statu identicu à u statu cunnisciutu almacenatu in u repository Git.

2. Synchronization cù Secret Manager

L'amministratore hà ancu benefiziu da a capacità di sincronizà l'oggetti sicreti OpenShift cù u software appropritatu cum'è Vault in modu di gestisce li utilizendu strumenti apposta per questu.

3. Control di cunfigurazioni drift

L'amministratore serà solu in favore se OpenShift GitOps stessu identifica è avvistà di discrepanze trà e cunfigurazioni reali è quelli specificati in u repositoriu, per pudè risponde rapidamente à a deriva.

4. Notificazioni nantu à a deriva di cunfigurazione

Sò utili in u casu quandu l'amministratore vole amparà rapidamente nantu à i casi di deriva di cunfigurazione per piglià rapidamente e misure appropritate per sè stessu.

5. Sincronizazione manuale di e cunfigurazioni quandu drifting

Permette à l'amministratore di sincronizà u cluster OpenShift cù u repository Git in casu di deriva di cunfigurazione, per rinvià rapidamente u cluster à un statu cunnisciutu precedente.

6.Auto-sincronizazione di cunfigurazioni quandu drifting

L'amministratore pò ancu cunfigurà u cluster OpenShift per sincronizà automaticamente cù u repository quandu una deriva hè rilevata, in modu chì a cunfigurazione di cluster currisponde sempre à e cunfigurazioni in Git.

7. Diversi clusters - un repository

L'amministratore pò almacenà e cunfigurazioni di parechji clusters OpenShift diffirenti in un repository Git è applicà selettivamente cum'è necessariu.

8. Gerarchia di cunfigurazioni di cluster (eredità)

L'amministratore pò stabilisce una ghjerarchia di cunfigurazioni di cluster in u repository (stage, prod, app portfolio, etc. cù eredità). In altre parolle, pò determinà se e cunfigurazioni deve esse applicate à unu o più clusters.

Per esempiu, se un amministratore stabilisce a gerarchia "Clusters di produzzione (prod) → Clusters System X → Clusters di produzzione di u sistema X" in u repository Git, allora una cumminazione di e seguenti cunfigurazioni hè applicata à i clusters di produzzione di u sistema X:

Configs cumuni à tutti i clusters di produzzione.
Configs per u cluster System X.
Configs per u cluster di produzzione di u sistema X.

9. Templates è cunfigurazione overrides

L'amministratore pò annullà un inseme di cunfigurazione ereditata è i so valori, per esempiu, per aghjurnà a cunfigurazione per clusters specifichi à quale seranu applicati.

10. Selettivu include è esclude per cunfigurazioni, cunfigurazioni di l'applicazione

L'amministratore pò stabilisce e cundizioni per l'applicazione o non applicazione di certe cunfigurazioni à clusters cù certe caratteristiche.

11. Supportu di mudelli

I sviluppatori prufittàranu di a capacità di sceglie cumu si definiscenu e risorse di l'applicazione (Helm Chart, pura Kubernetes yaml, etc.) per utilizà u formatu più apprupriatu per ogni applicazione specifica.

Strumenti GitOps nantu à a piattaforma OpenShift

ArgoCD

ArgoCD implementa u mudellu di Reconcile di Risorse Esterne è offre una UI centralizzata per orchestrazione di relazioni unu à parechje trà clusters è repositori Git. I svantaghji di stu prugramma includenu l'incapacità di gestisce l'applicazioni quandu ArgoCD ùn hè micca travagliatu.

Situ web ufficiale

purtata

Flux implementa un mudellu di Reconcile di Risorse On-Cluster è, in u risultatu, ùn ci hè una gestione centralizata di u repositoriu di definizione, chì hè un puntu debule. Per d 'altra banda, precisamente per via di a mancanza di centralizazione, a capacità di gestisce l'applicazioni ferma ancu se un cluster falla.

Situ web ufficiale

Installazione di ArgoCD nantu à OpenShift

ArgoCD offre un'eccellente interfaccia di linea di cumanda è cunsola web, cusì ùn copreremu micca Flux è altre alternative quì.

Per implementà ArgoCD nantu à a piattaforma OpenShift 4, seguite questi passi cum'è amministratore di cluster:

Implementazione di cumpunenti ArgoCD nantu à a 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}')

Migliuramentu di ArgoCD Server in modu chì pò esse vistu da 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 di ArgoCD Cli Tool

# 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

Cambia a password di l'amministratore di u 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

Dopu avè cumpletu sti passi, pudete travaglià cù ArgoCD Server attraversu a cunsola web ArgoCD WebUI o l'uttellu di linea di cumanda ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps - Ùn hè mai troppu tardi

"U trenu hè partutu" - questu hè ciò chì dicenu di una situazione quandu l'uppurtunità di fà qualcosa hè mancata. In u casu di OpenShift, u desideriu di principià immediatamente à utilizà sta nova piattaforma fresca spessu crea esattamente questa situazione cù a gestione è u mantenimentu di rotte, implementazioni è altri oggetti OpenShift. Ma a chance hè sempre completamente persa?

Cuntinuà a seria di articuli circa GitOps, oghje vi mustraremu cumu trasfurmà una applicazione artighjanali è e so risorse in un prucessu induve tuttu hè gestitu da l'arnesi GitOps. Per fà questu, prima implementeremu manualmente l'applicazione httpd. A screenshot quì sottu mostra cumu creamu un spaziu di nome, implementazione è serviziu, è poi espose stu serviziu per creà una strada.

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

Allora avemu una applicazione artighjanali. Avà deve esse trasferitu sottu a gestione GitOps senza perdita di dispunibilità. In breve, face questu:

Crea un repository Git per u codice.
Esportemu i nostri ogetti attuali è li carichemu in u repository Git.
Selezzione è implementazione di strumenti GitOps.
Aghjunghjemu u nostru repository à questu toolkit.
Definimu l'applicazione in u nostru toolkit GitOps.
Facemu un test run di l'applicazione utilizendu u toolkit GitOps.
Sincronizemu l'ogetti cù u toolkit GitOps.
Habilita a poda è l'auto-sincronizazione di l'uggetti.

Cum'è citatu in u precedente articulu, in GitOps ci hè una sola è una sola fonte d'infurmazioni nantu à tutti l'uggetti in u cluster (s) Kubernetes - u repository Git. Dopu, procedemu da a premessa chì a vostra urganizazione usa digià un repository Git. Pò esse publicu o privatu, ma deve esse accessibile à i clusters Kubernetes. Questu pò esse u stessu repository cum'è per u codice di l'applicazione, o un repository separatu creatu apposta per implementazioni. Hè ricumandemu di avè permessi stretti in u repositoriu postu chì i sicreti, rotte è altre cose sensibili à a sicurità seranu guardati quì.

In u nostru esempiu, creeremu un novu repositoriu publicu in GitHub. Pudete chjamà ciò chì vulete, usemu u nome blogpost.

Se i schedarii di l'ughjettu YAML ùn sò micca stati guardati in u locu o in Git, allora avete da aduprà i binari oc o kubectl. In a screenshot sottu dumandemu YAML per u nostru spaziu di nomi, implementazione, serviziu è percorsu. Prima di questu, avemu clonatu u repositoriu novu creatu è cd in questu.

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

Avà edità u schedariu deployment.yaml per sguassà u campu chì Argo CD ùn pò micca sincronizà.

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

Inoltre, a strada deve esse cambiata. Prima setteremu una variabile multilinea è poi rimpiazzà l'ingress: null cù u cuntenutu di quella variabile.

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

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

Allora, avemu risoltu i schedari, tuttu ciò chì resta hè di salvà in u repository Git. Dopu chì questu repository diventa l'unica fonte d'infurmazioni, è qualsiasi mudificazione manuale di l'uggetti deve esse strettamente pruibita.

git commit -am ‘initial commit of objects’
git push origin master

In più partendu da u fattu chì avete digià implementatu ArgoCD (cumu fà questu - vede precedente post). Dunque, aghjunghje à u CD Argo u repository chì avemu creatu, chì cuntene u codice di l'applicazione da u nostru esempiu. Solu assicuratevi di specificà u repositoriu esatta chì avete creatu prima.

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

Avà criemu l'applicazione. L'applicazione stabilisce valori per chì u toolkit GitOps capisce quale repository è percorsi da aduprà, quale OpenShift hè necessariu per gestisce l'uggetti, quale ramu specificu di u repositoriu hè necessariu, è se e risorse anu da sincronizà 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 chì una applicazione hè specificata in u CD Argo, u toolkit cumencia à cuntrollà l'uggetti digià implementati contru à e definizioni in u repository. In u nostru esempiu, l'auto-sync è a pulizia sò disattivati, perchè l'elementi ùn cambianu ancu. Per piacè nutate chì in l'interfaccia Argo CD a nostra applicazione averà u statutu "Fuori di sincronia" perchè ùn ci hè micca una etichetta chì ArgoCD furnisce.
Hè per quessa chì quandu avemu principiatu a sincronizazione un pocu più tardi, l'uggetti ùn saranu micca redistribuiti.

Avà femu una prova corsa per assicurà chì ùn ci sò micca errori in i nostri schedari.

argocd app sync simple-app --dry-run

Se ùn ci sò micca errori, pudete andà à a sincronizazione.

argocd app sync simple-app

Dopu avè eseguitu l'argocd get command in a nostra applicazione, duvemu vede chì u statutu di l'applicazione hè cambiatu in Sano o Synced. Questu significarà chì tutte e risorse in u repositoriu Git currispondenu avà à quelli risorse chì sò digià stati implementati.

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:        <none>
Sync Status:        Synced to master (60e1678)
Health Status:      Healthy
...

Avà pudete attivà a sincronia automatica è a pulizia per assicurà chì nunda ùn hè creatu manualmente è chì ogni volta chì un ughjettu hè creatu o aghjurnatu à u repository, una implementazione serà.

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

Dunque, avemu purtatu cun successu una applicazione sottu u cuntrollu di GitOps chì inizialmente ùn hà micca utilizatu GitOps in ogni modu.

Source: www.habr.com

Introduzione à GitOps per OpenShift