GitOps: todo sobre esta in­frae­s­tru­c­tu­ra in­fo­r­má­ti­ca au­to­ma­ti­za­da

GitOps es un concepto que gestiona in­frae­s­tru­c­tu­ras y apli­ca­cio­nes mediante un enfoque de­cla­ra­ti­vo y las controla con Git. El objetivo de esta idea es au­to­ma­ti­zar los procesos, ahorrar tiempo y ga­ra­n­ti­zar una mejor y más segura co­la­bo­ra­ción entre los distintos equipos en los re­po­si­to­rios.

La au­to­ma­ti­za­ción desempeña un papel fu­n­da­me­n­tal en el ámbito del de­sa­rro­llo de software. Esta es una de las razones por las que DevOps ha tenido un éxito tan rotundo. La base de esto es la idea del “In­fra­s­tru­c­tu­re as Code (IaC)”, que pretende mapear las in­frae­s­tru­c­tu­ras y co­n­fi­gu­ra­cio­nes de un sistema in­fo­r­má­ti­co y de esta manera hacerlas re­pro­du­ci­bles. GitOps es una extensión lógica de este enfoque. Desde 2017, el software de código abierto Git controla todo el proceso de gestión de una apli­ca­ción, desde la ad­mi­ni­s­tra­ción hasta el de­sa­rro­llo final del software, como un “Single Source of Truth”. Para ello, GitOps define un estado objetivo, comprueba y, si es necesario, ajusta la in­frae­s­tru­c­tu­ra hasta alcanzar dicho estado.

Wea­ve­wo­r­ks pro­po­r­cio­na un conjunto de buenas prácticas para unificar los métodos in­di­vi­dua­les de su­pe­r­vi­sión de los co­n­te­ne­do­res. Estos pueden aplicarse a Ku­be­r­ne­tes y otras te­c­no­lo­gías con un trasfondo en la nube, lo que facilita su gestión. Git se remonta a un sistema de control de versiones de­sa­rro­lla­do por Linus Torvald en 2005. Permite que di­fe­re­n­tes equipos de de­sa­rro­lla­do­res trabajen juntos en un mismo proyecto en paralelo. Los cambios solo se adoptan tras un acuerdo conjunto y se conservan los estados de de­sa­rro­llo más antiguos. Los de­sa­rro­lla­do­res pueden trabajar en di­fe­re­n­tes aspectos si­mu­l­tá­nea­me­n­te y co­m­bi­nar­los al final. En nuestra Digital Guide puedes acceder a un tutorial de Git completo.

Con GitOps, el estado objetivo de un sistema se describe primero de forma de­cla­ra­ti­va. Los cambios se realizan según el principio de Git a través de pull requests. Si se llevan a cabo, modifican el re­po­si­to­rio Git. Cuando se realiza un pull request en un entorno con GitOps, el operador GitOps se activa, captura el commit y solicita el estado actual a través de Git. Lo compara con el estado deseado en el re­po­si­to­rio. Una vez aprobados los cambios, se fusionan con el estado anterior y se adoptan di­re­c­ta­me­n­te para la in­frae­s­tru­c­tu­ra en directo. Esto permite que los procesos sean más rápidos y fluidos, además de ga­ra­n­ti­zar la es­ta­bi­li­dad y fia­bi­li­dad del sistema.

Gracias a unos pri­n­ci­pios cla­ra­me­n­te definidos e inal­te­ra­bles, los flujos de trabajo de GitOps deberían funcionar siempre de forma fiable. En primer lugar, se trata de los sistemas de­cla­ra­ti­vos que se han descrito an­te­rio­r­me­n­te, ya conocidos por otros cloud natives. La de­s­cri­p­ción de­cla­ra­ti­va garantiza que todo el sistema pueda ser tratado como código y ve­r­sio­na­do. Esto sirve para la seguridad y la es­ta­bi­li­dad de todo el sistema, ya que las de­s­via­cio­nes de la versión Git también pueden re­co­no­ce­r­se y no­ti­fi­car­se in­me­dia­ta­me­n­te. Además, las SSH Keys ga­ra­n­ti­zan que siempre se pueda rastrear y averiguar el origen de un código. Gracias a la de­cla­ra­ción previa, los cambios también pueden au­to­ma­ti­zar­se, de­te­c­tar­se las posibles fuentes de error y co­rre­gi­r­se en una fase temprana.

El enfoque principal de DevOps es, y siempre ha sido, acercar el de­sa­rro­llo a la ejecución para si­m­pli­fi­car los flujos de trabajo. Dado que los equipos in­di­vi­dua­les colaboran más es­tre­cha­me­n­te, el producto final mejora y los cambios pueden rea­li­zar­se con mayor rapidez y precisión. GitOps adopta este enfoque y lo aplica de forma coherente a la parte de ejecución (ope­ra­cio­nes). GitOps se centra co­m­ple­ta­me­n­te en Git, mientras que DevOps y DevSecOps son más bien una idea fu­n­da­me­n­tal que impulsa la co­la­bo­ra­ción entre áreas antes separadas y se basa en pipelines de CI y CD. Sin embargo, ambos enfoques también pueden co­m­bi­nar­se.

