La mayoría de nosotros, al notar otro término nuevo en la blogosfera o conferencia de TI, tarde o temprano hacemos una pregunta similar: “¿Qué es esto? ¿Sólo otra palabra de moda, una “palabra de moda” o algo realmente digno de atención, estudio y promesa de nuevos horizontes? A mi me pasó lo mismo con el término GitOps hace tiempo. Armado con muchos artículos existentes, así como con el conocimiento de colegas de la empresa. Intenté descubrir qué tipo de bestia es esta y cuál podría ser su uso en la práctica.
Por cierto, sobre la novedad del término. GitOps Nuestra reciente encuesta también dice: más de la mitad de los encuestados aún no han comenzado a trabajar con sus principios.
Por tanto, el problema de la gestión de infraestructuras no es nuevo. Muchos proveedores de nube están disponibles para el público en general desde hace una docena de años y, al parecer, deberían haber hecho que el trabajo de los equipos responsables de la infraestructura fuera sencillo y sencillo. Sin embargo, en comparación con el proceso de desarrollo de aplicaciones (donde la automatización está alcanzando niveles cada vez nuevos), los proyectos de infraestructura a menudo todavía implican muchas tareas manuales y requieren conocimientos y experiencia especializados, especialmente teniendo en cuenta los requisitos actuales de tolerancia a fallos, flexibilidad, escalabilidad y elasticidad.
Los servicios en la nube cumplieron estos requisitos con mucho éxito y fueron ellos quienes dieron un impulso significativo al desarrollo del enfoque. IAC. Esto es comprensible. Después de todo, hicieron posible configurar un centro de datos completamente virtual: no hay servidores físicos, bastidores ni componentes de red; toda la infraestructura se puede describir mediante scripts y archivos de configuración.
Entonces, ¿cuál es exactamente la diferencia? GitOps de IAC? Fue con esta pregunta que comencé mi investigación. Después de hablar con colegas, pude hacer la siguiente comparación:
GitOps
IAC
Todo el código se almacena en un repositorio git
El control de versiones del código es opcional.
Código declarativo Descripción / Idempotencia
Se aceptan descripciones tanto declarativas como imperativas.
Los cambios entran en vigor mediante los mecanismos de solicitud de combinación/solicitud de extracción
El acuerdo, la aprobación y la colaboración son opcionales.
El proceso de implementación de actualizaciones está automatizado.
El proceso de implementación de actualizaciones no está estandarizado (automático, manual, copia de archivos, uso de la línea de comandos, etc.)
En otras palabras GitOps nació precisamente de la aplicación de los principios IAC. En primer lugar, la infraestructura y las configuraciones ahora podrían almacenarse del mismo modo que las aplicaciones. El código es fácil de almacenar, compartir, comparar y utilizar capacidades de control de versiones. Versiones, ramas, historia. Y todo ello en un lugar de acceso público para todo el equipo. Por lo tanto, el uso de sistemas de control de versiones se convirtió en un desarrollo completamente natural. En particular, git es el más popular.
Por otro lado, fue posible automatizar los procesos de gestión de infraestructura. Ahora esto se puede hacer de forma más rápida, fiable y económica. Además, los principios de CI/CD ya eran conocidos y populares entre los desarrolladores de software. Sólo era necesario transferir y aplicar conocimientos y habilidades ya conocidos a una nueva área. Estas prácticas, sin embargo, fueron más allá de la definición estándar de Infraestructura como código, de ahí el concepto GitOps.
Curiosidad GitOps, por supuesto, también en el hecho de que no es un producto, complemento o plataforma asociada a ningún proveedor. Es más bien un paradigma y un conjunto de principios, similar a otro término con el que estamos familiarizados: DevOps.
La compañía Hemos desarrollado dos definiciones de este nuevo término: teórica y práctica. Empecemos por lo teórico:
GitOps es una metodología que toma los mejores principios de DevOps utilizados para el desarrollo de aplicaciones, como control de versiones, colaboración, orquestación, CI/CD, y los aplica a los desafíos de automatizar la gestión de infraestructura.
Todos los procesos GitOps Trabajo utilizando herramientas existentes. Todo el código de infraestructura se almacena en el ya conocido repositorio git, los cambios pasan por el mismo proceso de aprobación que cualquier otro código de programa y el proceso de implementación está automatizado, lo que nos permite minimizar los errores humanos, aumentar la confiabilidad y la reproducibilidad.
Desde un punto de vista práctico, describimos GitOps следующим обрахом:
Ya hemos analizado la infraestructura como código como uno de los componentes clave de esta fórmula. Presentemos al resto de participantes.
Solicitud de fusión (nombre alternativo Solicitud de extracción). En términos de proceso, MR es una solicitud para aplicar cambios de código y luego fusionar ramas. Pero en términos de las herramientas que utilizamos, esta es más una oportunidad para obtener una imagen completa de todos los cambios que se están realizando: no solo la diferencia de código recopilada de una cierta cantidad de confirmaciones, sino también el contexto, los resultados de las pruebas y la resultado final esperado. Si hablamos de código de infraestructura, entonces nos interesa cómo cambiará exactamente la infraestructura, cuántos recursos nuevos se agregarán, eliminarán y cambiarán. Preferiblemente en algún formato más conveniente y fácil de leer. Para los proveedores de nube, es una buena idea saber cuál será el impacto financiero de este cambio.
Pero la RM también es un medio de colaboración, interacción y comunicación. El lugar donde entra en juego el sistema de frenos y contrapesos. Desde simples comentarios hasta aprobaciones y aprobaciones formales.
Bueno, el último componente: CI/CD, como ya sabemos, permite automatizar el proceso de realizar cambios y pruebas de infraestructura (desde una simple verificación de sintaxis hasta un análisis de código estático más complejo). Y también en la posterior detección de derivas: diferencias entre el estado real y el deseado del sistema. Por ejemplo, como resultado de cambios manuales no autorizados o fallas del sistema.
Sí, el término GitOps no nos presenta nada completamente nuevo, no reinventa la rueda, sino que simplemente aplica la experiencia ya acumulada en un área nueva. Pero aquí es donde reside su fuerza.
Y si de repente te interesa saber cómo se ve todo esto en la práctica, te invito a que eches un vistazo a nuestro , en el que te cuento paso a paso cómo usar GitLab:
-
Implementar los principios básicos de GitOps.
-
Crear y realizar cambios en la infraestructura de la nube (usando el ejemplo de Yandex Cloud)
-
Automatizar la detección de desvíos del sistema desde un estado deseado mediante el monitoreo activo
https://bit.ly/34tRpwZ
Fuente: habr.com