GitOps Es una filosofía para el desarrollo de aplicaciones que utiliza las mejores prácticas de DevOps ( control de versiones, colaboración, cumplimineto y las herramientas CI/CD)  para automatizar la infraestructura

En definitiva supone una automatización de la infraestructura, extendiendo el concepto y dando completitud, a partir de algo que ya está bastante maduro como es la automatización del desarrollo de software.

Componentes principales de GitOps

  • IaC. Infraestructura como código

Se considera a GIT como nucleo de información o fuente de la verdad de la infraestructura y toda la configuración de la infraestructura debe encontrarse en git.

  • Mergue o pull request.

Todos los cambios en la infraestructura deben gestionarse mediante pull o merge request(*).De esta forma la integración de un cambio en la infraestrucutra tendrán la garantia de los procesos colaborativos de revisión y comentarios y la consolidación en las ramas troncales estarán controladas.

(*) Se trata del mismo concepto. En plataformas como Bitbuket,GitHub…se denomina pull request mientras que GitLab lo denomina merge request.

  • CD/CI

GitOps automatiza las actualizaciones de infraestructura mediante un flujo de trabajo de Git con integración continua y entrega continua (CI / CD). Cuando se fusiona un nuevo código se consolida el cambio en el entorno. Cualquier cambio de configuración, como cambios manuales o errores, se sobrescribe mediante la automatización de GitOps para que el entorno llegue a el estado deseado definido en Git. La mayoría de los productos usan pipelines CI / CD para administrar e implementar la automatización de GitOps, pero también se pueden usar otras formas de automatización, como los operadores de definiciones.

 

GitOps se diferencia por focalizar en una experiencia centrada en el desarrollador. La gestión de la infraestructura a través de GitOps ocurre en el mismo sistema de control de versiones que el desarrollo de la aplicación, lo que permite a los equipos colaborar más en una ubicación central.

 

¿Cómo implementar GitOps?

 

Existen infinidad de productos y combinaciones de los mismos para implementar GitOps siendo el único invariante GIT como gestor del control de versiones y fuente de la verdad os indico en la siguiente tabla los elementos y operaciones y algunos productos con los que llevarlo a cabo…numerosas opciones, en el caso de GitLab de manera muy compacta y con respecto a las grandes plataformas GCP,AWS,Azure,Redhat con productos propios para cubrir todo el ciclo de GitOps.

 

Cluster de Kubernetes (Cloud, local,….) Google Cloud GKE, Amazon EKS, Azure, Openshift, Minikube, Minishift, Kind, K3S, K3D
Herramienta de gestión de Git (MR,PR,…) GitLab,GitHub,Bitbucket,AWS CodeCommit,Google cloud source repository,Azure Repos
Herramienta de CI GitLab CI, Jenkins, Bamboo, Circle, Travis, TeamCity, CodeShip,AWS CodePipeline,Google CloudBuild, Azure Pipelines
Herramienta de CD GitLab CD, Flux, Spinaker, Argo, AWS CodePipeline,Google CloudBuild, Azure Pipelines
Gestión de configuración Ansible,CHEF,puppet
Aprovisionamiento de infraestructura Terraform,Plumi,AWS CloudFormation

Veamos un ejemplo sencillo

Pasando a la práctica vamos a implementar GitOps de manera sencilla, utilizando lo siguiente

  • K3D como cluster kubernetes local
  • GitHub como Gestor de Git y pull request
  • Flux como Herramienta para CD

En el ejemplo vamos a omitir la Integración continua, porque el objetivo es hacer foco en la entrega continua mediante Flux, a continuación se enumera nuestra práctica.

  • Crear repositorio y configurar(Token de usuario) GitHub
  • Instalar Flux en nuestro cluster K3D
  • Comprobar que el namespace y pods de flux están corriendo
  • Comprobar que en nuestro repo se encuentre el namespace flux-system de manera automática
  • Os indico un para de pasos que voy a omitir para abreviar pero que es importante
    • Crearemos una issue y una rama feature. En dicha rama añadiremos un par de yaml uno para definir un namespace (gitops-atb) y el otro para un pod (a partir deuna imagen existente en Docker Hub…de un microservicio spring boot sencillo)
    • Integraremos en la rama principal mediante pull request
  • En vez de los pasos anteriores voy a añadir los yaml directamente sobre la rama develop de sincronización con el cluster develop…se trata de un atajo que rompe con la filosofia GitOps completamente ya que no realiza la colaboración en la integración mediante el pull request, pero por otro lado como yo mismo me integro a lo «juan palomo» pues me lo salto….pero en un contexto de trabajo si es muy importante la pull request, que por otro lado para obligar a este uso está la gestión de roles de usuario.
  • Observaremos que el despliegue en nuestro cluster del namespace y pod se ha realizado automáticamente desde la rama principal de GIT
  • Comprobaremos que el último commit es efectivamente el de la infraestructura desplegada

Partimos de un repo github vacio

Configuramos un token y los asignamos a la variable de entorno GITHUB_TOKEN. También debemos crear la varibale GITHUB_USER con el usuario de GitHub.

Necesitamos un cluster kubernetes en mi caso es K3D y también es necesario instalar Flux

Con el siguiente comando instalamos Flux en nuestro cluster

flux bootstrap github –owner=$GITHUB_USER –repository=gitops-atb –branch=develop –private=true –path=./clusters/develop

Le estamos indicando

  • El tipo de repositorio -> github
  • El usuario de github
  • El nombre del repo
  • la rama de sincronización. develop en nuestro caso
  • le indicamos que es un repo privado
  • Y el path que es clusters/develop con la idea de albergar un cluster por entorno….(una opción)

Y comentar que bootstrap es el comando que permite instalar los componentes de Flux en el cluster

Vemos que se han instalado los pods de flux en el namespace flux-system. Y vemos que flux bootstrap es idempotente…yo tenia flux previamente instalado con la nueva instalación ha establecido la nueva infraestructura pero a partir de ahí siempre la va a mantener mientras no existan cambios.

Me clono el repo en mi STS, añado el namespace gitops-atb y un pod (atb-istio-1) a partir de una imagen de un microservicio que tengo en Docker Hub y hago push……

¡¡¡Comprobamos como el pod atb-istio-1 se ha desplegado automáticamente en el namespace gitops-atb y está corriendo!!!

Esta web utiliza cookies propias para su correcto funcionamiento. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad