Cómo aprovechar al máximo GitOps ahora mismo

Es posible que haya encontrado esta breve introducción a GitOps compartida por el ingeniero de software en la nube predominante, Torre alta de Kelsey:

en el mundo de infraestructura como código, GitOps es una forma popular de administrar implementaciones automatizadas a través de integración continua/desarrollo continuo (CI/CD) y arquitectura de microservicios en general, ya que la mayor parte de nuestra infraestructura se define esencialmente en archivos de configuración actuales (por ejemplo, YAML, JSON, HCL). Esto no se limita a Kubernetes (K8s), pero a menudo está muy asociado con los clústeres de K8s. (Explicaré por qué en un segundo). Esto básicamente significa que cambiar cualquier cosa en la infraestructura de producción es tan simple como cambiar una línea de código.

La razón por la que GitOps se identifica tan de cerca con K8s es que K8s está completamente configurado en YAML declarativo y, por lo tanto, puede obtener rápidamente los beneficios de usar GitOps, ya que en realidad es solo una infraestructura definida por software. Cuando se trata de aplicar correctamente GitOps en su organización de ingeniería, lo principal a lo que debe prestar atención es cómo aplicar cambios en su clúster o infraestructura.

Al elegir la ruta de GitOps, solo puede hacerlo a través de una única fuente de verdad: su repositorio de administración de código fuente (SCM) (por ejemplo, GitLab, GitHub, Bitbucket o su solución de alojamiento) que aplica la versión de la política de auditoría para toda su organización. Esto significa que la única forma de realizar cambios en su infraestructura es a través de una solicitud de extracción en su repositorio. Así es como se mantiene el control de versiones a gran escala en grandes organizaciones de ingeniería que utilizan GitOps.

