GitOps: comparación de métodos pull y push

Nota. traducir: En la comunidad de Kubernetes, una tendencia llamada GitOps está ganando popularidad, como hemos visto personalmente, visitando KubeCon Europe 2019. Este término fue relativamente reciente acuñado por el director de Weaveworks, Alexis Richardson, y significa el uso de herramientas familiares para los desarrolladores (principalmente Git, de ahí el nombre) para resolver problemas operativos. En particular, estamos hablando del funcionamiento de Kubernetes almacenando sus configuraciones en Git e implementando cambios automáticamente en el clúster. Matthias Jg habla de dos enfoques para esta implementación en este artículo.

El año pasado, (de hecho, formalmente esto sucedió en agosto de 2017 - aprox. traducción.) Existe un nuevo enfoque para implementar aplicaciones en Kubernetes. Se llama GitOps y se basa en la idea básica de que las versiones de implementación se rastrean en el entorno seguro de un repositorio Git.

Las principales ventajas de este enfoque son las siguientes::

1. Versiones de implementación e historial de cambios. El estado de todo el clúster se almacena en un repositorio Git y las implementaciones se actualizan únicamente mediante confirmaciones. Además, se pueden realizar un seguimiento de todos los cambios mediante el historial de confirmaciones.
2. Reversiones usando comandos familiares de Git... Llanura git reset le permite restablecer los cambios en las implementaciones; Los estados pasados ​​siempre están disponibles.
3. Control de acceso listo. Normalmente, un sistema Git contiene una gran cantidad de datos confidenciales, por lo que la mayoría de las empresas prestan especial atención a protegerlos. En consecuencia, esta protección también se aplica a las operaciones con despliegues.
4. Políticas para implementaciones. La mayoría de los sistemas Git admiten de forma nativa políticas rama por rama; por ejemplo, solo las solicitudes de extracción pueden actualizar el maestro y los cambios deben ser revisados ​​y aceptados por otro miembro del equipo. Al igual que con el control de acceso, se aplican las mismas políticas a las actualizaciones de implementación.

Como puede ver, el método GitOps tiene muchos beneficios. Durante el año pasado, dos enfoques ganaron especial popularidad. Uno se basa en empujar y el otro en tirar. Antes de analizarlos, veamos primero cómo son las implementaciones típicas de Kubernetes.

Métodos de implementación

En los últimos años, se han establecido en Kubernetes varios métodos y herramientas para implementaciones:

1. Basado en plantillas nativas de Kubernetes/Kustomize. Esta es la forma más sencilla de implementar aplicaciones en Kubernetes. El desarrollador crea los archivos YAML básicos y los aplica. Para deshacerse de reescribir constantemente las mismas plantillas, se desarrolló Kustomize (convierte las plantillas de Kubernetes en módulos). Nota. traducir: Kustomize se ha integrado en kubectl con lanzamiento de Kubernetes 1.14.
2. Cartas de timón. Los gráficos de timón le permiten crear conjuntos de plantillas, contenedores de inicio, sidecars, etc., que se utilizan para implementar aplicaciones con opciones de personalización más flexibles que en un enfoque basado en plantillas. Este método se basa en archivos YAML con plantilla. Helm los llena con varios parámetros y luego los envía a Tiller, un componente del clúster que los implementa en el clúster y permite actualizaciones y reversiones. Lo importante es que Helm básicamente simplemente inserta los valores deseados en las plantillas y luego los aplica de la misma manera que lo hace en el enfoque tradicional. (lea más sobre cómo funciona todo y cómo puede usarlo en nuestro artículo de timón - aprox. trad.). Existe una amplia variedad de gráficos Helm ya preparados que cubren una amplia gama de tareas.
3. Herramientas alternativas. Hay muchas herramientas alternativas. Lo que todos tienen en común es que convierten algunos archivos de plantilla en archivos YAML legibles por Kubernetes y luego los usan.

En nuestro trabajo, utilizamos constantemente gráficos de Helm para herramientas importantes (ya que ya tienen muchas cosas listas, lo que hace la vida mucho más fácil) y archivos YAML de Kubernetes "puros" para implementar nuestras propias aplicaciones.

Tirar y empujar