A di­fe­re­n­cia del Co­n­ti­nuous Delivery y Co­n­ti­nuous In­te­gra­tion, GitOps extrae toda la in­fo­r­ma­ción necesaria di­re­c­ta­me­n­te de Git según el principio de pull y prescinde del de­s­plie­gue a través de un servidor CI. El servidor CI puede seguir uti­li­zá­n­do­se con GitOps, pero solo es re­s­po­n­sa­ble de la co­n­s­tru­c­ción y las pruebas. Puedes encontrar más in­fo­r­ma­ción sobre el tema Co­n­ti­nuous In­te­gra­tion vs. Co­n­ti­nuous Delivery vs. Co­n­ti­nuous De­plo­y­me­nt en la Digital Guide.

Debido a su ve­r­sa­ti­li­dad, Ku­be­r­ne­tes es pro­ba­ble­me­n­te la pla­ta­fo­r­ma más im­po­r­ta­n­te para gestionar apli­ca­cio­nes basadas en co­n­te­ne­do­res. Ku­be­r­ne­tes también trabaja de forma de­cla­ra­ti­va y tiene en cuenta el estado de destino de un sistema. Por lo tanto, Ku­be­r­ne­tes puede trabajar muy bien con GitOps y también hacer las veces de operador. Sin embargo, es im­po­r­ta­n­te que el código fuente y la co­n­fi­gu­ra­ción estén separados por motivos de seguridad y para una mejor visión de conjunto. El estado actual puede ser al­ma­ce­na­do en un re­po­si­to­rio Git separado. También es im­po­r­ta­n­te utilizar las he­rra­mie­n­tas de si­n­cro­ni­za­ción adecuadas que impidan el acceso no au­to­ri­za­do y los posibles errores.

Mientras tanto, existen numerosas he­rra­mie­n­tas para GitOps que pretenden si­m­pli­fi­car y mejorar si­g­ni­fi­ca­ti­va­me­n­te la au­to­ma­ti­za­ción, por ejemplo, he­rra­mie­n­tas para trabajar con Ku­be­r­ne­tes que actúan como ope­ra­do­res y se encargan de la im­ple­me­n­ta­ción de GitOps. El operador (o co­n­tro­la­dor pe­r­so­na­li­za­do) más conocido es Flux. Algunas al­te­r­na­ti­vas son ArgoCD o Fleet. Las he­rra­mie­n­tas más im­po­r­ta­n­tes para una mayor seguridad son SOPS de Mozilla y Sealed Secrets de Bitnami. Cluster API o Fleet son ideales para combinar con clústeres de Ku­be­r­ne­tes. En general, el mercado es re­la­ti­va­me­n­te amplio, por lo que hay una he­rra­mie­n­ta adecuada para casi todas las apli­ca­cio­nes.

Si quieres saber cómo de bueno y adecuado es GitOps para lo que lo necesitas, vale la pena echar un vistazo a sus ventajas y de­s­ve­n­ta­jas.

• Pro­du­c­ti­vi­dad: Gracias a la au­to­ma­ti­za­ción, se pueden realizar muchos más cambios en un menor tiempo. De este modo, los de­sa­rro­lla­do­res sacan los proyectos adelante con mucha más efi­cie­n­cia.
• Seguridad y es­ta­bi­li­dad: Gracias a la precisión de los controles, los errores se detectan más rá­pi­da­me­n­te e incluso se corrigen au­to­má­ti­ca­me­n­te. Esto co­n­tri­bu­ye a una mayor seguridad y es­ta­bi­li­dad. Gracias a los rollbacks re­si­s­te­n­tes, la re­s­ti­tu­ción de estados an­te­rio­res también es mucho más fácil y el enfoque pull evita co­m­pli­ca­cio­nes no deseadas.
• Unidad: Los flujos de trabajo están uni­fi­ca­dos a través de GitOps. Esto conduce a una co­la­bo­ra­ción mejor y más fácil, al igual que permite a los nuevos empleados empezar a trabajar más rá­pi­da­me­n­te.

• Se­pa­ra­ción de CI y CD: Debido a la estricta se­pa­ra­ción entre CI y CD en el enfoque GitOps, puede ser difícil realizar pruebas después de ser de­s­ple­ga­do.
• Resumen: Es­pe­cia­l­me­n­te cuando se trabaja con múltiples entornos, puede resultar confuso utilizar GitOps. Los numerosos re­po­si­to­rios y co­n­fi­gu­ra­cio­nes pueden co­n­tri­buir a esa confusión.