🥇GitOps: comparación de los métodos Pull y Push

Nota de traducción.: En la comunidad de Kubernetes, está ganando una notable popularidad una tendencia llamada GitOps, de la que nos convencimos personalmente, al asistir a KubeCon Europe 2019. Este término fue creado relativamente recientemente por el fundador de Weaveworks, Alexis Richardson, y se refiere a la aplicación de herramientas familiares para los desarrolladores (principalmente Git, de donde proviene su nombre) para abordar tareas de operación. En particular, se trata de operar Kubernetes almacenando sus configuraciones en Git y desplegando automáticamente cambios en el clúster. Matthias Jg explica en este artículo dos enfoques para este despliegue. El año pasado

GitOps: comparación de métodos Pull y Push

(de hecho, formalmente ocurrió en agosto de 2017 - nota del traductor) apareció un nuevo enfoque para el despliegue de aplicaciones en Kubernetes. Se llama GitOps, y se basa en la idea fundamental de que el seguimiento de versiones de despliegues se realiza en un entorno seguro de repositorio Git. Las principales ventajas de este enfoque son las siguientes

Versionado de despliegues e historial de cambios:

. El estado de todo el clúster se almacena en un repositorio Git, y los despliegues solo se actualizan a través de commits. Además, todos los cambios se pueden rastrear mediante el historial de commits.Reversiones utilizando los comandos Git familiares
. Un simplegit reset permite revertir cambios en los despliegues; siempre hay estados anteriores disponibles. Control de acceso listo
. Por lo general, un sistema Git contiene muchos datos confidenciales, por lo que la mayoría de las empresas prestan especial atención a su protección. Por lo tanto, esta protección se extiende también a las operaciones con despliegues.Políticas para despliegues
. La mayoría de los sistemas Git inicialmente soportan políticas para diferentes ramas, por ejemplo, solo los pull requests pueden actualizar el master, y otro miembro del equipo debe revisar y aprobar los cambios. Al igual que con el control de acceso, las mismas políticas se aplican a las actualizaciones de los despliegues.Como pueden ver, el método GitOps tiene muchas ventajas. En el último año, han cobrado especial popularidad dos enfoques. Uno se basa en push, el otro en pull. Antes de analizarlos, veamos primero cómo son los despliegues típicos de Kubernetes.

Métodos de despliegue

En los últimos años, han surgido varios métodos y herramientas para despliegues en Kubernetes:

Basados en plantillas nativas de Kubernetes/Kustomize

На основе родных шаблонов Kubernetes/Kustomize. Esta es la forma más sencilla de desplegar aplicaciones en Kubernetes. El desarrollador crea archivos YAML básicos y los aplica. Para evitar reescribir constantemente las mismas plantillas, se desarrolló Kustomize (que convierte las plantillas de Kubernetes en módulos). Nota de traducción.: Kustomize se ha integrado en kubectl con el lanzamiento de Kubernetes 1.14.
Chartes de Helm. Los Chartes de Helm permiten crear conjuntos de plantillas, contenedores init, sidecars, etc., que se utilizan para desplegar aplicaciones con opciones de configuración más flexibles que el enfoque basado en plantillas. Este método se basa en archivos YAML parametrizados. Helm los llena con varios parámetros y luego los envía a Tiller, un componente del clúster que los despliega en el clúster y permite actualizaciones y retrocesos. Lo importante es que, en esencia, Helm simplemente inserta los valores necesarios en las plantillas y luego las aplica de la misma manera que se hace en el enfoque tradicional. (para más información sobre cómo funciona todo esto y cómo se puede usar, lea nuestro artículo sobre Helm — nota del traductor). Hay una gran variedad de Chartes de Helm listos que abarcan un amplio espectro de tareas.
Herramientas alternativas. Hay muchas herramientas alternativas. Todas ellas comparten el hecho de que convierten algunos archivos de plantilla en comprensibles archivos YAML de Kubernetes y luego los aplican.

En nuestro trabajo, usamos constantemente los Chartes de Helm para herramientas importantes (ya que muchos de ellos ya están listos, lo que simplifica mucho la vida) y archivos YAML 'limpios' de Kubernetes para desplegar nuestras propias aplicaciones.

Pull & Push

