Nota. traducir: Después de una publicación reciente En cuanto a los métodos pull y push en GitOps, vimos interés en este modelo en general, pero hubo muy pocas publicaciones en ruso sobre este tema (simplemente no hay ninguna sobre Habré). Por lo tanto, nos complace ofrecerle una traducción de otro artículo, ¡aunque hace casi un año! - de Weaveworks, cuyo director acuñó el término "GitOps". El texto explica la esencia del enfoque y las diferencias clave con los existentes.
Hace un año publicamos . En aquel entonces, compartimos cómo el equipo de Weaveworks lanzó un SaaS completamente basado en Kubernetes y desarrolló un conjunto de mejores prácticas prescriptivas para implementar, administrar y monitorear en un entorno nativo de la nube.
El artículo resultó ser popular. Otras personas empezaron a hablar sobre GitOps y empezaron a publicar nuevas herramientas para , , , , etcétera. Apareció en nuestro sitio web publicaciones y casos de uso de GitOps. Pero algunas personas todavía tienen preguntas. ¿En qué se diferencia el modelo del tradicional? y entrega continua ()? ¿Es necesario utilizar Kubernetes?
Pronto nos dimos cuenta de que se necesitaba una nueva descripción que ofreciera:
- Una gran cantidad de ejemplos e historias;
- Definición específica de GitOps;
- Comparación con la entrega continua tradicional.
En este artículo hemos intentado cubrir todos estos temas. Proporciona una introducción actualizada a GitOps y una perspectiva de desarrollador y CI/CD. Nos centramos principalmente en Kubernetes, aunque el modelo puede generalizarse.
Conoce GitOps
Imagina a Alicia. Dirige Family Insurance, que ofrece seguros médicos, de automóvil, de hogar y de viaje a personas que están demasiado ocupadas para entender por sí mismas los entresijos de los contratos. Su negocio comenzó como un proyecto paralelo cuando Alice trabajaba en un banco como científica de datos. Un día se dio cuenta de que podía utilizar algoritmos informáticos avanzados para analizar datos de forma más eficaz y formular paquetes de seguros. Los inversores financiaron el proyecto y ahora su empresa genera más de 20 millones de dólares al año y está creciendo rápidamente. Actualmente emplea a 180 personas en diversos puestos. Esto incluye un equipo de tecnología que desarrolla, mantiene el sitio web, la base de datos y analiza la base de clientes. El equipo de 60 personas está dirigido por Bob, el director técnico de la empresa.
El equipo de Bob implementa sistemas de producción en la nube. Sus aplicaciones principales se ejecutan en GKE, aprovechando Kubernetes en Google Cloud. Además, utilizan diversas herramientas de análisis y datos en su trabajo.
Family Insurance no se propuso utilizar contenedores, pero quedó atrapado en el entusiasmo de Docker. La empresa pronto descubrió que GKE facilitaba la implementación de clústeres para probar nuevas funciones. Se agregaron Jenkins para CI y Quay para organizar el registro de contenedores, y se escribieron scripts para Jenkins que enviaron nuevos contenedores y configuraciones a GKE.
Ha pasado algún tiempo. Alice y Bob estaban decepcionados con el desempeño del enfoque elegido y su impacto en el negocio. La introducción de contenedores no mejoró la productividad tanto como esperaba el equipo. A veces, las implementaciones fallaban y no estaba claro si los culpables eran los cambios de código. También resultó difícil realizar un seguimiento de los cambios de configuración. A menudo era necesario crear un nuevo clúster y mover aplicaciones a él, ya que era la forma más fácil de eliminar el desorden en el que se había convertido el sistema. Alice temía que la situación empeorara a medida que se desarrollara la aplicación (además, se estaba gestando un nuevo proyecto basado en el aprendizaje automático). Bob había automatizado la mayor parte del trabajo y no entendía por qué la tubería seguía siendo inestable, no escalaba bien y requería intervención manual periódicamente.
Luego aprendieron sobre GitOps. Esta decisión resultó ser exactamente lo que necesitaban para seguir adelante con confianza.
Alice y Bob llevan años escuchando hablar de Git, DevOps y la infraestructura como flujos de trabajo de código. Lo que es único de GitOps es que ofrece un conjunto de mejores prácticas (tanto definitivas como normativas) para implementar estas ideas en el contexto de Kubernetes. Este tema incluyendo .
Family Insurance decide implementar GitOps. La empresa ahora cuenta con un modelo de operación automatizado que es compatible con Kubernetes y combina velocidad con estabilidadporque ellos:
- descubrió que la productividad del equipo se duplicó sin que nadie se volviera loco;
- dejó de servir scripts. En cambio, ahora pueden centrarse en nuevas características y mejorar los métodos de ingeniería, por ejemplo, introduciendo implementaciones canary y mejorando las pruebas;
- hemos mejorado el proceso de implementación para que rara vez falle;
- tuvo la oportunidad de restaurar implementaciones después de fallas parciales sin intervención manual;
- comprado usadoоMayor confianza en los sistemas de entrega. Alice y Bob descubrieron que podían dividir el equipo en equipos de microservicios que trabajaran en paralelo;
- puede realizar entre 30 y 50 cambios en el proyecto todos los días gracias al esfuerzo de cada grupo y probar nuevas técnicas;
- es fácil atraer nuevos desarrolladores al proyecto, quienes tienen la oportunidad de implementar actualizaciones en producción mediante solicitudes de extracción en unas pocas horas;
- pasar fácilmente la auditoría en el marco de SOC2 (para el cumplimiento de los proveedores de servicios con los requisitos para la gestión segura de datos; lea más, por ejemplo, - aprox. trad.).
¿Qué ha pasado?
GitOps es dos cosas:
- Modelo operativo para Kubernetes y nativo de la nube. Proporciona un conjunto de mejores prácticas para implementar, administrar y monitorear aplicaciones y clústeres en contenedores. Definición elegante en la forma. de :
- El camino para crear un entorno de gestión de aplicaciones centrado en el desarrollador. Aplicamos el flujo de trabajo de Git tanto a operaciones como a desarrollo. Tenga en cuenta que no se trata solo de Git push, sino de organizar todo el conjunto de herramientas CI/CD y UI/UX.
Algunas palabras sobre Git
Si no está familiarizado con los sistemas de control de versiones y el flujo de trabajo basado en Git, le recomendamos encarecidamente que los conozca. Trabajar con sucursales y solicitudes de extracción puede parecer magia negra al principio, pero los beneficios valen la pena. Aquí para empezar
Cómo funciona Kubernetes
En nuestra historia, Alice y Bob recurrieron a GitOps después de trabajar con Kubernetes por un tiempo. De hecho, GitOps está estrechamente relacionado con Kubernetes: es un modelo operativo para infraestructura y aplicaciones basadas en Kubernetes.
¿Qué ofrece Kubernetes a los usuarios?
Estas son algunas de las características principales:
- En el modelo de Kubernetes, todo se puede describir en forma declarativa.
- El servidor API de Kubernetes toma esta declaración como entrada y luego intenta continuamente llevar el clúster al estado descrito en la declaración.
- Las declaraciones son suficientes para describir y gestionar una amplia variedad de cargas de trabajo: "aplicaciones".
- Como resultado, se producen cambios en la aplicación y el clúster debido a:
- cambios en las imágenes de los contenedores;
- cambios en la especificación declarativa;
- errores en el entorno, por ejemplo, fallos de contenedores.
Las grandes capacidades de convergencia de Kubernetes
Cuando un administrador realiza cambios en la configuración, el orquestador de Kubernetes los aplicará al clúster siempre que su estado sea no se acercará a la nueva configuración. Este modelo funciona para cualquier recurso de Kubernetes y es extensible con definiciones de recursos personalizados (CRD). Por lo tanto, las implementaciones de Kubernetes tienen las siguientes maravillosas propiedades:
- Automatización: Las actualizaciones de Kubernetes proporcionan un mecanismo para automatizar el proceso de aplicación de cambios de manera elegante y oportuna.
- Convergencia: Kubernetes seguirá intentando actualizar hasta que tenga éxito.
- Idempotencia: Las aplicaciones repetidas de la convergencia conducen al mismo resultado.
- Determinismo: Cuando los recursos son suficientes, el estado del clúster actualizado depende únicamente del estado deseado.
Cómo funciona GitOps
Hemos aprendido lo suficiente sobre Kubernetes para explicar cómo funciona GitOps.
Volvamos a los equipos de microservicios de Family Insurance. ¿Qué suelen tener que hacer? Mire la lista a continuación (si algún elemento le parece extraño o desconocido, deje de criticar y quédese con nosotros). Estos son sólo ejemplos de flujos de trabajo basados en Jenkins. Hay muchos otros procesos cuando se trabaja con otras herramientas.
Lo principal es que vemos que cada actualización finaliza con cambios en los archivos de configuración y repositorios de Git. Estos cambios en Git hacen que el "operador GitOps" actualice el clúster:
1.Proceso de trabajo: "Construcción de Jenkins - rama maestra".
Lista de tareas:
- Jenkins envía imágenes etiquetadas a Quay;
- Jenkins envía los gráficos de configuración y Helm al depósito de almacenamiento maestro;
- La función de nube copia la configuración y los gráficos del depósito de almacenamiento maestro al repositorio Git maestro;
- El operador de GitOps actualiza el clúster.
2. Compilación de Jenkins: rama de lanzamiento o revisión:
- Jenkins envía imágenes sin etiquetar a Quay;
- Jenkins envía los gráficos de configuración y Helm al depósito de almacenamiento provisional;
- La función de nube copia la configuración y los gráficos del depósito de almacenamiento provisional al repositorio Git provisional;
- El operador de GitOps actualiza el clúster.
3. Compilación de Jenkins: rama de desarrollo o característica:
- Jenkins envía imágenes sin etiquetar a Quay;
- Jenkins inserta los gráficos de configuración y Helm en el depósito de almacenamiento de desarrollo;
- La función de nube copia la configuración y los gráficos del depósito de almacenamiento de desarrollo al repositorio Git de desarrollo;
- El operador de GitOps actualiza el clúster.
4. Agregar un nuevo cliente:
- El gerente o administrador (LCM/ops) llama a Gradle para implementar y configurar inicialmente los balanceadores de carga de red (NLB);
- LCM/ops confirma una nueva configuración para preparar la implementación para las actualizaciones;
- El operador de GitOps actualiza el clúster.
Breve descripción de GitOps
- Describe el estado deseado de todo el sistema utilizando especificaciones declarativas para cada entorno (en nuestra historia, el equipo de Bob define toda la configuración del sistema en Git).
- El repositorio de Git es la única fuente de información sobre el estado deseado de todo el sistema.
- Todos los cambios al estado deseado se realizan mediante confirmaciones en Git.
- Todos los parámetros del clúster deseados también son observables en el propio clúster. De esta manera podemos determinar si coinciden (convergen, converger) o diferir (divergir, divergir) estados deseados y observados.
- Si los estados deseado y observado difieren, entonces:
- Existe un mecanismo de convergencia que, tarde o temprano, sincroniza automáticamente los estados objetivo y observado. Dentro del clúster, Kubernetes hace esto.
- El proceso comienza inmediatamente con una alerta de "cambio confirmado".
- Después de un período de tiempo configurable, se puede enviar una alerta "diferencial" si los estados son diferentes.
- De esta manera, todas las confirmaciones en Git provocan actualizaciones verificables e idempotentes en el clúster.
- La reversión es la convergencia a un estado previamente deseado.
- La convergencia es definitiva. Su aparición está indicada por:
- No hay alertas de diferencias durante un período de tiempo determinado.
- alerta "convergente" (por ejemplo, webhook, evento de reescritura de Git).
¿Qué es la divergencia?
Repitamos de nuevo: todas las propiedades deseadas del clúster deben ser observables en el propio clúster.
Algunos ejemplos de divergencia:
- Cambio en el archivo de configuración debido a la fusión de ramas en Git.
- Un cambio en el archivo de configuración debido a una confirmación de Git realizada por el cliente GUI.
- Múltiples cambios en el estado deseado debido a PR en Git seguidos de la creación de la imagen del contenedor y los cambios de configuración.
- Un cambio en el estado del clúster debido a un error, un conflicto de recursos que resulta en un "mal comportamiento" o simplemente una desviación aleatoria del estado original.
¿Cuál es el mecanismo de convergencia?
Unos pocos ejemplos:
- Para contenedores y clústeres, Kubernetes proporciona el mecanismo de convergencia.
- Se puede utilizar el mismo mecanismo para gestionar aplicaciones y diseños basados en Kubernetes (como Istio y Kubeflow).
- Proporciona un mecanismo para gestionar la interacción operativa entre Kubernetes, repositorios de imágenes y Git. , que es parte .
- Para las máquinas base, el mecanismo de convergencia debe ser declarativo y autónomo. Por nuestra propia experiencia podemos decir que más cercano a esta definición, pero aún requiere control humano. En este sentido, GitOps extiende la tradición de Infraestructura como Código.
GitOps combina Git con el excelente motor de convergencia de Kubernetes para proporcionar un modelo de explotación.
GitOps nos permite decir: Sólo aquellos sistemas que pueden describirse y observarse pueden automatizarse y controlarse..
GitOps está destinado a toda la pila nativa de la nube (por ejemplo, Terraform, etc.)
GitOps no es sólo Kubernetes. Queremos que todo el sistema se impulse de forma declarativa y utilice la convergencia. Por sistema completo nos referimos a una colección de entornos que trabajan con Kubernetes, por ejemplo, "clúster de desarrollo 1", "producción", etc. Cada entorno incluye máquinas, clústeres, aplicaciones, así como interfaces para servicios externos que proporcionan datos, monitoreo y etc.
Observe lo importante que es Terraform para el problema de arranque en este caso. Kubernetes debe implementarse en algún lugar y usar Terraform significa que podemos aplicar los mismos flujos de trabajo de GitOps para crear la capa de control que sustenta a Kubernetes y las aplicaciones. Esta es una práctica recomendada útil.
Hay un fuerte enfoque en aplicar conceptos de GitOps a capas sobre Kubernetes. Actualmente existen soluciones tipo GitOps para Istio, Helm, Ksonnet, OpenFaaS y Kubeflow, así como, por ejemplo, para Pulumi, que crean una capa para el desarrollo de aplicaciones nativas en la nube.
Kubernetes CI/CD: comparando GitOps con otros enfoques
Como se dijo, GitOps es dos cosas:
- El modelo operativo para Kubernetes y nativo de la nube descrito anteriormente.
- El camino hacia un entorno de gestión de aplicaciones centrado en el desarrollador.
Para muchos, GitOps es principalmente un flujo de trabajo basado en Git Push. A nosotros también nos gusta. Pero eso no es todo: veamos ahora las canalizaciones de CI/CD.
GitOps permite la implementación continua (CD) para Kubernetes
GitOps ofrece un mecanismo de implementación continua que elimina la necesidad de "sistemas de gestión de implementación" separados. Kubernetes hace todo el trabajo por usted.
- La actualización de la aplicación requiere una actualización en Git. Esta es una actualización transaccional al estado deseado. Luego, el propio Kubernetes realiza la "implementación" dentro del clúster en función de la descripción actualizada.
- Debido a la naturaleza del funcionamiento de Kubernetes, estas actualizaciones son convergentes. Esto proporciona un mecanismo para la implementación continua en el que todas las actualizaciones son atómicas.
- Nota: ofrece un operador GitOps que integra Git y Kubernetes y permite realizar CD conciliando el estado actual y deseado del clúster.
Sin kubectl y scripts
Debe evitar el uso de Kubectl para actualizar su clúster y, especialmente, evitar el uso de scripts para agrupar comandos de kubectl. En cambio, con la canalización de GitOps, un usuario puede actualizar su clúster de Kubernetes a través de Git.
Beneficios incluidos:
- Corrección. Se puede aplicar, hacer converger y finalmente validar un grupo de actualizaciones, acercándonos al objetivo del despliegue atómico. Por el contrario, el uso de scripts no ofrece ninguna garantía de convergencia (más sobre esto a continuación).
- seguridad. Kelsey Hightower: "Restringe el acceso a tu clúster de Kubernetes a las herramientas de automatización y a los administradores responsables de depurarlo o mantenerlo". ver también sobre seguridad y cumplimiento de especificaciones técnicas, así como robando credenciales de un guión de Jenkins escrito descuidadamente.
- Experiencia de usuario. Kubectl expone la mecánica del modelo de objetos de Kubernetes, que es bastante compleja. Idealmente, los usuarios deberían interactuar con el sistema en un nivel más alto de abstracción. Aquí me referiré nuevamente a Kelsey y recomendaré verla. .
Diferencia entre CI y CD
GitOps mejora los modelos CI/CD existentes.
Un servidor de CI moderno es una herramienta de orquestación. En particular, es una herramienta para orquestar canalizaciones de CI. Estos incluyen compilación, prueba, fusión con tronco, etc. Los servidores de CI automatizan la gestión de canalizaciones complejas de varios pasos. Una tentación común es crear un script para un conjunto de actualizaciones de Kubernetes y ejecutarlo como parte de una canalización para impulsar cambios en el clúster. De hecho, esto es lo que hacen muchos expertos. Sin embargo, esto no es óptimo y he aquí por qué.
Se debe utilizar CI para enviar actualizaciones al tronco, y el clúster de Kubernetes debe cambiar en función de esas actualizaciones para administrar el CD internamente. lo llamamos , a diferencia del modelo CI push. El CD es parte orquestación en tiempo de ejecución.
Por qué los servidores CI no deberían hacer CD mediante actualizaciones directas en Kubernetes
No utilice un servidor de CI para organizar actualizaciones directas de Kubernetes como un conjunto de trabajos de CI. Este es el antipatrón del que estamos hablando. en tu blog
Volvamos a Alice y Bob.
¿Qué problemas enfrentaron? El servidor CI de Bob aplica los cambios al clúster, pero si falla en el proceso, Bob no sabrá en qué estado se encuentra (o debería estar) el clúster ni cómo solucionarlo. Lo mismo ocurre en caso de éxito.
Supongamos que el equipo de Bob creó una nueva imagen y luego parcheó sus implementaciones para implementar la imagen (todo desde la canalización de CI).
Si la imagen se genera normalmente, pero la canalización falla, el equipo tendrá que resolver:
- ¿Se ha implementado la actualización?
- ¿Estamos lanzando una nueva construcción? ¿Conducirá esto a efectos secundarios innecesarios, con la posibilidad de tener dos compilaciones de la misma imagen inmutable?
- ¿Deberíamos esperar a la próxima actualización antes de ejecutar la compilación?
- ¿Qué salió mal exactamente? ¿Qué pasos deben repetirse (y cuáles es seguro repetir)?
Establecer un flujo de trabajo basado en Git no garantiza que el equipo de Bob no encuentre estos problemas. Todavía pueden cometer un error con el envío de confirmación, la etiqueta o algún otro parámetro; sin embargo, este enfoque está todavía mucho más cerca de un enfoque explícito de todo o nada.
En resumen, he aquí por qué los servidores CI no deberían trabajar con CD:
- Los scripts de actualización no siempre son deterministas; Es fácil cometer errores en ellos.
- Los servidores de CI no convergen al modelo de clúster declarativo.
- Es difícil garantizar la idempotencia. Los usuarios deben comprender la semántica profunda del sistema.
- Es más difícil recuperarse de un fallo parcial.
Nota sobre Helm: si desea utilizar Helm, le recomendamos combinarlo con un operador GitOps como . Esto ayudará a garantizar la convergencia. Helm en sí no es ni determinista ni atómico.
GitOps como la mejor forma de implementar la Entrega Continua para Kubernetes
El equipo de Alice y Bob implementa GitOps y descubre que se ha vuelto mucho más fácil trabajar con productos de software y mantener un alto rendimiento y estabilidad. Terminemos este artículo con una ilustración que muestra cómo es su nuevo enfoque. Tenga en cuenta que estamos hablando principalmente de aplicaciones y servicios, pero GitOps se puede utilizar para administrar una plataforma completa.
Modelo operativo para Kubernetes
Mira el siguiente diagrama. Presenta Git y el repositorio de imágenes del contenedor como recursos compartidos para dos ciclos de vida orquestados:
- Un canal de integración continua que lee y escribe archivos en Git y puede actualizar un repositorio de imágenes de contenedores.
- Un canal Runtime GitOps que combina implementación con administración y observabilidad. Lee y escribe archivos en Git y puede descargar imágenes de contenedores.
¿Cuáles son los principales hallazgos?
- Separación de intereses: Tenga en cuenta que ambas canalizaciones solo pueden comunicarse actualizando Git o el repositorio de imágenes. En otras palabras, existe un firewall entre CI y el entorno de ejecución. Lo llamamos el "firewall de inmutabilidad" (cortafuegos de inmutabilidad), ya que todas las actualizaciones del repositorio crean nuevas versiones. Para obtener más información sobre este tema, consulte las diapositivas 72-87. .
- Puede utilizar cualquier servidor CI y Git: GitOps funciona con cualquier componente. Puede seguir utilizando sus servidores CI y Git, repositorios de imágenes y conjuntos de pruebas favoritos. Casi todas las demás herramientas de entrega continua del mercado requieren su propio servidor CI/Git o repositorio de imágenes. Esto puede convertirse en un factor limitante en el desarrollo de la nube nativa. Con GitOps, puedes utilizar herramientas familiares.
- Los eventos como herramienta de integración: Tan pronto como se actualizan los datos en Git, Weave Flux (o el operador de Weave Cloud) notifica el tiempo de ejecución. Siempre que Kubernetes acepta un conjunto de cambios, Git se actualiza. Esto proporciona un modelo de integración simple para organizar flujos de trabajo para GitOps, como se muestra a continuación.
Conclusión
GitOps proporciona las sólidas garantías de actualización que requiere cualquier herramienta CI/CD moderna:
- automatización;
- convergencia;
- idempotencia;
- determinismo.
Esto es importante porque ofrece un modelo operativo para desarrolladores nativos de la nube.
- Las herramientas tradicionales para gestionar y monitorear sistemas están asociadas con equipos de operaciones que operan dentro de un runbook. (un conjunto de procedimientos y operaciones de rutina - aprox. traducción), vinculado a una implementación específica.
- En la gestión nativa de la nube, las herramientas de observabilidad son la mejor manera de medir los resultados de las implementaciones para que el equipo de desarrollo pueda responder rápidamente.
Imagine muchos clústeres dispersos en diferentes nubes y muchos servicios con sus propios equipos y planes de implementación. GitOps ofrece un modelo invariante de escala para gestionar toda esta abundancia.
PD del traductor
Lea también en nuestro blog:
- «";
- «";
- «".
Solo los usuarios registrados pueden participar en la encuesta. por favor
¿Sabías acerca de GitOps antes de que aparecieran estas dos traducciones en Habré?
-
si, lo sabia todo
-
Sólo superficialmente
-
No
35 usuarios votaron. 10 usuarios se abstuvieron.
Fuente: habr.com