🥇Introducció a GitOps per a OpenShift

Avui parlarem dels principis i models de GitOps, així com de com s'implementen aquests models a la plataforma OpenShift. Hi ha disponible una guia interactiva sobre aquest tema по ссылке.

En poques paraules, GitOps és un conjunt de pràctiques per utilitzar sol·licituds d'extracció de Git per gestionar la infraestructura i les configuracions d'aplicacions. El dipòsit de Git a GitOps es tracta com una única font d'informació sobre l'estat del sistema, i qualsevol canvi en aquest estat és totalment rastrejable i auditable.

La idea del seguiment de canvis a GitOps no és gens nova; aquest enfocament s'ha utilitzat durant molt de temps gairebé universalment quan es treballa amb el codi font de l'aplicació. GitOps simplement implementa funcions similars (revisions, sol·licituds d'extracció, etiquetes, etc.) en la gestió de la configuració d'aplicacions i d'infraestructures i ofereix avantatges similars com en el cas de la gestió del codi font.

No hi ha cap definició acadèmica ni un conjunt de regles aprovades per a GitOps, només un conjunt de principis sobre els quals es basa aquesta pràctica:

La descripció declarativa del sistema s'emmagatzema al repositori Git (configuracions, seguiment, etc.).
Els canvis d'estat es fan mitjançant sol·licituds d'extracció.
L'estat dels sistemes en execució s'ajusta a les dades del dipòsit mitjançant sol·licituds push de Git.

Principis de GitOps

Les definicions del sistema es descriuen com a codi font

La configuració dels sistemes es tracta com a codi perquè es pugui emmagatzemar i versionar automàticament en un repositori Git, que serveix com a font única de veritat. Aquest enfocament fa que sigui fàcil de desplegar i revertir els canvis als sistemes.

L'estat i la configuració desitjats dels sistemes s'estableixen i versionen a Git

En emmagatzemar i versionar l'estat desitjat dels sistemes a Git, podem implementar i revertir fàcilment els canvis als sistemes i aplicacions. També podem utilitzar els mecanismes de seguretat de Git per controlar la propietat del codi i verificar-ne l'autenticitat.

Els canvis de configuració es poden aplicar automàticament mitjançant sol·licituds d'extracció

Mitjançant les sol·licituds d'extracció de Git, podem controlar fàcilment com s'apliquen els canvis a les configuracions del repositori. Per exemple, es poden lliurar a altres membres de l'equip perquè les revisin o es realitzin proves de CI, etc.

I, al mateix temps, no cal distribuir els poders d'administració a dreta i esquerra. Per confirmar canvis de configuració, els usuaris només necessiten els permisos adequats al dipòsit de Git on s'emmagatzemen aquestes configuracions.

Solucionant el problema de la deriva incontrolada de configuracions

Un cop l'estat desitjat del sistema s'emmagatzema en un repositori Git, tot el que hem de fer és trobar un programari que garanteixi que l'estat actual del sistema coincideixi amb l'estat desitjat. Si no és així, aquest programari hauria d'eliminar la discrepància per si mateix, o bé notificar-nos sobre la deriva de la configuració.

Models GitOps per a OpenShift

Reconciliador de recursos al clúster

Segons aquest model, el clúster té un controlador que s'encarrega de comparar els recursos de Kubernetes (fitxers YAML) al repositori Git amb els recursos reals del clúster. Si es detecten discrepàncies, el controlador envia notificacions i possiblement pren mesures per corregir-les. Aquest model GitOps s'utilitza a Anthos Config Management i Weaveworks Flux.

Reconciliador de recursos externs (Push)

Aquest model es pot considerar com una variació de l'anterior, quan disposem d'un o més controladors encarregats de sincronitzar recursos en els parells “Repositori Git - clúster Kubernetes”. La diferència aquí és que cada clúster gestionat no té necessàriament el seu propi controlador independent. Els parells de clúster Git - k8s sovint es defineixen com a CRD (definicions de recursos personalitzades), que poden descriure com el controlador hauria de realitzar la sincronització. Dins d'aquest model, els controladors comparen el dipòsit de Git especificat al CRD amb els recursos del clúster de Kubernetes, que també s'especifiquen al CRD, i realitzen les accions adequades en funció dels resultats de la comparació. En particular, aquest model GitOps s'utilitza a ArgoCD.

GitOps a la plataforma OpenShift

Administració de la infraestructura de Kubernetes multiclúster

Amb la difusió de Kubernetes i la creixent popularitat de les estratègies multinúvol i la informàtica de punta, el nombre mitjà de clústers OpenShift per client també augmenta.

Per exemple, quan s'utilitza la informàtica de punta, els clústers d'un client es poden desplegar en centenars o fins i tot milers. Com a resultat, es veu obligat a gestionar diversos clústers OpenShift independents o coordinats al núvol públic i on-premise.

En aquest cas, s'han de resoldre molts problemes, en particular:

Controla que els clústers es trobin en un estat idèntic (configuracions, supervisió, emmagatzematge, etc.)
Recrea (o restaura) clústers basats en un estat conegut.
Creeu nous clústers basats en un estat conegut.
Desplegueu els canvis a diversos clústers d'OpenShift.
Feu retrocedir els canvis en diversos clústers d'OpenShift.
Enllaceu configuracions de plantilles a diferents entorns.

Configuracions d'aplicacions

Durant el seu cicle de vida, les aplicacions sovint passen per una cadena de clústers (dev, stage, etc.) abans d'acabar en un clúster de producció. A més, a causa dels requisits de disponibilitat i escalabilitat, els clients solen desplegar aplicacions en diversos clústers locals o en diverses regions d'una plataforma de núvol públic.

En aquest cas, s'han de resoldre les tasques següents:

Assegureu-vos el moviment d'aplicacions (binaris, configuracions, etc.) entre clústers (dev, stage, etc.).
Desplegueu els canvis a les aplicacions (binaris, configuracions, etc.) en diversos clústers d'OpenShift.
Retrocedeix els canvis a les aplicacions a un estat conegut anterior.

Casos d'ús d'OpenShift GitOps

1. Aplicant canvis des del repositori Git

Un administrador de clúster pot emmagatzemar configuracions de clúster d'OpenShift en un dipòsit de Git i aplicar-les automàticament per crear nous clústers sense esforç i portar-los a un estat idèntic a l'estat conegut emmagatzemat al dipòsit de Git.

2. Sincronització amb Secret Manager

L'administrador també es beneficiarà de la possibilitat de sincronitzar objectes secrets d'OpenShift amb el programari adequat com Vault per gestionar-los mitjançant eines creades especialment per a això.

3. Control de configuracions de deriva

L'administrador només estarà a favor si el mateix OpenShift GitOps identifica i avisa sobre discrepàncies entre les configuracions reals i les especificades al repositori, de manera que puguin respondre ràpidament a la deriva.

4. Notificacions sobre la deriva de la configuració

Són útils en el cas que l'administrador vulgui conèixer ràpidament els casos de deriva de la configuració per prendre ràpidament les mesures adequades per si mateix.

5. Sincronització manual de configuracions en deriva

Permet a l'administrador sincronitzar el clúster OpenShift amb el dipòsit de Git en cas de deriva de la configuració, per tornar ràpidament el clúster a un estat conegut anterior.

6.Autosincronització de configuracions en deriva

L'administrador també pot configurar el clúster d'OpenShift perquè es sincronitzi automàticament amb el dipòsit quan es detecti una deriva, de manera que la configuració del clúster sempre coincideixi amb les configuracions de Git.

7. Diversos clústers - un dipòsit

L'administrador pot emmagatzemar configuracions de diversos clústers d'OpenShift diferents en un dipòsit de Git i aplicar-los de manera selectiva segons sigui necessari.

8. Jerarquia de configuracions de clúster (herència)

L'administrador pot establir una jerarquia de configuracions de clúster al repositori (etapa, producte, cartera d'aplicacions, etc. amb herència). En altres paraules, pot determinar si les configuracions s'han d'aplicar a un o més clústers.

