• Autor de la entrada:
  • Tiempo de lectura:19 minutos de lectura

GitOps es un marco operativo que toma las mejores prácticas de DevOps utilizadas para el desarrollo de aplicaciones, como el control de versiones, la colaboración, el cumplimiento y las herramientas de CI/CD y las aplica a la automatización de la infraestructura.

Si bien el ciclo de vida del desarrollo de software se ha automatizado, la infraestructura sigue siendo un proceso mayormente manual que requiere equipos especializados.

Con las demandas de la infraestructura actual, se ha vuelto cada vez más crucial implementar la automatización de la infraestructura.

La infraestructura moderna debe ser elástica para que pueda administrar de manera efectiva los recursos de la nube que se necesitan para las implementaciones continuas.

Las aplicaciones modernas se desarrollan teniendo en cuenta la velocidad y la escala. Las organizaciones con una cultura DevOps madura pueden implementar código en producción cientos de veces al día.

Los equipos de DevOps pueden lograr esto a través de las mejores prácticas de desarrollo, como el control de versiones, la revisión de código y las canalizaciones de CI/CD que automatizan las pruebas y las implementaciones.

GitOps se utiliza para automatizar el proceso de aprovisionamiento de infraestructura. De manera similar a cómo los equipos usan el código fuente de la aplicación, los equipos de operaciones que adoptan GitOps usan archivos de configuración almacenados como código (infraestructura como código).

Los archivos de configuración de GitOps generan el mismo entorno de infraestructura cada vez que se implementa, al igual que el código fuente de la aplicación genera los mismos archivos binarios de la aplicación cada vez que se crea.

¿Cómo funciona GitOps?

GitOps organiza el proceso de implementación en torno a repositorios de código como elemento central. Hay al menos dos repositorios: El repositorio de aplicaciones y el repositorio de configuración del entorno.

El repositorio de aplicaciones contiene el código fuente de la aplicación y los manifiestos de implementación para implementar la aplicación.

El repositorio de configuración del entorno contiene todos los manifiestos de implementación de la infraestructura deseada actualmente de un entorno de implementación.

Describe qué aplicaciones y servicios de infraestructura (agente de mensajes, red de servicios, herramienta de supervisión, etc.) deben ejecutarse con qué configuración y versión en el entorno de implementación.

Existen dos formas de implementar la estrategia de implementación para GitOps: Implementaciones basadas en inserción e implementaciones basadas en extracción (inserción=push / extracción=pull).

La diferencia entre los dos tipos de implementación es cómo se garantiza que el entorno de implementación realmente se asemeje a la infraestructura deseada.

Cuando sea posible, se debe preferir el enfoque basado en extracción, ya que se considera la práctica más segura y por lo tanto, la mejor para implementar GitOps.

Implementaciones basadas en push o inserción

La estrategia de implementación basada en Push se implementa mediante herramientas populares de CI/CD como Jenkins , CircleCI o Travis CI, entre otros muchos.

El código fuente de la aplicación vive dentro del repositorio de la aplicación junto con los YAML de Kubernetes necesarios para implementar la aplicación.

Cada vez que se actualiza el código de la aplicación, se activa la canalización de compilación que crea las imágenes del contenedor y finalmente, el repositorio de configuración del entorno se actualiza con nuevos descriptores de implementación.

Además, se pueden almacenar plantillas de YAML en el repositorio de la aplicación para que cuando se cree una nueva versión, la plantilla se puede usar para generar el YAML dentro del repositorio de configuración del entorno.

Los cambios en el repositorio de configuración del entorno desencadenan la canalización de implementación.

Esta canalización es responsable de aplicar todos los manifiestos en el repositorio de configuración del entorno a la infraestructura. Con este enfoque, es indispensable proporcionar credenciales al entorno de implementación.

Entonces, la canalización tiene el modo dios habilitado.

En algunos casos de uso, una implementación basada en Push es inevitable cuando se ejecuta un aprovisionamiento automatizado de infraestructura en la nube.

