¿GitOps es la próxima gran innovación en DevOps?
Muchas organizaciones ahora ven DevOps como parte de su estrategia de transformación digital, ya que fomenta una cultura de responsabilidad compartida, transparencia y comentarios más rápidos. Sin embargo, a medida que se reduce la brecha entre los equipos de desarrollo y operaciones, también lo hacen los procesos.
Lo mismo ocurre con Git, el sistema de control de versiones más utilizado actualmente en el mundo. A medida que las empresas adoptan las metodologías de DevOps, también lo hacen las herramientas, lo que ha dado pie a una evolución hacia GitOps, un conjunto de prácticas que permiten a los desarrolladores realizar más tareas relacionadas con las operaciones de TI.
¿Qué es GitOps?
En esencia, GitOps es una infraestructura basada en código y procedimientos operativos que utilizan Git como sistema de control de código fuente. Es una evolución de la infraestructura como código (IaC) y una práctica recomendada de DevOps que aprovecha Git como la única fuente de información y el mecanismo de control para crear, actualizar y eliminar arquitectura del sistema. Dicho de otro modo, es la práctica de usar solicitudes de incorporación de cambios de Git para verificar e implementar automáticamente modificaciones en la infraestructura del sistema.
Además de Git como mecanismo clave de DevOps, también se usa GitOps para describir herramientas que aumentan la funcionalidad predeterminada de Git. Estas herramientas se utilizaron principalmente con modelos operativos para la infraestructura y las aplicaciones basadas en Kubernetes. Hay un desarrollo y un debate continuos en la comunidad de DevOps para incorporar las herramientas de GitOps en otras plataformas distintas de Kubernetes, como Terraform.
GitOps garantiza que la infraestructura en la nube de un sistema se pueda reproducir de inmediato en función del estado de un repositorio de Git. Las solicitudes de incorporación de cambios modifican el estado del repositorio de Git. Una vez aprobadas y fusionadas, las solicitudes de incorporación de cambios volverán a configurar y sincronizarán automáticamente la infraestructura en vivo con el estado del repositorio. Este flujo de trabajo de solicitud de incorporación de cambios de sincronización en vivo es la esencia fundamental de GitOps.
Material relacionado
Chuleta de Git
VER LA SOLUCIÓN
Aprende a usar Git con Bitbucket Cloud
La historia de GitOps
Git es una herramienta esencial para el desarrollo de software que permite flujos de trabajo de solicitud de incorporación de cambios y revisión de código. Las solicitudes de incorporación de cambios promueven la visibilidad de los cambios entrantes en un código base y fomentan la comunicación, el debate y la revisión de los cambios.
Las solicitudes de incorporación de cambios son una función fundamental en el desarrollo de software colaborativo y cambiaron la forma en que los equipos y las empresas compilan software. Dichas solicitudes aportan transparencia y capacidad de medición a un proceso que antes era opaco. Las solicitudes de incorporación de cambios de Git contribuyeron a que los procesos de DevOps evolucionaran hacia el desarrollo de software. Los administradores de sistemas, que solían ser reticentes al cambio, ahora están adoptando nuevas prácticas de desarrollo de software, como la metodología ágil y DevOps.
La administración de sistemas como oficio tiene una historia desordenada. Antes, los administradores de sistemas gestionaban el hardware manualmente conectándose a máquinas y aprovisionándolas en un bastidor de servidores físicos o a través de una API de aprovisionamiento en la nube. Además del proceso de aprovisionamiento manual, había que hacer una gran cantidad de trabajo de configuración manual como rutina habitual. Los administradores mantenían colecciones personalizadas de configuraciones y scripts imperativos, los juntaban y los colocaban en varios lugares. Estos scripts podían dejar de funcionar en cualquier momento o perderse. La colaboración era un desafío, ya que las cadenas de herramientas personalizadas no se documentaban ni se compartían habitualmente.
El movimiento DevOps surgió de este pantano primordial de administración de sistemas. DevOps tomó prestadas las mejores ideas de la ingeniería de software y las aplicó a la administración de sistemas, en la que las herramientas combinadas se convirtieron en código controlado por versiones.
La infraestructura como código (IaC) es una de las mayores revelaciones de DevOps. Anteriormente, los administradores de sistemas preferían los scripts imperativos personalizados para configurar los sistemas. El software imperativo sigue una secuencia de pasos para lograr un estado deseado, tales como:
El software imperativo suele ser propenso a errores y es fácil que deje de funcionar al cambiar la secuencia de eventos. El desarrollo de software moderno ha tendido a alejarse de los patrones imperativos para acercarse a los patrones de software declarativos.
El software declarativo sigue una declaración de un estado esperado en lugar de una secuencia de comandos. A continuación se muestra una comparación de declaraciones de DevOps imperativas y declarativas.
Mientras que las declaraciones imperativas pueden indicar lo siguiente:
- Instala un sistema operativo en esta máquina
- Instala estas dependencias
- Descarga el código de esta URL
- Mueve el código a este directorio
- Haz esto 3 veces para otras 3 máquinas
La versión declarativa de esto simplemente indicaría: 4 máquinas tienen software de esta URL instalado en este directorio.
La IaC fomenta y promueve herramientas declarativas de administración de sistemas por encima de soluciones imperativas personalizadas. Esto dio lugar a la aparición de tecnologías como Docker Containers, Ansible, Terraform y Kubernetes, que utilizan archivos de configuración declarativos estáticos. La legibilidad humana y el estado reproducible constante son resultados beneficiosos. Estos archivos de configuración se añadieron de manera natural a Git para seguimiento y revisión. GitOps funciona de manera parecida pero no así exactamente.
Muchos de los problemas tradicionales de administración de sistemas se han resuelto a estas alturas en la historia de DevOps. Los archivos y las herramientas de configuración ahora se almacenan en una ubicación central, están documentados y son accesibles para muchos miembros del equipo. Las confirmaciones y las solicitudes de incorporación de cambios se usaron para realizar un seguimiento de las modificaciones en la configuración y fomentar el debate sobre la colaboración y la revisión. El único problema que queda en esta etapa es que la configuración aún se percibe como desconectada del sistema en vivo. Una vez que se aprueba una solicitud de incorporación de cambios de configuración y se fusiona en el repositorio, el sistema en vivo se actualiza manualmente para que coincida con el estado del repositorio estático. Este es el problema exacto que resuelve GitOps.
La idea de GitOps la tramó y compartió por primera vez WeaveWorks, una empresa de gestión empresarial de Kubernetes, y desde entonces ha proliferado en toda la comunidad de DevOps. GitOps es una extensión de la IaC y la configuración declarativa analizada más arriba. GitOps aporta algo de magia al flujo de trabajo de solicitud de incorporación de cambios que sincroniza el estado del sistema en vivo con el del repositorio de configuración estática.
Ventajas de GitOps
GitOps comparte muchas de las mismas ventajas que un flujo de trabajo de desarrollo de software de rama de función ágil. La principal ventaja es la facilidad de adopción debido al uso de herramientas comunes. Git es el estándar de facto de los sistemas de control de versiones y es una herramienta de desarrollo de software común para la mayoría de los desarrolladores y equipos de software. Esto facilita que los desarrolladores familiarizados con Git se conviertan en colaboradores multifuncionales y participen en GitOps.
El uso de un sistema de control de versiones permite a un equipo realizar un seguimiento de todas las modificaciones en la configuración de un sistema. Esto proporciona una "fuente de información" y un registro de auditoría valioso para revisar si algo deja de funcionar o tiene un comportamiento inesperado. Los equipos pueden revisar el historial de GitOps y ver cuándo se introdujo una regresión. Además, el registro de auditoría se puede utilizar como referencia para auditorías de cumplimiento normativo o seguridad. El historial de GitOps se puede utilizar como prueba cuando se modifican o actualizan elementos como los certificados de cifrado.
GitOps aporta transparencia y claridad a la infraestructura de una organización con un repositorio central. El hecho de incluir todas las configuraciones de sistemas en un repositorio central ayuda a escalar la contribución de los miembros del equipo. Las solicitudes de incorporación de cambios que se realizan a través de servicios de Git alojados, como Bitbucket, cuentan con herramientas eficaces para revisar el código y comentar debates. Esto crea bucles de comunicación pasivos que permiten que todo el equipo de ingeniería pueda observar y supervisar los cambios en la infraestructura.
GitOps puede aumentar considerablemente la productividad de un equipo de DevOps. Además, le permite experimentar rápidamente con nuevas configuraciones de infraestructura. Si los nuevos cambios no tienen el comportamiento esperado, un equipo puede usar el historial de Git para revertir los cambios a un estado óptimo conocido. Esto es muy efectivo, ya que habilita la conocida funcionalidad de "deshacer" en una infraestructura complicada.
Cómo funciona GitOps
Los procedimientos de GitOps se llevan a cabo mediante un sistema de orquestación subyacente. GitOps en sí mismo es un patrón agnóstico de prácticas recomendadas. En la actualidad, muchas soluciones de GitOps populares utilizan principalmente Kubernetes como sistema de orquestación. Están apareciendo en el mercado conjuntos de herramientas de GitOps alternativos que admiten la manipulación directa de Terraform.
Para lograr una instalación completa de GitOps, se requiere una plataforma de canalización. Jenkins, Bitbucket Pipelines o CircleCI son algunas herramientas de canalización populares que se complementan con GitOps. Las canalizaciones automatizan y cierran la brecha entre las solicitudes de incorporación de cambios de Git y el sistema de orquestación. Una vez que los hooks de canalización se han establecido y activado a partir de las solicitudes de incorporación de cambios, los comandos se ejecutan en la parte de orquestación.
Un nuevo patrón o componente que se introduce específicamente con GitOps es el "operador" de GitOps, que consiste en un mecanismo que se encuentra entre la canalización y el sistema de orquestación. Una solicitud de incorporación de cambios inicia la canalización que luego activa el operador. El operador examina el estado del repositorio y el inicio de la orquestación, y los sincroniza. El operador es el componente mágico de GitOps.
Ejemplos de GitOps
Imagina que un equipo identifica un cuello de botella en el rendimiento o un aumento en el tráfico, y el equipo nota que el equilibrador de carga no funciona según lo esperado. El equipo examina el repositorio de GitOps que contiene la configuración de la infraestructura y encuentra un archivo específico que configura e implementa el equilibrador de carga. Puede revisarlo en su sitio de alojamiento de Git en línea. Después de algunas revisiones y conversaciones, el equipo detecta que algunos de los valores de configuración del equilibrador de carga no son óptimos y deben ajustarse.
Un miembro del equipo inicia una nueva solicitud de incorporación de cambios que optimiza los valores del equilibrador de carga. Un segundo miembro del equipo revisa y aprueba dicha solicitud y la fusiona en el repositorio. La fusión inicia una canalización de GitOps que activa el operador de GitOps. El operador detecta que se ha cambiado la configuración del equilibrador de carga y confirma con la herramienta de orquestación de sistemas que esto no coincide con lo que está en vivo en el clúster del equipo.
El operador indica al sistema de orquestación que actualice la configuración del equilibrador de carga. El orquestador se encarga del resto e implementa automáticamente el equilibrador de carga recién configurado. Luego, el equipo supervisa el sistema en vivo recién actualizado para ver si vuelve a un estado correcto. Se trata de una situación ideal de GitOps. Vamos a ampliar más la idea para hacer una demostración de la utilidad de GitOps.
Imaginemos que en lugar de ajustar ligeramente los valores del equilibrador de carga para que sean óptimos, el equipo toma la decisión agresiva de implementar un tipo de equilibrador de carga completamente nuevo. El equipo siente que el equilibrador de carga actual tiene fallos fundamentales y quiere probar una opción alternativa. El flujo de trabajo es el mismo que el ajuste del valor. El equipo crea una solicitud de incorporación de cambios que introduce una configuración de equilibrador de carga completamente nueva y elimina la configuración anterior. Después, esto se aprueba y se implementa a través de la canalización.
Lamentablemente, el equipo descubre que este nuevo tipo de equilibrador de carga no es compatible con otros servicios de su clúster. El nuevo equilibrador de carga provoca fallos de tráfico críticos y detiene las operaciones de los usuarios. Afortunadamente, dado que el equipo dispone de una canalización completa de GitOps, puede deshacer rápidamente estos cambios en el equilibrador de carga. El equipo realizará otra solicitud de incorporación de cambios que revierta el repositorio al anterior equilibrador de carga funcional conocido. De nuevo, esta operación la advertirá GitOps y se implementará automáticamente. Esto mejorará rápidamente la infraestructura y la puntuación de fiabilidad del equipo.
Resumen
GitOps es un patrón de flujo de trabajo muy potente que permite gestionar la infraestructura moderna en la nube. Aunque se centra principalmente en la gestión de clústeres de Kubernetes, la comunidad de DevOps aplica y publica soluciones de GitOps en otros sistemas distintos de Kubernetes. GitOps puede aportar muchas ventajas a un equipo de ingeniería, como la mejora de la comunicación, la visibilidad, la estabilidad y la fiabilidad del sistema. Uno de los requisitos principales para tener una buena experiencia de GitOps es disponer de una plataforma Git alojada moderna, como Bitbucket.
Compartir este artículo
Tema siguiente
Lecturas recomendadas
Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.
Blog de Bitbucket
Ruta de aprendizaje de DevOps