Índice

    El estado de las implementaciones en el mundo real

    La doctrina GitOps afirma ser la forma nueva y más fácil de obtener CI/CD, excepto que la parte CD de CI/CD es una bestia mucho más compleja de lo que las prácticas de GitOps le harían creer. Con GitOps, la parte del CD se divide en un enfoque muy binario para diseñar entornos. Está en etapa de preparación o en producción, donde simplemente presiona el interruptor y su código está en producción. En mis años de experiencia como ingeniero, todavía tengo que participar en un cambio de código significativo, implementación de funciones u otra implementación importante que sea tan simple como eso.

    Hay mucho más trabajo encapsulado en el control de versiones de puesta en escena o producción completamente abstraído del proceso de CD con GitOps. Esto significa que cualquier proceso de diseño que se tome en serio la calidad tendrá algunas fases entre las fases de CI y CD de una implementación importante. Estos incluyen pruebas, validación de resultados, verificación de que los cambios se han propagado, pruebas repetidas y, a menudo, implementaciones parciales (Canary y similares). Estos son solo algunos ejemplos de cómo se maneja el CD en las organizaciones de ingeniería.

    Sugerencias de GitOps para mejorar las implementaciones

    Cuando se trata de GitOps, no hay necesidad de reinventar la rueda CI/CD (y especialmente el CD). Si es como la mayoría de las personas y obtiene CI/CD al grabar su proceso de CD con algunos scripts personalizados antes y después de la implementación para superarlo, sepa que hay mejores maneras de hacerlo con los facilitadores de GitOps. Uso de facilitadores de GitOps como código abierto, alojado por Cloud Native Computing Foundation (CNCF). CD Argo permite a los usuarios tomar todos esos scripts personalizados y administrarlos a escala en un solo lugar. Esto asegura las mejores prácticas al usar scripts en el proceso de CI/CD, haciéndolos canónicos y repetibles cada vez que se ejecutan.

    Además, dado que hay un agente que sincroniza continuamente el estado, reduce los errores humanos al hacer cumplir el estado de confirmación.

    Manejar el caos entre repositorios con GitOps

    Con arquitecturas de implementación complejas como K8 o incluso simples microservicios antiguos, incluso los pequeños cambios en el código a menudo afectan a otros servicios interdependientes. Mapear estas dependencias con GitOps tiende a convertirse en un infierno. A menudo, con archivos y repositorios compartidos, necesita sincronizar el estado. Sin embargo, lo que encontrará a menudo es que los errores, las configuraciones incorrectas o incluso los errores pueden crear una efecto mariposa lo que inicia una cascada de fallas que se vuelve extremadamente difícil de rastrear y comprender en GitOps.

    Una forma común de resolver este desafío con GitOps es crear un "súper repositorio", que es esencialmente una ubicación única centralizada que contiene punteros a todas las dependencias, archivos, recursos, etc. relevantes. Sin embargo, esto se convierte rápidamente en un "trampa" desordenado de un repositorio, donde es extremadamente difícil comprender, rastrear y registrar los cambios.

    Cuando tiene muchas dependencias, para que esto funcione en GitOps, estas dependencias deben estar representadas en Git. Esto requiere que su organización sea "nativa de Git". Esto significa que tendrá que hacer mucho trabajo de automatización de cinta adhesiva para crear módulos y submódulos para conectar y correlacionar su súper repositorio y sus subrepos. Muchas veces, esto genera muchos costos generales de mantenimiento que se vuelven extremadamente difíciles de mantener con el tiempo.

    Si no lo hace, no obtendrá los beneficios de GitOps y, en su mayoría, se quedará con las desventajas. Puede lograr capacidades similares a través de un archivo YAML que encapsula todas las versiones y dependencias, similar a un gráfico general de Helm. Sin volverse completamente nativo de Git, básicamente podría ser cualquier otra cosa y no GitOps.

    Mientras que en el mundo de GitOps, los repositorios son la única fuente de verdad para los entornos, en la práctica hay muchas integraciones de terceros en una distribución determinada. Estas integraciones pueden ser cualquier cosa, desde su autenticación y autorización (por ejemplo, Auth0) hasta su base de datos, que, en su mayor parte, se actualizan externamente a su repositorio. Estos cambios de recursos externos, que podrían tener un impacto significativo en la producción y las implementaciones, no tienen representación dentro del repositorio con una única fuente de verdad. Esto podría ser un punto ciego serio en toda la distribución.

    Consejos de GitOps para gestionar mejor el caos

    Cuando use GitOps, trate sus configuraciones de la misma manera que trataría su código. No escatime en canalizaciones de validación, asegúrese de que la higiene de las solicitudes de incorporación de cambios sea adecuada y cumpla con cualquier otra práctica que aplique cuando administre el código a escala para evitar este caos. ¡No entres en pánico! Si se envía algo incorrecto y le preocupa que se propague a todos los servidores, clústeres y repositorios, todo lo que necesita hacer es ejecutar git reverty puedes deshacer la última confirmación.

    Además, de manera similar a mi recomendación de estado de sincronización, el uso de facilitadores de GitOps puede ayudar a administrar las prácticas de Git, ser nativo de Git y administrar las distribuciones de Kubernetes (además de ser nativo de Kubernetes).

    Finalmente, para evitar el desorden o la complejidad, asegúrese de que el estado de su repositorio de Git esté lo más cerca posible de sus entornos de producción para evitar que sus entornos se desvíen de las operaciones de GitOps.

    3 consejos para usar GitOps

    Estos son mis consejos para aprovechar al máximo GitOps:

    1. Asegúrese de generar visibilidad en su automatización de GitOps desde el principio, para no ejecutar a ciegas a través de sus muchos repositorios. Cuando se trata de hacer que GitOps funcione de manera óptima, debe trabajar con un solo repositorio por aplicación. Cuando estos comienzan a acumularse, la visibilidad puede convertirse en un verdadero punto de dolor. Piense en las dependencias y cómo diseñar suficiente visibilidad en el sistema, de modo que si algo sale mal, sabrá cómo rastrearlo hasta su origen y solucionarlo.
    2. Una forma de hacer esto es planificar todo tipo de escenarios de falla. ¿Qué sucede cuando las dependencias fallan? Cuando se trata de GitOps, los conflictos de fusión son una forma de vida. ¿Cómo maneja las implementaciones de alta velocidad y las promociones de producción que pueden abrumar a un sistema GitOps? Piense en los muchos desafíos, fracasos y conflictos potenciales y mantenga un libro de jugadas para cada uno. Además, siguiendo el primer punto, asegúrese de que haya suficiente visibilidad para que todos puedan resolver los problemas rápidamente. Y por supuesto, no olvides el git revert Comando en caso de error.
    3. Usa un monorepo. Aquí, lo dije. El viejo mono vs. multi-repo. Cuando se trata de GitOps, no hay duda de cuál es la mejor opción. Si bien un repositorio único centralizado tiene inconvenientes (por ejemplo, puede volverse desordenado, comprender los procesos de compilación, convertirse en una pesadilla, etc.), también puede ayudar a resolver la mayoría de los problemas con las dependencias entre repositorios.

    Como ingeniero, sentí este dolor directamente. Me di cuenta de que existe una necesidad urgente de algo que correlacione estas adicciones y los desafíos de visibilidad que he sentido todos los días de mi vida con GitOps.

    Quería una mejor solución para detectar y conectar errores en cascada en una configuración de microservicios compleja para una causa raíz o un cambio de código. Todo lo que había intentado hasta la fecha, incluido GitOps, proporcionó solo información parcial, muy pocas correlaciones y casi ninguna causalidad.

    Las herramientas de GitOps (como Argo CD) ayudan a resolver muchos problemas que surgen con DIY GitOps. El uso de tales herramientas puede ser algo bueno a tener en cuenta al caminar por el camino de GitOps porque:

    • Están diseñados de forma nativa para Kubernetes
    • Son adecuados para equipos pequeños que utilizan el extractor de imágenes.
    • Tener un fuerte apoyo de la comunidad (por ejemplo, Argo CD a través de CNCF, que también es fácil de usar con otras herramientas de Argo)
    • Proporcione una experiencia de desarrollo mejorada con una buena interfaz de usuario para aplicaciones
    • Integración nativa con Git, que ayuda a minimizar el caos y la complejidad

    La línea de fondo

    Los procesos de distribución, especialmente con nuevas versiones, son un complejo firma de ingeniería. Para lograr estos resultados, es necesario invertir esfuerzos tanto en tecnología como en diseño de procesos. Por ejemplo, ¿cuál es la mejor manera de implementar y validar mi aplicación en producción?

    GitOps es un excelente punto de partida para comprender lo que se ejecuta en producción. Tenga en cuenta que también puede necesitar un poco más de actualización con herramientas adicionales y automatización de bricolaje para que funcione perfectamente para su equipo de ingeniería. De esa forma, la brillantez de GitOps es de 24K en lugar de oro de los tontos para su organización.

    Artículos de interés

    Subir