Fundamentos de GitOps: La Base del Desarrollo Moderno

Flux: La Evolución Continua del GitOps

Arquitectura y Componentes de

Configuración Práctica de

ArgoCD: Potencia y Flexibilidad en la Entrega Continua

Arquitectura y Componentes de ArgoCD

Instalación y Configuración de ArgoCD

Comparación Detallada: Flux vs ArgoCD

Experiencia de Usuario y Interfaces

Escalabilidad y Rendimiento

Modelo de Seguridad y Autenticación

Capacidades de Multi-tenancy

Casos de Uso y Mejores Prácticas

Cuándo Elegir

Cuándo Elegir ArgoCD

Implementación de Estrategias Avanzadas

Gestión Multi-Cluster con

Progressive Delivery con ArgoCD

Monitoreo y Observabilidad

Métricas y Alertas en

Dashboard y Alertas en ArgoCD

Consideraciones de Migración y Coexistencia

Migración de ArgoCD a

Estrategias de Coexistencia

Futuro de GitOps y Herramientas Emergentes

Conclusión

Recursos Adicionales GitOps se ha establecido como uno de los paradigmas más revolucionarios en el mundo del desarrollo y operaciones de software moderno. Esta metodología, que utiliza Git como fuente única de verdad para la configuración y el estado deseado de la infraestructura, ha transformado la manera en que los equipos DevOps gestionan y despliegan aplicaciones en entornos de contenedores y Kubernetes. En este contexto, dos herramientas han emergido como líderes indiscutibles en el ecosistema GitOps: Flux y ArgoCD. Ambas plataformas ofrecen capacidades robustas para implementar flujos de trabajo GitOps, pero cada una tiene sus propias fortalezas, características distintivas y casos de uso óptimos. Esta guía completa explora en profundidad ambas herramientas, proporcionando una comparación detallada y ejemplos prácticos para ayudarte a tomar la mejor decisión para tu organización. GitOps es más que una simple metodología; es una filosofía operativa que revoluciona la manera en que gestionamos infraestructuras y aplicaciones. Los principios fundamentales de GitOps establecen que todo el estado deseado del sistema debe estar declarado en Git, que Git debe ser la fuente única de verdad, y que los cambios deben ser aplicados de manera automática y auditables. El paradigma GitOps se basa en cuatro principios esenciales. Primero, la descripción declarativa del sistema completo debe estar versionada en Git, desde la configuración de aplicaciones hasta los manifiestos de infraestructura. Segundo, el estado canónico deseado debe estar versionado en Git, proporcionando un historial completo y auditable de todos los cambios. Tercero, los cambios aprobados pueden ser aplicados automáticamente al sistema, eliminando la necesidad de intervención manual y reduciendo significativamente los errores operacionales. Cuarto, los agentes de software deben asegurar la correctitud y alertar sobre cualquier divergencia entre el estado actual y el deseado. Esta metodología ofrece beneficios transformadores para las organizaciones. La auditabilidad completa se logra mediante el historial de Git, donde cada cambio está documentado y puede ser rastreado hasta su origen. La seguridad se ve reforzada porque no se requiere acceso directo a los clusters de producción; los desarrolladores pueden realizar cambios mediante pull requests que son revisados antes de ser aplicados. La velocidad de desarrollo aumenta significativamente al automatizar los procesos de despliegue y reducir la carga operacional en los equipos de desarrollo. Flux representa la segunda generación de herramientas GitOps, desarrollada por Weaveworks y ahora mantenida por la Cloud Native Computing Foundation (CNCF) como proyecto graduado. Flux v2 es una reescritura completa que adopta una arquitectura modular y extensible, diseñada específicamente para ser cloud-native y altamente escalable. Flux v2 se compone de varios controladores especializados que trabajan en conjunto para proporcionar capacidades GitOps completas. El Source Controller gestiona los recursos de origen, incluyendo repositorios Git, buckets S3 y repositorios Helm. Este controlador es responsable de detectar cambios en las fuentes y notificar a otros componentes cuando nuevas versiones están disponibles. El Kustomize Controller se encarga de aplicar manifiestos de Kubernetes utilizando Kustomize, proporcionando capacidades avanzadas de personalización y gestión de configuraciones. Este controlador puede manejar dependencias complejas entre recursos y asegurar que los cambios se apliquen en el orden correcto. El Helm Controller gestiona releases de Helm, permitiendo la instalación, actualización y rollback de charts de manera declarativa. Integra perfectamente con repositorios de Helm y puede gestionar valores personalizados y configuraciones específicas del entorno. El Notification Controller proporciona capacidades de notificación y alertas, integrándose con sistemas como Slack, Discord, Microsoft Teams y webhooks personalizados. Este componente es crucial para mantener a los equipos informados sobre el estado de los despliegues y cualquier problema que pueda surgir. El Image Reflector y Image Automation Controllers trabajan juntos para automatizar las actualizaciones de imágenes de contenedores, detectando nuevas versiones y actualizando automáticamente los manifiestos en Git. La instalación de Flux v2 comienza con la preparación del entorno. Es esencial tener un cluster de Kubernetes funcional y acceso configurado a través de kubectl. También necesitas tener un token de acceso personal para GitHub, GitLab o el proveedor de Git que utilices. La configuración de un repositorio fuente es el siguiente paso crítico: Para implementar aplicaciones usando Kustomize, definimos un recurso Kustomization: ArgoCD, desarrollado originalmente por Intuit y ahora parte del proyecto Argo bajo la CNCF, se ha establecido como una de las plataformas GitOps más completas y maduras disponibles. Su interfaz web rica y su capacidad para gestionar aplicaciones complejas lo han convertido en la elección preferida para muchas organizaciones enterprise. ArgoCD sigue una arquitectura distribuida compuesta por varios componentes especializados. El ArgoCD Server proporciona la API y la interfaz web, sirviendo como punto de entrada principal para usuarios y administradores. Este componente maneja la autenticación, autorización y proporciona todas las funcionalidades de la interfaz gráfica. El Application Controller es el cerebro operativo de ArgoCD, monitoreando continuamente las aplicaciones configuradas y comparando el estado actual con el estado deseado definido en Git. Cuando detecta diferencias, puede automáticamente sincronizar los cambios o notificar a los usuarios según la configuración establecida. El Repository Server maneja las conexiones a los repositorios Git, clonando repositorios, generando manifiestos de Kubernetes y proporcionando capacidades de caché para mejorar el rendimiento. Este componente es crucial para la escalabilidad en entornos con múltiples repositorios y aplicaciones. El Redis Server proporciona almacenamiento en caché y capacidades de cola, mejorando significativamente el rendimiento y la responsividad de ArgoCD en despliegues grandes. El Dex Server gestiona la autenticación e integración con proveedores de identidad externos como LDAP, SAML, OAuth2 y OpenID Connect, permitiendo una integración perfecta con los sistemas de identidad corporativos existentes. La instalación de ArgoCD puede realizarse de múltiples maneras. El método más directo utiliza manifiestos YAML: Para configuración de producción, es recomendable personalizar la instalación: ArgoCD sobresale en la experiencia de usuario con su interfaz web rica e intuitiva. El dashboard proporciona visualizaciones detalladas del estado de las aplicaciones, incluyendo gráficos de dependencias, estados de recursos y capacidades de drill-down que permiten a los usuarios explorar cada componente de sus aplicaciones. La interfaz permite realizar operaciones como sincronización manual, rollbacks y gestión de configuraciones de manera visual e intuitiva. Flux, por el contrario, adopta un enfoque más minimalista y orientado a la línea de comandos. Aunque no proporciona una interfaz web nativa, esta simplicidad resulta en menor sobrecarga de recursos y mayor flexibilidad para integraciones personalizadas. Los equipos que prefieren herramientas de línea de comandos y automatización completa a menudo encuentran que Flux se alinea mejor con sus flujos de trabajo existentes. En términos de escalabilidad, Flux v2 demuestra ventajas significativas en entornos grandes debido a su arquitectura modular. Cada controlador puede escalarse independientemente, y la ausencia de una interfaz web reduce la carga en los recursos del cluster. Flux es particularmente eficiente en escenarios con múltiples clusters y repositorios, donde su diseño permite una gestión distribuida más efectiva. ArgoCD puede experimentar desafíos de rendimiento en despliegues muy grandes, especialmente cuando gestiona cientos o miles de aplicaciones. Sin embargo, las recientes mejoras en las versiones más nuevas han abordado muchos de estos problemas, y la implementación de características como Application Sets ha mejorado significativamente la capacidad de gestionar aplicaciones a escala. ArgoCD ofrece un modelo de seguridad más granular y robusto, con soporte nativo para RBAC (Role-Based Access Control) y integración con múltiples proveedores de identidad. Los administradores pueden definir políticas de acceso detalladas, controlando qué usuarios pueden ver, modificar o sincronizar aplicaciones específicas. Flux adopta un modelo de seguridad más simple, delegando principalmente en los mecanismos de RBAC de Kubernetes. Aunque esto puede resultar en menos granularidad, también significa menos complejidad y superficie de ataque reducida. ArgoCD proporciona capacidades de multi-tenancy más avanzadas a través de sus proyectos y sistemas de RBAC. Los administradores pueden crear proyectos separados para diferentes equipos, cada uno con sus propias políticas de acceso, repositorios permitidos y destinos de despliegue. Flux maneja multi-tenancy principalmente a través de namespaces de Kubernetes y configuraciones separadas por tenant, lo que requiere más configuración manual pero ofrece mayor flexibilidad en la implementación. Flux es la elección ideal para organizaciones que priorizan la simplicidad, la eficiencia de recursos y la automatización completa. Es particularmente adecuado para: Entornos con múltiples clusters donde la gestión distribuida es crítica. La arquitectura modular de Flux permite una gestión eficiente de resources across clusters sin la sobrecarga de interfaces gráficas. Equipos que prefieren herramientas de línea de comandos y flujos de trabajo completamente automatizados. Flux se integra perfectamente con scripts de automatización y pipelines de CI/CD existentes. Organizaciones que requieren la máxima eficiencia de recursos en sus clusters. La menor huella de Flux permite dedicar más recursos a las aplicaciones productivas. Escenarios donde la integración con herramientas de monitoreo y observabilidad personalizadas es prioritaria. Flux proporciona métricas detalladas y capacidades de integración flexibles. ArgoCD es la mejor opción para organizaciones que valoran la experiencia de usuario rica, las capacidades de gestión visual y los requisitos de seguridad granular: Equipos que incluyen desarrolladores y operadores que se benefician de interfaces visuales para comprender y gestionar aplicaciones complejas. La interfaz web de ArgoCD reduce significativamente la curva de aprendizaje. Organizaciones con requisitos estrictos de auditoría y compliance que necesitan capacidades de logging detalladas y trazabilidad visual de cambios. Entornos enterprise con múltiples equipos que requieren aislamiento estricto y control de acceso granular. Las capacidades de RBAC de ArgoCD son superiores para estos escenarios. Aplicaciones complejas con múltiples dependencias donde la visualización de relaciones es crucial para el debugging y la resolución de problemas. Esta implementación requiere atención a los detalles y seguimiento de las mejores prácticas. Flux v2 proporciona capacidades nativas para gestión multi-cluster a través de su arquitectura distribuida: ArgoCD se integra perfectamente con herramientas de progressive delivery como Argo Rollouts: Flux proporciona métricas detalladas en formato Prometheus que pueden ser utilizadas para monitoreo y alertas: ArgoCD proporciona capacidades nativas de monitoreo y puede integrarse con sistemas de alertas externos: Para organizaciones que consideran migrar de ArgoCD a Flux, el proceso debe ser gradual y cuidadosamente planificado: En algunos casos, puede ser beneficial utilizar ambas herramientas en diferentes contextos: El ecosistema GitOps continúa evolucionando con nuevas herramientas y estándares emergentes. El trabajo en la especificación GitOps de la OpenGitOps Working Group está estableciendo estándares que promoverán mayor interoperabilidad entre herramientas. Flux v3 está en desarrollo con mejoras en rendimiento, nuevas capacidades de multi-tenancy y mejor integración con el ecosistema cloud-native. ArgoCD continúa mejorando su escalabilidad y añadiendo nuevas características como Application Sets y mejor soporte para Helm. La elección entre Flux y ArgoCD no tiene una respuesta única correcta; depende fundamentalmente de los requisitos específicos, preferencias del equipo y contexto organizacional. Flux brilla en entornos que priorizan la eficiencia, automatización completa y simplicidad operacional. ArgoCD sobresale cuando la experiencia de usuario, capacidades de seguridad granular y gestión visual son prioritarias. Independientemente de la herramienta elegida, la adopción de GitOps representa un paso transformador hacia operaciones más confiables, auditables y eficientes. Ambas plataformas proporcionan bases sólidas para implementar prácticas GitOps maduras que pueden escalar con las necesidades de tu organización. La clave del éxito radica en comprender profundamente los principios de GitOps, evaluar cuidadosamente los requisitos específicos de tu entorno y elegir la herramienta que mejor se alinee con tus objetivos operacionales y culturales. Con cualquiera de estas herramientas, estarás bien equipado para navegar el futuro de la entrega de software y gestión de infraestructura. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Instalación de Flux CLI

