La mayoría de nosotros, al notar un nuevo término en el blog o en una conferencia de TI, tarde o temprano nos hacemos la misma pregunta: “¿Qué es esto? ¿Es otra palabra de moda, un 'buzzword' o realmente algo que merece atención, estudio y promete nuevos horizontes?” Así fue como me ocurrió con el término GitOps hace algún tiempo. Armado con numerosos artículos existentes y el conocimiento de mis colegas de la empresa , intenté averiguar qué tipo de bestia era y cómo podría verse su aplicación en la práctica.
Por cierto, la novedad del término GitOps también se refleja en la reciente encuesta que realizamos: más de la mitad de los encuestados aún no habían comenzado a trabajar con sus principios.
Así que el problema de la gestión de la infraestructura no es nuevo. Muchos proveedores de servicios en la nube han estado disponibles al público durante más de diez años y, aparentemente, deberían haber facilitado el trabajo de los equipos responsables de la infraestructura. Sin embargo, al comparar con el proceso de desarrollo de aplicaciones (donde el nivel de automatización alcanza nuevos horizontes), los proyectos de infraestructura aún incluyen muchas tareas manuales y requieren conocimientos y especialistas específicos, especialmente teniendo en cuenta los modernos requisitos de resistencia, flexibilidad, escalabilidad y elasticidad.
Los servicios en la nube han satisfecho con éxito estos requisitos y precisamente ellos han dado un impulso significativo al desarrollo del enfoque IaC. Y es comprensible. Pues precisamente ellos han permitido configurar un centro de datos virtual completo: no hay servidores físicos, racks ni componentes de red; toda la infraestructura se puede describir mediante scripts y archivos de configuración.
Entonces, ¿cuál es la verdadera diferencia? GitOps desde IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Todo el código se almacena en un repositorio git
La versionado del código no es obligatorio
Descripción declarativa del código / Idempotencia
Se permite tanto la descripción declarativa como la imperativa
Los cambios entran en vigor utilizando mecanismos de Merge Request / Pull Request
La validación, aprobación y colaboración no son obligatorias
El proceso de implementación de actualizaciones está automatizado
El proceso de implementación de actualizaciones no está normalizado (automático, manual, copia de archivos, utilizando la línea de comando, etc.)
En otras palabras GitOps nació precisamente gracias a la aplicación de principios IaC. En primer lugar, la infraestructura y las configuraciones ahora podían almacenarse de la misma manera que las aplicaciones. El código es fácil de almacenar, compartir, comparar y aprovechar las capacidades de versionado. Versiones, ramas, historial. Y todo esto en un lugar público para todo el equipo. Por lo tanto, el uso de sistemas de control de versiones se convirtió en un desarrollo completamente lógico. En particular, git, como el más popular.
Por otro lado, surgió la posibilidad de automatizar los procesos de gestión de infraestructura. Ahora se puede hacer más rápido, más fiable y más barato. Además, los principios de CI/CD ya eran conocidos y populares entre los desarrolladores de software. Solo era necesario trasladar y aplicar los conocimientos y habilidades ya conocidas en un nuevo ámbito. Sin embargo, estas prácticas iban más allá de la definición estándar de Infraestructura como Código, de ahí nació el concepto. GitOps.
Curiosidad GitOps, por supuesto, también radica en que no es un producto, complemento o plataforma relacionada con ningún proveedor. Más bien, es una paradigma y un conjunto de principios, similar al otro término familiar: DevOps.
Puedes realizar Hemos desarrollado dos definiciones de este nuevo término: teórica y práctica. Comencemos por la teórica:
GitOps es una metodología que utiliza los principios avanzados de DevOps aplicados al desarrollo de aplicaciones, tales como control de versiones, colaboración, consenso, CI/CD, y los aplica para resolver tareas de automatización de la gestión de infraestructura.
Todos los procesos GitOps operan utilizando herramientas ya existentes. Todo el código de infraestructura se almacena en el repositorio git ya conocido, los cambios pasan por el mismo proceso de consenso que cualquier otro código de programa, y el proceso de implementación está automatizado, lo que minimiza los errores humanos, aumenta la fiabilidad y la reproducibilidad.
Desde un punto de vista práctico, describimos GitOps de la siguiente manera:
Hemos discutido la Infraestructura como Código como uno de los componentes clave de esta fórmula. Vamos a imaginar a los demás participantes.
Merge Request (nombre alternativo de Pull Request). En términos del proceso, un MR es una solicitud para aplicar cambios en el código y posteriormente fusionar ramas. Pero en cuanto a las herramientas que utilizamos, es más bien una oportunidad para obtener una visión completa de todos los cambios realizados: no solo un diff de código, generado a partir de varios commits, sino también contexto, resultados de pruebas y el resultado final esperado. Si hablamos de código de infraestructura, nos interesa cómo cambiará exactamente la infraestructura, cuántos nuevos recursos se agregarán o eliminarán, y cómo se modificarán. Idealmente, en un formato más conveniente y fácil de leer. En el caso de los proveedores de nube, sería útil saber qué consecuencias financieras acarreará este cambio.
Pero el MR también es una herramienta de colaboración, interacción y comunicación. Es el lugar donde opera el sistema de pesos y contrapesos. Desde simples comentarios hasta aprobaciones y validaciones formales.
Y el último componente: CI/CD, como ya sabemos, permite automatizar el proceso de hacer cambios en la infraestructura, pruebas (desde una simple verificación de sintaxis hasta un análisis estático de código más complejo). Además, en el futuro, detectar derivas: diferencias entre el estado real y el estado deseado del sistema. Por ejemplo, como resultado de cambios manuales no autorizados o fallas del sistema.
Sí, el término GitOps no nos introduce a nada absolutamente nuevo, no inventa la rueda, simplemente aplica la experiencia acumulada en un nuevo campo. Pero en eso radica su fuerza.
Y si de repente te interesa cómo se ve todo esto en la práctica, te invito a ver nuestro , en el que explico paso a paso cómo, utilizando GitLab:
Implementar los principios básicos de GitOps
Crear y realizar cambios en la infraestructura en la nube (con el ejemplo de Yandex Cloud)
Automatizar la detección de la deriva del sistema con respecto al estado deseado mediante monitoreo activo
https://bit.ly/34tRpwZ
Fuente: habr.com