En una de sus publicaciones recientes en el blog, presenté la herramienta Weave Flux, que permite hacer commit de plantillas en un repositorio Git y actualizar el despliegue después de cada commit o push del contenedor. Mi experiencia muestra que esta herramienta es una de las principales en la promoción del enfoque pull, así que me referiré a ella con frecuencia. Si desea saber más sobre cómo usarla, aquí está el enlace al artículo.

NB! Todas las ventajas del uso de GitOps se mantienen para ambos enfoques.

Enfoque basado en Pull

GitOps: comparación de métodos Pull y Push

La base del enfoque pull radica en el hecho de que todos los cambios se aplican desde dentro del clúster. Dentro del clúster hay un operador que verifica regularmente los repositorios de Git y el Docker Registry relacionados. Si hay algún cambio en ellos, el estado del clúster se actualiza desde adentro. Por lo general, se considera que este proceso es bastante seguro, ya que ningún cliente externo tiene acceso a los derechos de administrador del clúster.

Pros:

Ningún cliente externo tiene derechos para realizar cambios en el clúster; todas las actualizaciones se implementan desde adentro.
Algunas herramientas también permiten sincronizar actualizaciones de Helm charts y vincularlas al clúster.
Se puede escanear el Docker Registry en busca de nuevas versiones. Si aparece una nueva imagen, el repositorio de Git y el despliegue se actualizan a la nueva versión.
Las herramientas pull pueden estar distribuidas en diferentes espacios de nombres con diferentes repositorios de Git y derechos de acceso. Esto permite aplicar un modelo multicliente (multitenant). Por ejemplo, el equipo A puede usar el espacio de nombres A, el equipo B utiliza el espacio de nombres B, y el equipo encargado de la infraestructura puede usar un espacio global.
Por lo general, las herramientas son bastante ligeras.
En combinación con herramientas como el operador Bitnami Sealed Secrets, los secretos pueden almacenarse encriptados en el repositorio de Git y ser extraídos dentro del clúster.
No hay conexión con las canalizaciones de CD, ya que los despliegues ocurren dentro del clúster.

Desventajas:

Gestionar secretos de despliegues a partir de Helm charts es más complicado que con los secretos normales, ya que primero deben generarse en forma de, digamos, sealed secrets, luego ser desencriptados por el operador interno y solo después de esto se vuelven accesibles para la herramienta pull. Luego, se puede lanzar una versión en Helm con los valores de los secretos ya desplegados. La forma más sencilla es crear un secreto con todos los valores de Helm utilizados para el despliegue, desencriptarlo y hacer un commit en Git.
Al aplicar un enfoque pull, te ves atado a herramientas que operan con pulls. Esto limita la capacidad de personalizar el proceso de implementación de despliegues en el clúster. Por ejemplo, trabajar con Kustomize se complica porque debe ejecutarse antes de que las plantillas finales lleguen a Git. No digo que no se puedan usar herramientas independientes, pero son más difíciles de integrar en el proceso de implementación.

Enfoque basado en Push

GitOps: comparación de métodos Pull y Push

En el enfoque push, un sistema externo (principalmente tuberías CD) inicia despliegues en el clúster después de un commit en el repositorio de Git o en caso de que una tubería CI anterior se ejecute con éxito. En este enfoque, el sistema tiene acceso al clúster.

Ventajas:

La seguridad está definida por el repositorio de Git y la tubería de construcción.
Es más fácil desplegar gráficos de Helm, hay soporte para plugins de Helm.
Es más sencillo gestionar secretos, ya que se pueden aplicar en las tuberías y también almacenar en Git de manera cifrada (dependiendo de las preferencias del usuario).
No hay dependencia de una herramienta específica, ya que se pueden utilizar cualquier tipo de ellas.
Las actualizaciones de versiones de contenedores pueden ser iniciadas por la tubería de construcción.

Desventajas:

Los datos de acceso al clúster se encuentran dentro del sistema de construcción.
La actualización de los contenedores de los despliegues sigue siendo más fácil de realizar con un proceso pull.
Fuerte dependencia del sistema CD, ya que las tuberías necesarias pueden haber sido inicialmente escritas para Gitlab Runners, y luego el equipo decide migrar a Azure DevOps o Jenkins… y habrá que realizar una migración de un gran número de tuberías de construcción.