Per exemple, si un administrador estableix la jerarquia "Clústers de producció (prod) → Clústers del sistema X → Clústers de producció del sistema X" al repositori Git, s'aplicarà una combinació de les configuracions següents als clústers de producció del sistema X:

Configuracions comunes a tots els clústers de producció.
Configuracions per al clúster System X.
Configuracions per al clúster de producció del sistema X.

9. Plantilles i substitucions de configuració

L'administrador pot anul·lar un conjunt de configuracions heretades i els seus valors, per exemple, per ajustar la configuració dels clústers específics als quals s'aplicaran.

10. Inclou i exclou selectivament per a configuracions, configuracions d'aplicacions

L'administrador pot establir les condicions per a l'aplicació o no aplicació de determinades configuracions a clústers amb determinades característiques.

11. Suport de plantilles

Els desenvolupadors es beneficiaran de la possibilitat de triar com es definiran els recursos de l'aplicació (Helm Chart, pur Kubernetes yaml, etc.) per tal d'utilitzar el format més adequat per a cada aplicació concreta.

Eines GitOps a la plataforma OpenShift

ArgoCD

ArgoCD implementa el model de conciliació de recursos externs i ofereix una interfície d'usuari centralitzada per orquestrar relacions d'un a molts entre clústers i repositoris Git. Els desavantatges d'aquest programa inclouen la incapacitat de gestionar aplicacions quan ArgoCD no funciona.