En una de mis publicaciones recientes en el blog, presenté la herramienta. Flujo de tejido, que le permite enviar plantillas al repositorio de Git y actualizar la implementación después de cada confirmación o envío del contenedor. Mi experiencia demuestra que esta herramienta es una de las principales para promover el enfoque pull, por lo que me referiré a ella con frecuencia. Si quieres saber más sobre cómo usarlo, aquí enlace del artículo.

NB! Todos los beneficios de usar GitOps siguen siendo los mismos para ambos enfoques.

Enfoque basado en pull

El enfoque pull se basa en el hecho de que todos los cambios se aplican desde dentro del clúster. Hay un operador dentro del clúster que verifica periódicamente los repositorios asociados de Git y Docker Registry. Si se les produce algún cambio, el estado del clúster se actualiza internamente. Generalmente, este proceso se considera muy seguro, ya que ningún cliente externo tiene acceso a los derechos de administrador del clúster.

Pros:

1. Ningún cliente externo tiene derechos para realizar cambios en el clúster; todas las actualizaciones se implementan desde dentro.
2. Algunas herramientas también le permiten sincronizar las actualizaciones de los gráficos de Helm y vincularlas al clúster.
3. Docker Registry se puede escanear en busca de nuevas versiones. Si hay una nueva imagen disponible, el repositorio y la implementación de Git se actualizan a la nueva versión.
4. Las herramientas de extracción se pueden distribuir en diferentes espacios de nombres con diferentes permisos y repositorios de Git. Gracias a esto se puede utilizar un modelo multiinquilino. Por ejemplo, el equipo A podría usar el espacio de nombres A, el equipo B podría usar el espacio de nombres B y el equipo de infraestructura podría usar el espacio global.
5. Por regla general, las herramientas son muy ligeras.
6. Combinado con herramientas como operador Secretos sellados de Bitnami, los secretos se pueden almacenar cifrados en un repositorio Git y recuperarse dentro del clúster.
7. No hay conexión con las canalizaciones de CD ya que las implementaciones se producen dentro del clúster.

Contras:

1. Administrar los secretos de implementación de los gráficos Helm es más difícil que los normales, ya que primero deben generarse en forma de, digamos, secretos sellados, luego un operador interno los descifra y solo después de eso están disponibles para la herramienta de extracción. Luego puede ejecutar la versión en Helm con los valores de los secretos ya implementados. La forma más sencilla es crear un secreto con todos los valores de Helm utilizados para la implementación, descifrarlo y enviarlo a Git.
2. Cuando adoptas un enfoque de tracción, te quedas atado a las herramientas de tracción. Esto limita la capacidad de personalizar el proceso de implementación en un clúster. Por ejemplo, Kustomize es complicado por el hecho de que debe ejecutarse antes de que las plantillas finales se envíen a Git. No digo que no pueda utilizar herramientas independientes, pero son más difíciles de integrar en su proceso de implementación.

Enfoque basado en push

En el enfoque push, un sistema externo (principalmente canalizaciones de CD) lanza implementaciones en el clúster después de una confirmación en el repositorio de Git o si la canalización de CI anterior tiene éxito. En este enfoque, el sistema tiene acceso al clúster.

Pros:

1. La seguridad está determinada por el repositorio de Git y el proceso de compilación.
2. La implementación de gráficos de Helm es más sencilla y admite complementos de Helm.
3. Los secretos son más fáciles de administrar porque se pueden usar en canalizaciones y también se pueden almacenar cifrados en Git (según las preferencias del usuario).
4. No existe conexión con una herramienta específica, ya que se puede utilizar cualquier tipo.
5. Las actualizaciones de la versión del contenedor pueden iniciarse mediante la canalización de compilación.

Contras:

1. Los datos de acceso al clúster están dentro del sistema de compilación.
2. Actualizar los contenedores de implementación es aún más fácil con un proceso de extracción.
3. Gran dependencia del sistema CD, ya que los pipelines que necesitamos pueden haber sido escritos originalmente para Gitlab Runners, y luego el equipo decide pasar a Azure DevOps o Jenkins... y tendrá que migrar una gran cantidad de pipelines de compilación.

Resultados: ¿Empujar o tirar?