Conclusiones: ¿Push o Pull?

Como suele suceder, cada enfoque tiene sus ventajas y desventajas. Algunas tareas son más fáciles de realizar con uno y más difíciles con otro. Al principio, realizaba implementaciones manualmente, pero tras encontrar varios artículos sobre Weave Flux, decidí adoptar procesos GitOps para todos los proyectos. Para las plantillas básicas esto resultó fácil, pero luego empecé a enfrentar dificultades al trabajar con gráficos de Helm. En ese momento, Weave Flux solo ofrecía una versión incipiente del Helm Chart Operator, pero incluso ahora algunas tareas son más complicadas debido a la necesidad de crear secretos manualmente y aplicarlos. Se podría argumentar que el enfoque pull es mucho más seguro, ya que las credenciales del clúster no están disponibles fuera de él, lo que aumenta la seguridad lo suficiente como para justificar el esfuerzo adicional.

Reflexionando un poco, llegué a una conclusión inesperada: no es así. En cuanto a los componentes que requieren máxima protección, en esta lista entrarían los almacenes de secretos y los sistemas de CI/CD, así como los repositorios de Git. La información dentro de ellos es bastante vulnerable y necesita la máxima protección. Además, si alguien logra infiltrarse en tu repositorio de Git y puede hacer push de código allí, podrá desplegar lo que desee (independientemente del enfoque elegido, ya sea pull o push) e infiltrarse en los sistemas del clúster. Por lo tanto, los componentes más críticos que requieren protección son el repositorio de Git y los sistemas de CI/CD, no las credenciales del clúster. Si tienes bien configuradas las políticas y medidas de seguridad para sistemas de este tipo, y las credenciales del clúster se extraen en los pipelines solo como secretos, la seguridad adicional que ofrece el enfoque pull puede no ser tan valiosa como se pensaba inicialmente.

Entonces, si el enfoque pull es más laborioso y no ofrece una ventaja en seguridad, ¿no sería lógico usar solo el enfoque push? Pero alguien podría argumentar que en el enfoque push estás demasiado atado al sistema de CD y, quizás, sería mejor evitarlo para facilitar futuras migraciones.

En mi opinión (como siempre), hay que usar lo que mejor se adapte a cada caso o combinarlos. Personalmente, utilizo ambos enfoques: Weave Flux para implementaciones basadas en pull, que principalmente incluyen nuestros propios servicios, y el enfoque push con Helm y complementos, que simplifica la aplicación de gráficos de Helm al clúster y permite crear secretos sin problemas. Creo que nunca habrá una única solución adecuada para todos los casos, ya que siempre hay muchos matices que dependen de la situación particular. Al mismo tiempo, recomiendo encarecidamente GitOps: facilita mucho la vida y aumenta la seguridad.

Espero que mi experiencia sobre este tema ayude a determinar qué método es más adecuado para su tipo de implementaciones, y estaré encantado de conocer su opinión.

P.D. Nota del traductor

En las desventajas del modelo pull hay un punto sobre lo difícil que es poner en Git los manifiestos renderizados, sin embargo, no hay desventaja en que el pipeline de CD en el modelo pull vive por separado del despliegue y esencialmente se convierte en un pipeline de la categoría Continuous Apply. Por lo tanto, se requerirá aún más esfuerzo para recopilar el estado de todas las implementaciones y dar acceso a los registros/estado, preferiblemente vinculado al sistema de CD.

En este sentido, el modelo push permite ofrecer algunas garantías de despliegue, ya que la duración del pipeline se puede igualar a la duración del despliegue.

Hemos probado ambos modelos y llegamos a las mismas conclusiones que el autor del artículo:

El modelo pull es adecuado para organizar la actualización de componentes del sistema en un gran número de clústeres (ver el artículo sobre addon-operator).
El modelo push basado en GitLab CI es adecuado para desplegar aplicaciones utilizando gráficos de Helm. Además, el despliegue de implementaciones dentro de los pipelines se rastrea utilizando la herramienta werf. Cabe mencionar que en el contexto de este proyecto, escuchamos constantemente «GitOps» cuando discutíamos los problemas urgentes de los ingenieros DevOps en nuestro stand en KubeCon Europe'19.