curl -s https://fluxcd.io/install.sh | sudo bash

Verificación de prerequisitosflux check --pre

Configuración del repositorio y instalación

flux bootstrap github \ --owner=$GITHUB_USER \ --repository=fleet-infra \ --branch=main \ --path=./clusters/my-cluster \ --personal

Command

Copy

$

Instalación de Flux CLI

curl -s https://fluxcd.io/install.sh | sudo bash

Verificación de prerequisitosflux check --pre

Configuración del repositorio y instalación

flux bootstrap github \ --owner=$GITHUB_USER \ --repository=fleet-infra \ --branch=main \ --path=./clusters/my-cluster \ --personal

Command

Copy

$

Instalación de Flux CLI

curl -s https://fluxcd.io/install.sh | sudo bash

Verificación de prerequisitosflux check --pre

Configuración del repositorio y instalación

flux bootstrap github \ --owner=$GITHUB_USER \ --repository=fleet-infra \ --branch=main \ --path=./clusters/my-cluster \ --personal

Code Block

Copy

apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: GitRepository metadata: name: podinfo namespace: flux-system spec: interval: 30s ref: branch: master url: https://github.com/stefanprodan/podinfo apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: GitRepository metadata: name: podinfo namespace: flux-system spec: interval: 30s ref: branch: master url: https://github.com/stefanprodan/podinfo apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: GitRepository metadata: name: podinfo namespace: flux-system spec: interval: 30s ref: branch: master url: https://github.com/stefanprodan/podinfo apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization metadata: name: podinfo namespace: flux-system spec: interval: 5m path: "./kustomize" prune: true sourceRef: kind: GitRepository name: podinfo validation: client healthChecks: - apiVersion: apps/v1 kind: Deployment name: podinfo namespace: default apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization metadata: name: podinfo namespace: flux-system spec: interval: 5m path: "./kustomize" prune: true sourceRef: kind: GitRepository name: podinfo validation: client healthChecks: - apiVersion: apps/v1 kind: Deployment name: podinfo namespace: default apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization metadata: name: podinfo namespace: flux-system spec: interval: 5m path: "./kustomize" prune: true sourceRef: kind: GitRepository name: podinfo validation: client healthChecks: - apiVersion: apps/v1 kind: Deployment name: podinfo namespace: default

