En las primeras fases del diseño o la implantación de GitOps, puede resultar desalentador pensar en las distintas herramientas y prácticas que puede necesitar. Quieres estar seguro de que estás diseñando un flujo de trabajo robusto y escalable para gestionar la infraestructura y los despliegues de aplicaciones. Y no querrás incorporar nada que complique en exceso los procesos o dificulte la liberación de cambios de código por parte de tu equipo.
Una forma de limitar su enfoque es buscar herramientas y prácticas que respalden sus prácticas de implantación. La principal consideración es si utilizas un enfoque basado en push o en pull. Ambos tienen sus pros y sus contras, y el que utilices afectará a las herramientas y procesos que incluyas en tu estrategia de GitOps.
Automatización de flujos de trabajo e infraestructura
En primer lugar, repasemos dos prácticas fundamentales de DevOps: La infraestructura como código (IaC) y la automatización con integración continua y entrega continua (CI/CD).
IaC es una técnica para desplegar y gestionar infraestructuras mediante código en lugar de una serie de pasos manuales o procesos interactivos. Este enfoque no se limita únicamente a primitivas de infraestructura o servicios gestionados en la nube, sino que es aplicable a todos los aspectos gestionables, como archivos de configuración, instalaciones de software, políticas de red y seguridad, etc. Comúnmente conocido como "X as Code", este tipo de gestión unificada proporciona un estado deseado planificado y documentado para su despliegue.
CI/CD es una metodología y un conjunto de prácticas comunes que permiten a los desarrolladores entregar de forma rápida y fiable aplicaciones de calidad y codificadas de forma segura. Adoptar CI/CD es adoptar una cultura en la que los equipos de desarrollo pueden centrarse en los requisitos de la empresa y del usuario final aplicando la automatización en las fases adecuadas del ciclo de vida del desarrollo de software.
En el desarrollo de software, la integración es el proceso de introducir cambios en el código de un repositorio. La integración continua (IC) es el proceso de validación automática de los cambios mediante la creación, comprobación y empaquetado del código actualizado de la aplicación de forma fiable y coherente. La activación de un flujo de trabajo CI en cada evento push proporciona un proceso de desarrollo más fluido y rápido, ya que los errores, las vulnerabilidades de seguridad y los conflictos se pueden descubrir antes de que los cambios se desplieguen en un entorno.
Un flujo de trabajo de entrega continua (CD) toma el relevo tras la finalización satisfactoria del flujo de trabajo de CI. Puede tratarse de un flujo de trabajo que facilite el despliegue de la aplicación directamente en los servidores de montaje o producción, o el envío de una nueva versión a un registro de contenedores o a una plataforma de distribución móvil.
Se trata de temas centrales en torno a la automatización de los flujos de trabajo de los desarrolladores. Un enfoque GitOps se basa en estas prácticas DevOps básicas y las pone en funcionamiento. Al aprovechar un repositorio git como única fuente de verdad para los archivos de definición de IaC y utilizar canalizaciones de automatización, puede controlar de forma eficaz la versión del estado deseado de su infraestructura.
Aquí es donde volvemos a tus prácticas de despliegue: decidir si lo mejor para tu aplicación y estrategia GitOps es push o pull.
Comparación entre arquitectura push y pull
Push-based, o sin agente, es el enfoque más tradicional en el que los cambios son empujados al entorno seleccionado por un cliente CI/CD externo como Jenkins o CircleCI. Esto puede ser preferible para entornos que no sean Kubernetes, o entornos con una mezcla de tipos de carga de trabajo que harían que la ejecución de agentes y webhooks separados en cada componente fuera engorrosa.
Pros:
- Más fácil de implantar en varios tipos de cargas de trabajo en un único entorno.
- Estandarización de la metodología de despliegue entre distintos entornos (es decir, nativos de la nube y locales).
- Flexibilidad de las herramientas, ya que la mayoría de los marcos de trabajo de CI/CD utilizan un modelo basado en la inserción.
Contras:
- El cliente CI/CD no tiene capacidad de observación para saber si los cambios se desplegaron correctamente o si se produjeron problemas en el lado del servidor como resultado.
- Puede que sea necesario instalar herramientas adicionales (por ejemplo, kubectl, Helm, Docker, Ansible, Terraform, SSH) para que el cliente CI/CD despliegue los cambios.
- Requiere dar al cliente de CI/CD acceso externo al entorno, lo que aumenta el riesgo de problemas de seguridad y cumplimiento.
El enfoque basado en pull o en agentes funciona en la dirección opuesta, haciendo que el entorno forme parte del proceso de CD. Un agente u operador vigila el repositorio git en busca de cambios, los extrae y los aplica. Esta tarea también se realiza cada vez que el agente detecta una desviación de la configuración de la única fuente de verdad. Este enfoque funciona especialmente bien con entornos nativos de Kubernetes.
Pros:
- El agente/operador tiene capacidad de observación sobre el estado actual del entorno y el estado de despliegue.
- Mejor seguridad y cumplimiento simplificado porque el entorno sólo requiere permiso para ver la fuente.
- Detección rápida de desviaciones de la configuración debidas a la intervención humana manual o a otras fuentes.
Contras:
- Más complejo para despliegues que no sean Kubernetes.
- Requiere herramientas diseñadas para trabajar con tipos de entorno específicos.
Cuando empieces a planificar tu estrategia de GitOps, considera cómo las diferentes estrategias de despliegue darán soporte a tu aplicación. Tanto los enfoques basados en push como en pull tienen sus ventajas y son adecuados para diferentes escenarios. Hay muchas herramientas y prácticas a tener en cuenta, y con algo de perspectiva sabrás cuál es la solución adecuada para tu equipo y tu pila.
¿Busca más información? Descargue nuestro libro electrónico gratuito Estrategia GitOps u obtenga una consulta gratuita con un experto en cloud computing de Akamai.
Comentarios