El terme DevOps fa referència a la cultura i conjunt de pràctiques que pretenen escurçar el cicle de vida de desenvolupament del software mitjançant l’acostament dels equips de desenvolupament i d’operacions, els qui tradicionalment treballaven aïlladament. DevOps té el seu origen en les metodologies àgils i es basa principalment en l’automatització de les tasques i el monitoratge constant d’aquestes. Arran de la seva aplicació en diferents àmbits, han anat sorgint altres conceptes semblants com MLOps, DevSecOps, DataOps, etc. Així, és raonable plantejar-se: És possible aplicar aquests principis a la gestió de la infraestructura?
La resposta és Sí. GitOps és una evolució de DevOps que consisteix en l’ús de repositoris de Git com a única font de veritat de l’estat de la infraestructura. Mitjançant l’ús de pràctiques i eines com a infraestructura com a codi (IaC) o pipelines de CI/CD, l’objectiu consisteix a aconseguir que l’estat del sistema descrit pel contingut dels fitxers del repositori coincideixi exactament amb el seu estat real. Algunes dels avantatges més destacats són:
- Automatització: El codi i configuracions que condueixen a l’estat actual es troben en un repositori accessible per l’equip de treball. En cas de fallada, és possible reproduir automàticament l’estat de la infraestructura.
- Transparència i visibilitat: El propi repositori de Git serveix com a documentació de l’estat del sistema. Qualsevol amb accés a aquest pot conèixer amb exactitud quines configuracions s’estan aplicant, ja que Git actua com a font única de veritat.
- Control de versions: Git, a l’ésser un sistema de control de versions, permet registrar cadascun dels canvis realitzats en la infraestructura, permetent realitzar rollbacks fàcilment en cas d’errors o conèixer el seu historial.
GitOps i Kubernetes
Un dels punts clau de Kubernetes és el seu caràcter declaratiu, és a dir, els recursos del clúster com poden ser els Pods, Deployments, Ingress, Service, etc. poden ser creats de manera declarativa mitjançant arxius yaml, anomenats manifests. Què passaria si s’elimina un Ingress? Si conservem la seva definició, n’hi ha prou amb tornar-ho a aplicar i Kubernetes s’encarregarà de fer els canvis corresponents. Però, i si fins i tot aquest procés es pogués arribar a automatitzar, de manera que el propi sistema fos capaç de detectar quins recursos falten i recrear-los?
El terme GitOps es va originar en aquest context, però encara falta per introduir un component, “el controlador”. El controlador és el software responsable de reconciliar l’estat del repositori amb l’estat del clúster. Per a això, el controlador ha de poder connectar-se al clúster, monitorar les definicions dels recursos existents i comparar-los amb aquells del repositori. Si el controlador detecta alguna diferència, aquest s’encarregarà de sincronitzar-los i aplicar les mesures necessàries per a solucionar-ho, incloent-hi tasques com la creació, eliminació i actualització de recursos.
Què és ArgoCD?
ArgoCD és una eina declarativa de desplegament continu (CD) que permet implementar GitOps en Kubernetes. ArgoCD consisteix en un controlador de Kubernetes que monitora contínuament les aplicacions que s’estan executant (estat actual) i les compara amb l’estat desitjat. Si aquests dos estats difereixen, ArgoCD marcarà l’aplicació com OutOfSync i oferirà la possibilitat de sincronitzar-la automàticament o manualment a través d’una interfície web o CLI.
Exemple pràctic: Modificant un Deployment
Suposem que volem gestionar un conjunt de recursos de Kubernetes amb GitOps, i per a això volem usar ArgoCD. Inicialment, s’ha de disposar d’un repositori de Git i un clúster de Kubernetes amb ArgoCD instal·lat. Existeixen diverses maneres d’instal·lar-ho (per exemple Helm). En aquest cas, s’assumeix que ArgoCD s’ha instal·lat en el mateix clúster de Kubernetes, encara que això no té per què sempre ser així.
Per a aquest exemple, es desplegarà el següent Deployment:
ArgoCD distingeix quins recursos ha de gestionar mitjançant Applications. Una Application és un Custom Resource (CR) propi de ArgoCD que conté informació sobre on trobar els manifests i on aplicar-los.
Amb aquesta aplicació, ArgoCD es configurarà de la següent manera:
- Estat desitjat: El directori manifests de la branca main del repositori de Git gitops-workshop.
- Estat actual: El contingut del namespace nginx del clúster de Kubernetes on es troba ArgoCD.
Nota: Les aplicacions també es poden crear des de la Web UI o la CLI. Tots dos mètodes acaben generant el mateix recurs.
Accedint a la interfície web de ArgoCD es podrà observar que s’ha creat l’aplicació nginx. Apareixerà com OutOfSync, ja que el deployment que hi ha en el repositori encara no existeix en el clúster. Per a solucionar-ho, cal clicar en el botó de Sync.
Si tot ha anat bé, uns instants després l’aplicació passarà a Synced, podent-se verificar com ArgoCD ha creat el recurs.
Per a il·lustrar el funcionament de ArgoCD, es pot modificar algun paràmetre del recurs. El següent comando redueix el nombre de rèpliques del deployment a 1:
$ kubectl scale deploy nginx-deployment –replicas=1 -n nginx
En executar-ho, veurem com l’aplicació torna de nou a estar OutOfSync. En clicar en la secció diff, podrem comprovar les diferències entre l’estat actual (esquerra) i l’estat desitjat (dreta).
Després de tornar a sincronitzar, ArgoCD restaurarà el nombre original de rèpliques, reconciliant així el clúster amb la informació del repositori de Git. En conseqüència, qualsevol canvi que es desitgi dur a terme ha d’estar registrat en el repositori de Git.
ArgoCD ofereix un ampli nombre de possibles configuracions, com per exemple la possibilitat d’ignorar canvis en camps específics d’alguns recursos, la selecció de diferents maneres de crear-los, la possibilitat de sincronitzar automàticament les aplicacions, etc. La seva documentació és detallada i conté informació sobre totes les seves funcionalitats.
Conclusió
Hem vist en què consisteix el paradigma GitOps i com es pot dur a terme per a gestionar clústers de Kubernetes mitjançant ArgoCD. No obstant això, la seva aplicació no està limitada únicament a aquest sector: A causa dels avantatges que ofereix GitOps, en els últims anys han sorgit altres solucions destinades a aplicar aquestes pràctiques en altres contextos, com és el desplegament d’infraestructura cloud amb Terraform. Actualment, GitOps és una realitat consolidada en molts sistemes IT i és un paradigma recomanat a l’hora d’iniciar un projecte d’aquestes característiques.