GitOps es genial, ¿no? ¿Qué es eso?, te escucho preguntar. En pocas palabras, en estos días, donde toda la infraestructura se puede virtualizar, GitOps se trata de administrar información sobre cómo debe verse (escrito como un archivo de texto), junto con la aplicación que se ejecutará en él. Aférrate a esa palabra ‘administrar’.
El concepto de infraestructura como código administrado de la misma manera que el código de software program puede ser easy, pero sus consecuencias son poderosas. De ahí GitOps, el término acuñado por Alexis Richardson, director ejecutivo y cofundador de Weaveworks: ‘git’ es el repositorio de código elegido para aplicaciones nativas de la nube y ‘ops’ porque, bueno, no se trata solo de eso en estos días. ?
La propia solución de flujo de trabajo GitOps de Weaveworks, FluxCD, acaba de graduarse de la fábrica de incubadoras que es Cloud Native Computing Basis (CNCF) – no es poca cosa dados los aros por los que habrá tenido que saltar. “Tuvimos auditores de seguridad en todo el código”, dijo Alexis cuando lo alcancé al respecto.
FluxCD no es el único chico de la cuadra: Argo CD por ejemplo, liderado por equipos de Intuit, Codefresh y otros, también logró la graduación de CNCF. Dos soluciones en competencia no son un problema: funcionan de diferentes maneras y se adaptan a diferentes casos de uso.
¿Y qué hay de esas poderosas consecuencias? Bueno. Impulsar el trabajo de GitOps es la necesidad clara y presente de administrar los datos de configuración en entornos de aplicaciones distribuidos masivamente y potencialmente altamente modificables. En el espacio cada vez más contenedorizado de aplicaciones nativas de la nube, este mismo controlador generó la existencia de motores de orquestación como DockerSwarm y Kubernetes, así como la necesidad de herramientas de observación de la nube, es decir, ¿cómo diablos identificamos un problema cuando no lo hacemos? siquiera saber dónde se está ejecutando nuestro software program?
En el espacio nativo de la nube, esto generalmente significa que cualquier aplicación que haya logrado sus objetivos de entrega a escala (ejemplos clave que siguen la arquitectura de Netflix) debe estar al tanto de cómo implementa su software program y luego cómo lo administra al mismo tiempo. escala. Hazlo y podrás lograr grandes cosas.
Por ejemplo, la manifestación de los tres es very important para escenarios como las comunicaciones de máquina a máquina y los automóviles sin conductor. En el espacio de las telecomunicaciones, en el que la última generación de tecnología inalámbrica (5G) es nativa de la nube por diseño, la capacidad de entregar actualizaciones de configuración y software program en paralelo y a escala solo es posible mediante la adopción de principios como GitOps. “Puedes actualizar cuarenta mil torres de telecomunicaciones sin tocarlas. Eso simplemente no sería posible de otra manera”, comenta Alexis, refiriéndose a Weaveworks’ camaradería con Deutsche Telekom.
GitOps es ordenado. Sin embargo, hay mucho que desglosar en la frase “administrar datos de configuración” del quinto párrafo anterior: no se trata solo de moverse de izquierda a derecha, desde el diseño de la aplicación/infraestructura hasta la implementación y luego a las operaciones. Cerca de mi corazón, y algo sobre lo que he escrito antes, es un tema central de todas las cosas de DevOps: que, en nuestro impulso por innovar a gran velocidad, hemos sacrificado nuestra capacidad de administrar lo que hemos creado.
Esta incapacidad para cerrar el ciclo infinito de DevOps se puede comparar con una manguera contra incendios que arroja datos de seguimiento, informes de incidentes, métricas de experiencia del usuario y similares, llenando el lado de desarrollo de la casa con fragmentos de información sin ninguna priorización o management actual. Es un desastre, lo que a menudo significa (me han dicho, de manera anecdótica) que los desarrolladores no saben en qué trabajar a continuación en términos de correcciones, por lo que simplemente continúan con lo que iban a hacer de todos modos, como una nueva funcionalidad.
En otra parte he hablado sobre la brecha de gobernanza entre la estrategia de innovación (“Vamos a crear algunas cosas nativas de la nube”) y la entrega. Es una de las razones por las que me aferré a la gestión del flujo de valor desde el principio como una forma de generar visibilidad en toda la tubería; también es por eso que estaba interesado en aprender más sobre el paso de Atlassian directamente al espacio de administración de servicios de TI.
GitOps resuelve la brecha de gobernanza, no agregando paneles y controles, al menos, no por sí mismos. Más bien, un principio basic de GitOps es que la información de configuración se inserta de la misma manera que el código y luego no se manipula después de la implementación, a menos que no se pueda evitar.
Estos dos conceptos están consagrados en el corazón de las herramientas de GitOps, ya que, de lo contrario, son solo cosas que apuesto a que se ven bien en una pizarra. Desde el Abrir GitOps sitio, el conjunto completo de principios es el siguiente:
1. Declarativo: un sistema debe documentarse por adelantado a través de declaraciones declaradas en lugar de tener que discernir el sistema a partir de su configuración de tiempo de ejecución.
2. Versionado e inmutable: se trata de almacenar estas declaraciones de infraestructura junto con el código de la aplicación, en un repositorio controlado por versión como git.
3. Extraído automáticamente: ahora estamos hablando de cómo el sistema deseado siempre se construye en función de su configuración declarada en lugar de retoques.
4. Reconciliados continuamente. Esta es la parte más genial e importante: si modifica la configuración del tiempo de ejecución, las herramientas deberían detectar el cambio y activar una solución.
Herramientas como FluxCD y ArgoCD promulgan estos principios. Fascinantemente, funcionan con el hecho de que los ingenieros no van a querer ralentizar la forma en que construyen las cosas, simplemente hacen cumplir el hecho de que no puedes manipularlo una vez que está hecho, y si lo haces, se generará una alerta. . Esto puede causar rechazo por parte de las personas que quieren promulgar cambios en el sistema en ejecución, en lugar de cambiar la fuente de la verdad, cube Alexis. “La gente cube que hay una latencia alta, a menudo no han configurado correctamente su sistema”.
Estoy haciendo este punto tan clara y directamente como puedo, debido a los peligros de (puedo llamarlo) lavado de GitOps. Solo cumplir con los dos primeros principios anteriores, o simplemente almacenar información de infraestructura como código en git, no significa que se esté haciendo GitOps. O es un circuito cerrado con identificación y conciliación de desviaciones de configuración basadas en alertas, o es solo otra canalización.
Tampoco se trata simplemente de principios, sino de beneficios. ¿Ese punto anterior sobre la implementación de actualizaciones en cuarenta mil torres de telecomunicaciones? Eso solo es posible si las fuentes de fricción de implementación se minimizan o eliminan por completo y si el entorno resultante se puede administrar operativamente en función de una comprensión lo más clara posible de cómo se ve. “No hay otro modelo operativo que realmente escale”, comenta Alexis, y tiene razón.
En última instancia, esto va al corazón de lo que significa ser ágil en el mundo digital. La agilidad no se trata de un caos controlado o de romper cosas sin crearlas realmente: tiene éxito con formas de trabajar y herramientas complementarias que se alinean con las necesidades de innovación a escala. Sí, GitOps es genial, pero solo si todas sus facetas se adoptan al por mayor: GitOps lite no es GitOps en absoluto.
