Solucionando el desafío de promoción de imágenes en múltiples entornos con ArgoCD

Promoción de imágenes en múltiples entornos con ArgoCD

Cuando se diseñan entornos en la nube, a menudo se recomienda configurar múltiples cuentas. Si bien este enfoque ofrece independencia de recursos, aislamiento, mejor seguridad, acceso y límites de facturación, también conlleva su propio conjunto de problemas. Uno de estos desafíos es promover y rastrear eficientemente aplicaciones entre diferentes entornos.

El enfoque de GitOps, junto con herramientas como ArgoCD y Kustomize, simplifica el seguimiento y la promoción. Sin embargo, a menudo se pasa por alto la promoción de imágenes. Muchas empresas adoptan un registro de imágenes compartido, pero pronto se llena de muchas versiones no utilizadas.

Este artículo explora un viaje reciente en el que examinamos el problema de promover imágenes y la solución innovadora que se adoptó, todo ello siguiendo los principios de GitOps.

Desafío

Recientemente, se presentó un escenario en el que una empresa que utiliza el registro ECR compartido estaba considerando migrar a registros ECR separados por razones de rentabilidad, mejor gobernanza y gestión del ciclo de vida optimizada.

• Conjunto de clasificadores Clasificador de votación
• Protege tus proyectos de Python Evita la invocación directa de setup.py para una máxima protección del código.
• Revelando el poder del ajuste de sesgo mejorando la precisión predictiva en conjuntos de datos desequilibrados

Aquí se muestra el estado actual de la infraestructura y los pipelines:

• Cada entorno tiene una cuenta de AWS dedicada con su propio clúster e instalación de ArgoCD.
• Se utiliza Kustomize para gestionar las diferencias de configuración entre los entornos.

├── infra  │   ├── charts/  └── overlays      ├── dev      │   ├── patch-image.yaml      └── production          ├── patch-image.yaml          └── patch-replicas.yaml

• Se utiliza Jenkins para construir continuamente nuevas imágenes en el entorno de desarrollo.

Sin embargo, ninguna de las herramientas proporcionadas de serie admite la promoción de imágenes entre registros ECR, lo que lleva a la exploración de soluciones innovadoras con algunas consideraciones.

Consideraciones:

• Promoción selectiva: El panorama de aplicaciones de la empresa está compuesto por múltiples módulos y equipos con diferentes plazos. Por lo tanto, es necesario admitir la promoción de imágenes solo para módulos seleccionados en cada versión.
• Almacenamiento optimizado: Los entornos como producción solo necesitan almacenar versiones de imágenes promovidas, reduciendo el desorden y optimizando el uso de recursos.
• Replicación de etiquetas y resúmenes de imágenes: La replicación de etiquetas y resúmenes de imágenes entre registros ECR es fundamental para la seguridad y la trazabilidad.

Soluciones potenciales

En un principio, se propusieron dos soluciones potenciales:

1. Replicación entre cuentas de ECR: ECR de AWS admite nativamente la replicación de imágenes entre dos cuentas. Sin embargo, hasta ahora no hay forma de filtrar las imágenes que se replican en función de ningún criterio. Como alternativa, AWS recomienda un diseño basado en eventos para replicar selectivamente imágenes en función de convenciones de nomenclatura de etiquetas. Sin embargo, dado que no sabemos qué versiones se promocionarán, requiere un paso adicional de cambio de etiqueta antes de la promoción.
2. Pipeline de promoción de Jenkins: Un pipeline de Jenkins que analiza los overlays de Kustomize en busca de etiquetas de imágenes y las replica de forma programática.

Ambas opciones son viables, pero introducen una capa adicional de complejidad en el proceso de promoción. Además, es necesario asegurarse de que las imágenes se promocionen antes de que se actualicen los overlays de Kustomize.

La estrategia ganadora: Trabajo previo a la sincronización de ArgoCD

En este escenario, el cliente ya estaba utilizando ArgoCD para la implementación continua de los cambios de la aplicación. Por lo tanto, decidimos asignar también a ArgoCD la responsabilidad de entregar imágenes al clúster del entorno de destino.

ArgoCD admite hooks que permiten ejecutar scripts personalizados antes o después de un proceso de implementación o sincronización.

1. Permiso del repositorio ECR: Autorizar el acceso de extracción entre cuentas para las imágenes de Docker

Para permitir que ArgoCD extraiga imágenes del ECR de origen, debemos agregar una política basada en recursos a nuestro repositorio.

// cross-account-ecr-read-policy.json{  "Version": "2012-10-17",  "Statement": [    {      "Sid": "AllowPull",      "Effect": "Allow",      "Principal": {        "AWS": "arn:aws:iam::{DESTINATION_ACCOUNT}:root" // Reemplace con su cuenta de destino      },      "Action": [        "ecr:BatchCheckLayerAvailability",        "ecr:BatchGetImage",        "ecr:GetDownloadUrlForLayer"      ]    }  ]}

Aplica la política a los repositorios ECR:

aws ecr set-repository-policy --repository-name example --policy-text "file://cross-account-ecr-read-policy.json"// Para múltiples repositorios:aws ecr describe-repositories --query "repositories[].[repositoryName]" | xargs -I {} aws ecr set-repository-policy --repository-name {} --policy-text "file://cross-account-ecr-read-policy.json"

2. Trabajo PreSync Hook: Copiar imagen entre cuentas

• Utilizamos Crane para copiar imágenes sin cambiar su etiqueta y digest.
• El trabajo PreSync Hook se guarda en git junto con otros manifiestos de aplicaciones y es monitoreado por ArgoCD. ArgoCD ejecuta el trabajo antes de sincronizar los cambios.
• La cuenta de origen es la cuenta de Desarrollo o DevOps desde la cual se extraerán las imágenes.
• La cuenta de destino es el entorno de Producción o destino donde se necesita copiar la imagen.

// Ejemplo de plantilla HelmapiVersion: batch/v1kind: Jobmetadata:  generateName: argo-presync-promote-image-  annotations:    argocd.argoproj.io/hook: PreSyncspec:  template:    spec:      volumes:        - name: creds          emptyDir: {}      initContainers:        - name: aws-creds          image: public.ecr.aws/aws-cli/aws-cli          command:            - sh            - -c            - |              aws ecr get-login-password > /creds/ecr          volumeMounts:            - name: creds              mountPath: /creds      containers:        // Por brevedad, he asumido que todos los valores Helm están disponibles en la raíz.        - name: promote-image          image: gcr.io/go-containerregistry/crane:debug          command:            - sh            - -c            - |              // Inicia sesión en ambos registros ECR              cat /creds/ecr | crane auth login {{.Values.sourceAccount}}.dkr.ecr.us-east-1.amazonaws.com -u AWS --password-stdin              cat /creds/ecr | crane auth login {{.Values.destinationAccount}}.dkr.ecr.us-east-1.amazonaws.com -u AWS --password-stdin              // Copia la imagen de la cuenta de origen a la cuenta de destino              crane copy {{.Values.image | replace .Values.destinationAccount .Values.sourceAccount}} {{.Values.image}}          volumeMounts:            - name: creds              mountPath: /creds      restartPolicy: Never  backoffLimit: 2

Conclusión

En conclusión, el equipo pudo promocionar imágenes bajo demanda utilizando el pre-sync hook. Esto hizo que la promoción a producción fuera un único paso de actualización de las superposiciones de Kustomize.

Me encantaría conocer otras opciones que hayan adoptado. Por ejemplo, un enfoque alternativo podría ser utilizar el Control de Admisión Dinámico de Kubernetes para interceptar y extraer imágenes faltantes bajo demanda.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!