Cualquiera que convierta un entorno de Kubernetes a GitOps necesita un operador adecuado. Las principales opciones son Argo CD y Flux. Diseñar el proceso GitOps de la empresa también es fundamental. El editor temático de iX, Johannes Schnatterer, explica en una entrevista lo que es importante.
Publicidad
Johannes Schnatterer se encarga de desarrollo, operaciones, formación y consultoría en Cloudogu. Su enfoque actual está en la nube, contenedores, entrega continua y GitOps.
Los operadores de GitOps ofrecen funciones como Argo CD y Flux. ¿Sigue siendo fundamentalmente diferenciable de alguna manera? ¿Qué diferencia podría haber a favor de una herramienta u otra?
En realidad, hay muchas diferencias menores. Pero la mayoría de ellos no son adecuados para mucha gente. Una regla general es que Argo CD está dirigido a usuarios finales y Flux es fácil de integrar con otros productos. Como muestra el artículo, ambos ofrecen la posibilidad de usos opuestos.
En mi experiencia, suele ser apropiado que Argo CD venga con una interfaz integrada y funciones de plantillas (ApplicationSets). Para muchos, Flux parece liviano y nativo de Kubernetes, fácil de instalar y actualizar, y proporciona una excelente experiencia de usuario para Helm. También innova en apoyo de los registros OCI y Terraform.
Sin embargo, pongamos algunos de estos puntos en perspectiva. Por ejemplo, Argo CD Core es una configuración liviana de Argo CD y WeaveWorks ofrece una variedad de interfaces de usuario para Flux.
¿Qué pasos adicionales se requieren al diseñar su propio proceso GitOps?
Conocer los requisitos es fundamental para elegir el operador adecuado, por ejemplo, ¿quieres utilizar aplicaciones o infraestructura? ¿Qué estructuras de comunicación existen en sus instalaciones? ¿Cuántos grupos, proyectos, departamentos o aplicaciones tienes? ¿Qué infraestructura tienes o quieres tener, como por ejemplo un cluster de Kubernetes? ¿Qué ambientes o puestos tienes? ¿Cuál es el cambio (promoción) entre ellos? ¿Quiere crear entornos de vista previa a corto plazo basados en solicitudes de extracción? Estas consideraciones ayudan a seleccionar un operador y cerrar la brecha de GitOps para mapear el mundo real a la infraestructura.
Publicidad
¿Hay ayuda con esto o cada uno tiene que descubrir por sí mismo cómo diseñar su proceso GitOps?
En general, no existe un estándar intencional para un proceso GitOps porque, según la Ley de Conway, depende de la arquitectura de comunicación de una organización. Sin embargo, a partir de la experiencia se pueden identificar algunos patrones consistentes. Aparte de la decisión por operador, queda pendiente la configuración de repositorios, promoción entre entornos, número de operadores y cableado de operadores.
Señor. Schnatterer, ¡muchas gracias por las respuestas! Un artículo de portada sobre New iX proporciona una comparación detallada entre Argo CD y Flux, mientras que otro proporciona patrones prácticos de GitOps. Además, la edición de septiembre Disponible inmediatamenteUna mirada más cercana a la herramienta forense y de fusión de la nube de Microsoft, Velociraptor.
En la serie «Tres preguntas y respuestas», iX quiere llegar al corazón de los desafíos actuales de TI, ya sea la vista del usuario frente a la PC, la vista del gerente o la vida cotidiana de un ejecutivo. ¿Tiene recomendaciones de su práctica diaria o de sus usuarios? ¿De quién son las notas sobre qué tema le gustaría leer brevemente? Entonces escríbanos o comente en el foro.
(javo)
«Amante de los viajes extremos. Fanático del tocino. Alborotador. Introvertido. Apasionado fanático de la música».