En tales casos, se recomienda enfáticamente utilizar el sistema de autorización configurable granular fino del proveedor de la nube para obtener permisos de implementación más restrictivos.

Otra cosa importante a tener en cuenta al usar este enfoque es que la canalización de implementación solo se activa cuando cambia el repositorio del entorno.

Esto significa que necesitas alguna forma de monitoreo, de modo que uno pueda intervenir si el entorno no coincide con lo que se describe en el repositorio del entorno.

Implementaciones basadas en pull o extracción

La estrategia de implementación basada en extracción utiliza los mismos conceptos que la variante basada en inserción, pero difiere en cómo funciona la canalización de implementación.

Las canalizaciones de CI/CD tradicionales se desencadenan por un evento externo, por ejemplo, cuando se envía código nuevo a un repositorio de aplicaciones. Con el enfoque de implementación basado en extracción, se presenta al operador.

Asume el rol de canalización al comparar continuamente el estado deseado en el repositorio del entorno con el estado real en la infraestructura implementada.

Cada vez que se notan diferencias, el operador actualiza la infraestructura para que coincida con el repositorio del entorno. Además, el registro de imágenes se puede monitorear para encontrar nuevas versiones de imágenes para implementar.

Al igual que la implementación basada en inserción, esta variante actualiza el entorno cada vez que cambia el repositorio del entorno. Sin embargo, con el operador también se pueden notar cambios en el otro sentido.

Cada vez que la infraestructura implementada cambia de alguna manera no descrita en el repositorio del entorno, estos cambios se revierten. Esto garantiza que todos los cambios se puedan rastrear en el registro de Git, al hacer que todos los cambios directos en el clúster sean imposibles.

Este cambio de dirección resuelve el problema de las implementaciones basadas en inserción, en las que el entorno solo se actualiza cuando se actualiza el repositorio del entorno.

Sin embargo, esto no significa que pueda prescindir por completo de ningún tipo de supervisión.

La mayoría de los operadores admiten el envío de correos electrónicos o notificaciones de Slack si no puede llevar el entorno al estado deseado por algún motivo, por ejemplo, si no puede extraer una imagen de contenedor.

Además, probablemente deba configurar el monitoreo para el propio operador, ya que sin él ya no hay ningún proceso de implementación automatizado.

El operador siempre debe vivir en el mismo entorno o clúster que la aplicación a implementar. Esto evita el modo dios, visto con el enfoque basado en inserción, donde la canalización de CI/CD conoce las credenciales para realizar implementaciones.

Cuando la instancia de implementación real vive dentro del mismo entorno, los servicios externos no necesitan conocer las credenciales.

El mecanismo de Autorización de la plataforma de implementación en uso se puede utilizar para restringir los permisos para realizar implementaciones.

Esto tiene un gran impacto en términos de seguridad. Al usar Kubernetes, se pueden utilizar las configuraciones de RBAC y las cuentas de servicio.

¿Cómo trabajar con múltiples aplicaciones y entornos?

Por supuesto, el trabajar con un solo repositorio de aplicaciones y un solo entorno no es realista para la mayoría de las aplicaciones. Cuando utilizas una arquitectura de microservicios, probablemente desees mantener cada servicio en su propio repositorio.

GitOps también puede manejar este caso de uso. Siempre puedes configurar varias canalizaciones de compilación que actualicen el repositorio del entorno.

A partir de ahí, el flujo de trabajo regular automatizado de GitOps se activa e implementa todas las partes de su aplicación.

La administración de múltiples entornos con GitOps se puede realizar simplemente usando ramas separadas en el repositorio del entorno.

Puedes configurar el operador o la canalización de implementación para que reaccione a los cambios en una rama mediante la implementación en el entorno de producción y otra para la implementación en el ensayo.

¿Cómo ponen en práctica GitOps los equipos?

GitOps no es un solo producto, complemento o plataforma. No existe una respuesta única para esta pregunta, ya que la mejor manera para que los equipos pongan en práctica GitOps variará según las necesidades y los objetivos específicos del equipo.

Sin embargo, algunos consejos sobre cómo comenzar con GitOps incluyen el uso de un repositorio de GitOps dedicado para que todos los miembros del equipo compartan configuraciones y códigos, automatizar la implementación de cambios de código y configurar alertas para notificar al equipo cuando se produzcan cambios.

GitOps requiere tres componentes principales:

DevOps GitOps = IaC + MR + CI/CD

IAC

GitOps utiliza un repositorio de Git como única fuente de verdad para las definiciones de infraestructura. Git es un sistema de control de versiones de código abierto que realiza un seguimiento de los cambios de gestión de código.

Un repositorio de Git es una carpeta .git en un proyecto que realiza un seguimiento de todos los cambios realizados en los archivos de un proyecto a lo largo del tiempo.

Infraestructura como código (IaC) es la práctica de mantener toda la configuración de la infraestructura almacenada como código.

El estado real deseado puede o no almacenarse como código (p. ej., número de réplicas o pods).

MR

GitOps utiliza solicitudes de combinación (MR) como mecanismo de cambio para todas las actualizaciones de infraestructura.

El MR es donde los equipos pueden colaborar a través de revisiones y comentarios y donde tienen lugar las aprobaciones formales.

Una fusión se compromete con su rama principal (o troncal) y sirve como un registro de auditoría.

CI/CD

GitOps automatiza las actualizaciones de la infraestructura mediante un flujo de trabajo de Git con integración continua (CI) y entrega continua (CI/CD). Cuando se fusiona código nuevo, la canalización de CI/CD promulga el cambio en el entorno.

Cualquier cambio de configuración, como cambios manuales o errores, se sobrescribe con la automatización de GitOps para que el entorno converja en el estado deseado definido en Git.

Desafíos de GitOps

Con cualquier esfuerzo de colaboración, el cambio puede ser complicado y GitOps no es una excepción.

GitOps es un cambio de proceso que requerirá disciplina de todos los participantes y el compromiso de hacer las cosas de una manera nueva. Es vital que los equipos escriban todo.

GitOps permite una mayor colaboración pero eso no es necesariamente algo natural para algunas personas u organizaciones.

Un proceso de aprobación de GitOps significa que los desarrolladores realizan cambios en el código, crean una solicitud de fusión, un aprobador fusiona estos cambios y el cambio se implementa.

Esta secuencia introduce un elemento de “cambio por comité” en la infraestructura que puede parecer tedioso y lento para los ingenieros acostumbrados a realizar cambios rápidos y manuales.

Es importante que todos los miembros del equipo registren lo que sucede en las solicitudes y problemas de combinación.

La tentación de editar algo directamente en producción o cambiar algo manualmente va a ser difícil de reprimir, pero cuanto menos “ingeniería salvaje” haya, mejor funcionará GitOps.

¿Por qué deberías usar GitOps?

Existen muchos beneficios de GitOps entre los que se incluyen las mejoras en la eficiencia y seguridad, costos reducidos e implementaciones más rápidas.

Con GitOps, las organizaciones pueden administrar toda su infraestructura y el ciclo de vida de desarrollo de aplicaciones utilizando una única herramienta unificada.

Esto permite una mayor colaboración y coordinación entre los equipos y da como resultado menos errores y una resolución de problemas más rápida.

Además, GitOps permite a las organizaciones aprovechar las últimas prácticas y herramientas de DevOps, como la contenedorización y los microservicios.

Implementa más rápido y con más frecuencia

Probablemente todas las tecnologías de implementación continua prometen hacer que la implementación sea más rápida y permitan implementarse con más frecuencia.

Lo que es único acerca de GitOps es que no vas a tener que cambiar de herramienta para implementar una aplicación, puesto que todo sucede en el sistema de control de versiones que utilizas para desarrollar la aplicación.

Recuperación de errores fácil y rápida

Si tu entorno de producción está inactivo se producirá el caos dentro del equipo, con GitOps siempre tendrás un historial completo de cómo cambió el entorno con el paso del tiempo.