Como suele ocurrir, cada enfoque tiene sus pros y sus contras. Algunas tareas son más fáciles de realizar con uno y más difíciles con otro. Al principio estaba haciendo implementaciones manualmente, pero después de encontrar algunos artículos sobre Weave Flux, decidí implementar procesos GitOps para todos los proyectos. Para las plantillas básicas esto fue fácil, pero luego comencé a tener dificultades con los gráficos de Helm. En ese momento, Weave Flux solo ofrecía una versión rudimentaria del Helm Chart Operador, pero incluso ahora algunas tareas son más difíciles debido a la necesidad de crear secretos manualmente y aplicarlos. Se podría argumentar que el enfoque de extracción es mucho más seguro porque no se puede acceder a las credenciales del clúster fuera del clúster, lo que lo hace mucho más seguro y vale la pena el esfuerzo adicional.

Después de pensarlo un poco, llegué a la inesperada conclusión de que esto no es así. Si hablamos de componentes que requieren la máxima protección, esta lista incluirá almacenamiento secreto, sistemas CI/CD y repositorios Git. La información que contienen es muy vulnerable y necesita la máxima protección. Además, si alguien ingresa a su repositorio Git y puede insertar código allí, puede implementar lo que quiera (ya sea pull o push) e infiltrarse en los sistemas del clúster. Por lo tanto, los componentes más importantes que deben protegerse son el repositorio Git y los sistemas CI/CD, no las credenciales del clúster. Si tiene políticas y controles de seguridad bien configurados para este tipo de sistemas, y las credenciales del clúster solo se extraen en canalizaciones como secretos, la seguridad adicional de un enfoque de extracción puede no ser tan valiosa como se pensaba originalmente.

Entonces, si el enfoque de extracción requiere más mano de obra y no proporciona un beneficio de seguridad, ¿no es lógico utilizar sólo el enfoque de inserción? Pero alguien podría argumentar que en el enfoque push uno está demasiado apegado al sistema CD y, tal vez, sea mejor no hacerlo para que sea más fácil realizar migraciones en el futuro.

En mi opinión (como siempre), conviene utilizar lo que sea más adecuado para un caso o combinación concreto. Personalmente, uso ambos enfoques: Weave Flux para implementaciones basadas en extracción que incluyen principalmente nuestros propios servicios, y el enfoque de inserción con Helm y complementos, que facilita la aplicación de gráficos de Helm al clúster y le permite crear secretos sin problemas. Creo que nunca habrá una solución única que se adapte a todos los casos, porque siempre hay muchos matices y dependen de la aplicación específica. Dicho esto, recomiendo ampliamente GitOps: hace la vida mucho más fácil y mejora la seguridad.

Espero que mi experiencia en este tema le ayude a decidir qué método es más adecuado para su tipo de implementación y me encantaría escuchar su opinión.

PD Nota del traductor

La desventaja del modelo pull es que es difícil colocar manifiestos renderizados en Git, pero no hay inconveniente en que la canalización de CD en el modelo pull viva separada del lanzamiento y esencialmente se convierta en una canalización de categorías. Aplicar continuamente. Por lo tanto, se requerirá un esfuerzo aún mayor para recopilar su estado de todas las implementaciones y de alguna manera proporcionar acceso a los registros/estado, preferiblemente con referencia al sistema de CD.

En este sentido, el modelo push nos permite ofrecer al menos algunas garantías de implementación, porque la vida útil de la canalización puede igualarse a la vida útil de la implementación.

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

1. El modelo pull nos sirve para organizar actualizaciones de componentes del sistema en una gran cantidad de clústeres (ver. artículo sobre operador de complementos).
2. El modelo push basado en GitLab CI es muy adecuado para implementar aplicaciones utilizando gráficos Helm. Al mismo tiempo, se monitorea el despliegue de implementaciones dentro de los oleoductos mediante la herramienta patio. Por cierto, en el contexto de este proyecto nuestro, escuchamos el constante "GitOps" cuando discutimos los problemas urgentes de los ingenieros de DevOps en nuestro stand en KubeCon Europe'19.

PPS del traductor

Lea también en nuestro blog:

• «Consejos y trucos de Kubernetes: transferir recursos que se ejecutan en un clúster a la administración de Helm 2";
• «Presentamos kubedog, una biblioteca para rastrear recursos de Kubernetes";
• «Ampliando y complementando Kubernetes (revisión y reportaje en vídeo)";
• «Consejos para crear flujos de trabajo personalizados en GitLab CI".

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Estás usando GitOps?

• Sí, enfoque de tracción

• Si, empuja

• Sí, tirar + empujar

• si, algo mas

• No

30 usuarios votaron. 10 usuarios se abstuvieron.

Fuente: habr.com