Crear namespace

kubectl create namespace argocd

Instalar ArgoCDkubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Obtener contraseña inicial del adminkubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Acceder a la interfaz web

kubectl port-forward svc/argocd-server -n argocd 8080:443

Command

Copy

$

Crear namespace

kubectl create namespace argocd

Instalar ArgoCDkubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Obtener contraseña inicial del adminkubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Acceder a la interfaz web

kubectl port-forward svc/argocd-server -n argocd 8080:443

Command

Copy

$

Crear namespace

kubectl create namespace argocd

Instalar ArgoCDkubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Obtener contraseña inicial del adminkubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Acceder a la interfaz web

kubectl port-forward svc/argocd-server -n argocd 8080:443

Code Block

Copy

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: project: default source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: project: default source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: project: default source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: GitRepository metadata: name: fleet-infra namespace: flux-system spec: interval: 1m ref: branch: main url: https://github.com/my-org/fleet-infra --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization metadata: name: staging-cluster namespace: flux-system spec: interval: 10m path: "./clusters/staging" prune: true sourceRef: kind: GitRepository name: fleet-infra --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization metadata: name: production-cluster namespace: flux-system spec: interval: 30m path: "./clusters/production" prune: true sourceRef: kind: GitRepository name: fleet-infra apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: GitRepository metadata: name: fleet-infra namespace: flux-system spec: interval: 1m ref: branch: main url: https://github.com/my-org/fleet-infra --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization metadata: name: staging-cluster namespace: flux-system spec: interval: 10m path: "./clusters/staging" prune: true sourceRef: kind: GitRepository name: fleet-infra --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization metadata: name: production-cluster namespace: flux-system spec: interval: 30m path: "./clusters/production" prune: true sourceRef: kind: GitRepository name: fleet-infra apiVersion: source.toolkit.fluxcd.io/v1beta1 kind: GitRepository metadata: name: fleet-infra namespace: flux-system spec: interval: 1m ref: branch: main url: https://github.com/my-org/fleet-infra --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization metadata: name: staging-cluster namespace: flux-system spec: interval: 10m path: "./clusters/staging" prune: true sourceRef: kind: GitRepository name: fleet-infra --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta1 kind: Kustomization metadata: name: production-cluster namespace: flux-system spec: interval: 30m path: "./clusters/production" prune: true sourceRef: kind: GitRepository name: fleet-infra apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: canary-app spec: project: default source: repoURL: https://github.com/my-org/canary-app targetRevision: HEAD path: k8s destination: server: https://kubernetes.default.svc namespace: default syncPolicy: automated: prune: true selfHeal: true --- apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: canary-rollout spec: replicas: 5 strategy: canary: steps: - setWeight: 20 - pause: {} - setWeight: 40 - pause: {duration: 10} - setWeight: 60 - pause: {duration: 10} - setWeight: 80 - pause: {duration: 10} selector: matchLabels: app: canary-app template: metadata: labels: app: canary-app spec: containers: - name: canary-app image: nginx:1.16 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: canary-app spec: project: default source: repoURL: https://github.com/my-org/canary-app targetRevision: HEAD path: k8s destination: server: https://kubernetes.default.svc namespace: default syncPolicy: automated: prune: true selfHeal: true --- apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: canary-rollout spec: replicas: 5 strategy: canary: steps: - setWeight: 20 - pause: {} - setWeight: 40 - pause: {duration: 10} - setWeight: 60 - pause: {duration: 10} - setWeight: 80 - pause: {duration: 10} selector: matchLabels: app: canary-app template: metadata: labels: app: canary-app spec: containers: - name: canary-app image: nginx:1.16 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: canary-app spec: project: default source: repoURL: https://github.com/my-org/canary-app targetRevision: HEAD path: k8s destination: server: https://kubernetes.default.svc namespace: default syncPolicy: automated: prune: true selfHeal: true --- apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: canary-rollout spec: replicas: 5 strategy: canary: steps: - setWeight: 20 - pause: {} - setWeight: 40 - pause: {duration: 10} - setWeight: 60 - pause: {duration: 10} - setWeight: 80 - pause: {duration: 10} selector: matchLabels: app: canary-app template: metadata: labels: app: canary-app spec: containers: - name: canary-app image: nginx:1.16 apiVersion: v1 kind: Service metadata: name: flux-metrics namespace: flux-system spec: selector: app: source-controller ports: - name: http-prom port: 8080 targetPort: 8080 --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: flux-system spec: selector: matchLabels: app: source-controller endpoints: - port: http-prom interval: 30s path: /metrics apiVersion: v1 kind: Service metadata: name: flux-metrics namespace: flux-system spec: selector: app: source-controller ports: - name: http-prom port: 8080 targetPort: 8080 --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: flux-system spec: selector: matchLabels: app: source-controller endpoints: - port: http-prom interval: 30s path: /metrics apiVersion: v1 kind: Service metadata: name: flux-metrics namespace: flux-system spec: selector: app: source-controller ports: - name: http-prom port: 8080 targetPort: 8080 --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: flux-system spec: selector: matchLabels: app: source-controller endpoints: - port: http-prom interval: 30s path: /metrics apiVersion: v1 kind: ConfigMap metadata: name: argocd-notifications-cm data: service.slack: | token: $slack-token template.app-deployed: | message: | {{if eq .serviceType "slack"}}:white_check_mark:{{end}} Application {{.app.metadata.name}} is now running new version. trigger.on-deployed: | - when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy' send: [app-deployed] apiVersion: v1 kind: ConfigMap metadata: name: argocd-notifications-cm data: service.slack: | token: $slack-token template.app-deployed: | message: | {{if eq .serviceType "slack"}}:white_check_mark:{{end}} Application {{.app.metadata.name}} is now running new version. trigger.on-deployed: | - when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy' send: [app-deployed] apiVersion: v1 kind: ConfigMap metadata: name: argocd-notifications-cm data: service.slack: | token: $slack-token template.app-deployed: | message: | {{if eq .serviceType "slack"}}:white_check_mark:{{end}} Application {{.app.metadata.name}} is now running new version. trigger.on-deployed: | - when: app.status.operationState.phase in ['Succeeded'] and app.status.health.status == 'Healthy' send: [app-deployed] #!/bin/bash