Lloc web oficial

Flux

Flux implementa un model de reconciliació de recursos al clúster i, com a resultat, no hi ha una gestió centralitzada del repositori de definicions, que és un punt feble. D'altra banda, precisament a causa de la manca de centralització, la capacitat de gestionar les aplicacions es manté encara que falli un clúster.

Lloc web oficial

Instal·lant ArgoCD a OpenShift

ArgoCD ofereix una excel·lent interfície de línia d'ordres i una consola web, de manera que no tractarem Flux i altres alternatives aquí.

Per implementar ArgoCD a la plataforma OpenShift 4, seguiu aquests passos com a administrador del clúster:

Desplegant components ArgoCD a la plataforma 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}')

Millora del servidor ArgoCD perquè pugui ser vist per 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

Desplegant l'eina 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

Canviar la contrasenya d'administrador del servidor 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

Després de completar aquests passos, podeu treballar amb ArgoCD Server mitjançant la consola web ArgoCD WebUI o l'eina de línia d'ordres ArgoCD Cli.
https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

GitOps: mai és massa tard

"El tren ha marxat": això és el que diuen sobre una situació en què es perd l'oportunitat de fer alguna cosa. En el cas d'OpenShift, el desig de començar a utilitzar immediatament aquesta nova plataforma genial sovint crea exactament aquesta situació amb la gestió i el manteniment de rutes, desplegaments i altres objectes OpenShift. Però l'oportunitat sempre es perd completament?

Continuant la sèrie d'articles sobre GitOps, avui us mostrarem com transformar una aplicació artesanal i els seus recursos en un procés on tot sigui gestionat per eines GitOps. Per fer-ho, primer desplegarem manualment l'aplicació httpd. La captura de pantalla següent mostra com creem un espai de noms, un desplegament i un servei, i després exposem aquest servei per crear una ruta.

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

Així que tenim una aplicació artesanal. Ara s'ha de transferir sota la gestió de GitOps sense pèrdua de disponibilitat. En resum, fa això:

Creeu un repositori Git per al codi.
Exportem els nostres objectes actuals i els pengem al repositori Git.
Selecció i implementació d'eines GitOps.
Afegim el nostre repositori a aquest conjunt d'eines.
Definim l'aplicació al nostre conjunt d'eines GitOps.
Realitzem una prova d'execució de l'aplicació mitjançant el conjunt d'eines GitOps.
Sincronitzem objectes mitjançant el conjunt d'eines GitOps.
Habiliteu la poda i la sincronització automàtica d'objectes.

Com s'ha dit a l'anterior article, a GitOps hi ha una i només una font d'informació sobre tots els objectes dels clústers de Kubernetes: el dipòsit de Git. A continuació, partim de la premissa que la vostra organització ja utilitza un repositori Git. Pot ser públic o privat, però ha de ser accessible als clústers de Kubernetes. Aquest pot ser el mateix dipòsit que el codi de l'aplicació o un repositori separat creat específicament per als desplegaments. Es recomana tenir permisos estrictes al dipòsit, ja que hi emmagatzemaran secrets, rutes i altres coses sensibles a la seguretat.

En el nostre exemple, crearem un nou repositori públic a GitHub. Podeu anomenar-lo com vulgueu, utilitzem el nom de blogpost.

Si els fitxers d'objectes YAML no s'emmagatzemaven localment ni a Git, haureu d'utilitzar els binaris oc o kubectl. A la captura de pantalla següent estem sol·licitant YAML per al nostre espai de noms, desplegament, servei i ruta. Abans d'això, vam clonar-hi el dipòsit i el cd acabat de crear.

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

Ara editem el fitxer deployment.yaml per eliminar el camp que Argo CD no pot sincronitzar.

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

A més, cal canviar el recorregut. Primer establirem una variable multilínia i després substituirem l'entrada: null amb el contingut d'aquesta variable.

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

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

Per tant, hem ordenat els fitxers, només queda desar-los al repositori Git. Després d'això, aquest dipòsit es converteix en l'única font d'informació i qualsevol canvi manual als objectes s'hauria de prohibir estrictament.

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

A més partim del fet que ja heu desplegat ArgoCD (com fer-ho - vegeu l'anterior publicar). Per tant, afegirem al CD Argo el repositori que hem creat, que conté el codi de l'aplicació del nostre exemple. Només assegureu-vos d'especificar el repositori exacte que heu creat anteriorment.

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

Ara creem l'aplicació. L'aplicació estableix valors perquè el conjunt d'eines GitOps entengui quin dipòsit i camins s'ha d'utilitzar, quin OpenShift es necessita per gestionar els objectes, quina branca específica del dipòsit es necessita i si els recursos s'han de sincronitzar automàticament.

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

Un cop especificada una aplicació al CD d'Argo, el conjunt d'eines comença a comprovar els objectes ja desplegats amb les definicions del dipòsit. Al nostre exemple, la sincronització automàtica i la neteja estan desactivades, de manera que els elements encara no canvien. Tingueu en compte que a la interfície del CD de l'Argo la nostra aplicació tindrà l'estat "Fora de sincronització" perquè ArgoCD no ofereix cap etiqueta.
És per això que quan comencem la sincronització una mica més tard, els objectes no es tornaran a desplegar.

Ara fem una prova per assegurar-nos que no hi ha errors als nostres fitxers.

argocd app sync simple-app --dry-run

Si no hi ha errors, podeu procedir a la sincronització.

argocd app sync simple-app

Després d'executar l'ordre argocd get a la nostra aplicació, hauríem de veure que l'estat de l'aplicació ha canviat a Sana o sincronitzada. Això significarà que tots els recursos del repositori Git corresponen ara als recursos que ja s'han desplegat.

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
...

Ara podeu habilitar la sincronització i la neteja automàtica per assegurar-vos que no es creï res manualment i que cada vegada que es creï o actualitzeu un objecte al dipòsit, es produeixi un desplegament.

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

Per tant, hem posat amb èxit una aplicació sota el control de GitOps que inicialment no utilitzava GitOps de cap manera.

Font: www.habr.com

Introducció a GitOps per a OpenShift