Eso hace que la recuperación de errores sea tan fácil como emitir un mensaje git reverty y ver a que punto quieres restaurar todo tu entorno.

Gestión de credenciales más sencilla

GitOps permite administrar implementaciones completamente desde dentro del entorno. Para ello, el entorno solo necesita acceso al repositorio y registro de imágenes. Eso es todo.

No tienes que dar a tus desarrolladores acceso directo a todo el entorno del proyecto.

Despliegues autodocumentados

¿Alguna vez has accedido a SSH en un servidor y te has preguntado qué se está ejecutando allí? Con GitOps, cada cambio en cualquier entorno debe realizarse a través del repositorio.

Siempre puede consultar en la rama maestra y obtener una descripción completa de lo que se implementa y dónde, además de tener el historial completo de cada cambio realizado en el sistema.

La ofrece una auditoría de cualquier cambio en todo tu sistema de forma totalmente gratuita.

Conocimiento compartido en equipos

El uso de Git para almacenar descripciones completas de tu infraestructura implementada permite que todo el equipo verifique la evolución a lo largo del tiempo.

Con excelentes mensajes de compromiso, todos pueden reproducir el proceso de pensamiento de cambiar la infraestructura y también encontrar fácilmente ejemplos de cómo configurar nuevos sistemas.

¿Cuál es la diferencia entre GitOps y DevOps?

Existen algunas diferencias clave entre GitOps y DevOps. Por un lado, GitOps se basa en gran medida en la automatización y las herramientas para administrar e implementar cambios de código, mientras que DevOps se enfoca más en la comunicación y la colaboración entre equipos.

Además, GitOps generalmente se usa junto con tecnologías de contenedorización como Kubernetes, mientras que DevOps se puede usar con cualquier tipo de aplicación.

GitOps es una rama de DevOps que se enfoca en el uso de repositorios git para administrar implementaciones de código de aplicaciones e infraestructura

La principal diferencia entre los dos es que en GitOps, el repositorio de git es la fuente de verdad para el estado de implementación, mientras que en DevOps, son los archivos de configuración de la aplicación o del servidor.

Componentes clave de un flujo de trabajo de GitOps

Hay cuatro componentes clave para un flujo de trabajo de GitOps, un repositorio de Git, una tubería de entrega continua (CD), una herramienta de implementación de aplicaciones y un sistema de monitoreo.

  1. El repositorio de Git es la fuente de la verdad para la configuración y el código de la aplicación.
  2. La canalización de CD es responsable de construir, probar e implementar la aplicación.
  3. La herramienta de implementación se utiliza para administrar los recursos de la aplicación en el entorno de destino.
  4. El sistema de monitoreo rastrea el rendimiento de la aplicación y proporciona retroalimentación al equipo de desarrollo.

¿Qué hace que GitOps funcione?

Al igual que con cualquier término de tecnología emergente, GitOps no se define estrictamente de la misma manera por todos en la industria.

Los principios de GitOps se pueden aplicar a todos los tipos de automatización de la infraestructura, incluidas las máquinas virtuales y los contenedores y pueden ser muy efectivos para los equipos que buscan administrar la infraestructura basada en Kubernetes.

Si bien, muchas herramientas y metodologías prometen una implementación más rápida y una administración fluida entre el código y la infraestructura, GitOps difiere al centrarse 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 mientras se benefician de las funciones integradas de Git.

FAQ GitOps

¿Está mi proyecto listo para GitOps?

¡Lo más probable es que sí! Lo bueno de GitOps es que no necesitas escribir ningún código de manera diferente.

Lo único que necesitas para comenzar es una infraestructura que se pueda administrar con herramientas declarativas de Infraestructura como código.

Si no utilizo Kubernetes, ¿Todavía puedo usar GitOps?

¡Sí! GitOps no se limita a Kubernetes. En principio, puedes utilizar cualquier infraestructura que se pueda observar y describir de forma declarativa y que tenga herramientas de Infraestructura como código disponibles.