Script de migración gradual

1. Instalar Flux en paralelo

flux bootstrap github --owner=$GITHUB_USER --repository=fleet-infra

2. Migrar aplicaciones una por una

Convertir Application de ArgoCD a Kustomization de

argocd app get myapp -o yaml > argocd-app.yaml

Convertir manualmente a Flux Kustomization

3. Validar funcionamiento antes de eliminar de ArgoCD

flux get kustomizationsargocd app delete myapp

4. Desinstalar ArgoCD cuando todas las aplicaciones estén migradas

kubectl delete -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Command

Copy

#!/bin/bash

Script de migración gradual

1. Instalar Flux en paralelo

flux bootstrap github --owner=$GITHUB_USER --repository=fleet-infra

2. Migrar aplicaciones una por una

Convertir Application de ArgoCD a Kustomization de

argocd app get myapp -o yaml > argocd-app.yaml

Convertir manualmente a Flux Kustomization

3. Validar funcionamiento antes de eliminar de ArgoCD

flux get kustomizationsargocd app delete myapp

4. Desinstalar ArgoCD cuando todas las aplicaciones estén migradas

kubectl delete -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Command

Copy

#!/bin/bash

Script de migración gradual

1. Instalar Flux en paralelo

flux bootstrap github --owner=$GITHUB_USER --repository=fleet-infra

2. Migrar aplicaciones una por una

Convertir Application de ArgoCD a Kustomization de

argocd app get myapp -o yaml > argocd-app.yaml

Convertir manualmente a Flux Kustomization

3. Validar funcionamiento antes de eliminar de ArgoCD

flux get kustomizationsargocd app delete myapp

4. Desinstalar ArgoCD cuando todas las aplicaciones estén migradaskubectl delete -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml - Flux para automatización de infraestructura y aplicaciones críticas del sistema- ArgoCD para aplicaciones de desarrollo donde la interfaz visual es valorada- Separación por equipos o proyectos según las preferencias y requisitos específicos - Documentación oficial de Flux- Documentación oficial de ArgoCD- OpenGitOps Principles- CNCF GitOps Working Group- Flux vs ArgoCD: Comparación detallada- GitOps Toolkit