Sin embargo, actualmente la mayoría de los operadores de GitOps basados en extracción se implementan enfocados hacía Kubernetes.

¿GitOps es solo una infraestructura versionada como código?

No. La infraestructura declarativa como código juega un papel muy importante en la implementación de GitOps, pero no es solo eso.

GitOps toma todo el ecosistema y las herramientas en torno a Git y lo aplica a la infraestructura.

Los sistemas de implementación continua garantizan que el estado actual deseado de la infraestructura se implemente en el entorno de producción.

Aparte de eso, se obtienen todos los beneficios de las revisiones de código, las solicitudes de extracción y los comentarios sobre los cambios en su infraestructura.

¿Cómo obtener secretos del entorno sin almacenarlos en git?

En primer lugar, ¡Nunca almacenes secretos en texto sin formato en git! ¡Nunca!

Dicho esto, si tienes secretos creados dentro del entorno que nunca abandonan el entorno.

El secreto permanece desconocido y las aplicaciones obtienen los secretos que necesitan, pero no están expuestos al mundo exterior.

Por ejemplo, aprovisiona una base de datos dentro del entorno y proporciona el secreto a las aplicaciones que interactúan solo con la base de datos.

Otro enfoque es agregar una clave privada al entorno (probablemente por alguien de un equipo de operaciones dedicado) y desde ese punto podrás agregar secretos cifrados por la clave pública al repositorio del entorno.

Incluso existe soporte de herramientas para crear esto del ecosistema de K8s.

¿Cómo maneja GitOps la propagación de DEV a PROD?

GitOps no proporciona una solución para propagar cambios de una etapa a la siguiente. Se recomienda usar un único entorno y evitar la propagación por etapas por completo.

Pero si se necesitan varias etapas (por ejemplo, DEV, QA, PROD, etc.) con un entorno para cada una, debes manejar la propagación fuera del alcance de GitOps; por ejemplo, mediante alguna canalización de CI/CD.

Si estamos haciendo DevOps. ¿Cuál es la diferencia con GitOps?

DevOps tiene que ver con el cambio cultural en una organización para hacer que las personas trabajen mejor juntas.

GitOps es una técnica para implementar la Entrega Continua.

Si bien DevOps y GitOps comparten principios como la automatización y la infraestructura de autoservicio, realmente no tiene sentido compararlos.

Sin embargo, estos principios compartidos ciertamente facilitan la adopción de un flujo de trabajo de GitOps cuando ya está empleando activamente técnicas de DevOps.

Entonces, ¿GitOps es básicamente NoOps?

Puedes usar GitOps para implementar NoOps, pero eso no hace que todas las tareas de operaciones queden obsoletas automáticamente.

Si estás utilizando recursos en la nube de todos modos, se puede utilizar GitOps para automatizarlos.

Sin embargo, por lo general, una parte de la infraestructura, como la configuración de la red o el clúster de Kubernetes que usarás no la administrarás de manera descentralizada; sino que se administrará de manera centralizada mediante un equipo de operaciones.

Así que las operaciones nunca desaparecerán realmente.

¿También existe SVNOps?

En cierto modo, sí. En principio, puedes utilizar cualquier sistema de control de versiones que desees.

Una de las ideas centrales de GitOps es permitir que los desarrolladores usen las herramientas con las que están familiarizados para operar en su infraestructura.

Si prefieres SVN a Git, ¡Genial!

Sin embargo, es posible que debas esforzarte más para encontrar herramientas que funcionen o incluso escribir tus propias herramientas, puesto que la mayoría de los operadores disponibles solo funcionan con el repositorio de Git.

¿Deberías contratar ingenieros de GitOps para tu equipo?

¡No! No hay ingenieros de GitOps. GitOps no es un rol (y tampoco lo es DevOps). GitOps es un conjunto de prácticas.

Lo que puedes buscar es un desarrollador que tenga experiencia en la práctica de GitOps o simplemente dejar que tus desarrolladores prueben y vayan adaptándose a estas nuevas prácticas.

Comparte tu opinión