Optimizar CI/CD y GitOps en vSphere Kubernetes con Harness, Wiz y Dynatrace

Introducción

Cuando tu equipo de plataforma pasa de proveer infraestructura a garantizar una entrega ágil y segura de aplicaciones, el desafío es mantener la velocidad de los desarrolladores sin sacrificar los guardrails operativos. En entornos VMware Cloud Foundation (VCF) 9 con vSphere Kubernetes Service (VKS), esto se traduce en construir un pipeline de CI/CD que automatice despliegues, valide imágenes en tiempo real y mantenga la observabilidad completa. Este artículo te guía para integrar Harness como orquestador de pipelines, Wiz para escaneo de vulnerabilidades y Dynatrace para monitoreo continuo, todo sobre VKS con un modelo de consumo basado en Infrastructure as Code (IaC) y Helm.

El resultado será un flujo GitOps donde el repositorio Git es la fuente de verdad única, las imágenes se escanean antes de llegar al clúster y los despliegues fallidos o con regresión de performance se revierten automáticamente antes de afectar entornos productivos.

Qué es y para qué sirve

Prerequisitos

1. Acceso a VCF 9: Debes tener permisos de Cloud Admin en vCenter para crear clústeres VKS.
2. API Key de Harness: Generada en la consola de Harness SaaS (perfil > API Keys).
3. Token de Wiz: Obtenido en la consola de Wiz (Settings > API Keys).
4. Token de Dynatrace: Generado en la consola de Dynatrace (Settings > Integration > API Tokens).
5. Repositorio Git: Acceso de escritura para el Harness Delegate (puede ser GitHub, GitLab, Bitbucket o Azure Repos).

Guía paso a paso

Paso 1: Bootstrap del clúster VKS con IaC

Usaremos Terraform para crear el clúster VKS en VCF y configurar los prerequisitos para Harness, Wiz y Dynatrace.

1. Clona el repositorio de ejemplo:

   git clone https://github.com/vmware-tanzu/vcf-vks-iac.git && cd vcf-vks-iac/terraform
   

1. Configura el archivo terraform.tfvars con tus credenciales de VCF:

   vcf_username   = "[email protected]"
   vcf_password   = "tu-contraseña-encriptada-en-base64" # Usa `echo -n "tu-contraseña" | base64`
   vcf_server     = "vcsa.vmware.local"
   cluster_name   = "vks-gitops-demo"
   datacenter     = "SDDC-Datacenter"
   resource_pool  = "RP-VKS-Workloads"
   

1. Inicializa y aplica Terraform:

   terraform init -upgrade
   terraform apply -auto-approve
   

– Se crea un clúster VKS llamado vks-gitops-demo.

– Se genera un archivo kubeconfig en ./output/kubeconfig.yaml.

– Se crean los namespaces harness, wiz y dynatrace (opcional, pero recomendado para aislamiento).

Paso 2: Instalación del Harness Delegate en VKS

El Delegate actúa como puente entre Harness SaaS y tu clúster VKS interno, permitiendo que los pipelines se ejecuten sin exponer credenciales sensibles.

1. Instala el Delegate usando Helm:

   helm repo add harness-delegate https://app.harness.io/storage/harness-download/delegate
   helm repo update
   

1. Genera el archivo de valores personalizado delegate-values.yaml:

   delegateName: vks-gitops-delegate
   namespace: harness
   accountId: TU_ACCOUNT_ID_DE_HARNESS
   delegateToken: TU_TOKEN_DE_DELEGATE  # Generado en Harness SaaS: Account Settings > Delegates > + New Delegate
   clusterName: vks-gitops-demo
   

1. Aplica la instalación:

   helm install vks-gitops-delegate harness-delegate/harness-delegate \
     --namespace harness \
     --create-namespace \
     -f delegate-values.yaml
   

1. Verifica que el Delegate esté corriendo:

   kubectl get pods -n harness
   

   NAME                                 READY   STATUS    RESTARTS   AGE
   vks-gitops-delegate-abc123-xyz456   2/2     Running   0          2m
   

Paso 3: Configuración de GitOps en Harness

GitOps en Harness usa Git Sync para mantener el estado del clúster sincronizado con el repositorio Git.

1. En la consola de Harness SaaS, ve a GitOps > Repositories > + New Repository.
2. Configura el repositorio remoto:

– Repo URL: https://github.com/tu-org/vks-gitops-manifests.git

– Branch: main

– Authentication: Usa un token de acceso personal (GitHub) o credenciales SSH.

1. Crea una Application en GitOps:

– Repository: Selecciona el repo configurado.

– Path: ./apps/nginx (o el directorio donde están tus manifests Helm).

1. Sincroniza manualmente por primera vez:

– Harness crea un Application en tu clúster VKS con los manifests del repositorio.

– Verifica con:

     kubectl get applications.argoproj.io -n harness
     

Paso 4: Integración de Wiz en el pipeline de CI

Wiz escanea imágenes de contenedores antes de que sean desplegadas, bloqueando el pipeline si detecta riesgos altos.

1. En la consola de Harness SaaS, ve a Pipelines > + New Pipeline.
2. Configura un CI Pipeline:

– Stages: Añade un Build y un Security Scan.

1. En la etapa Build, configura el paso para construir la imagen:

   - step:
       type: BuildAndPushDockerRegistry
       name: Build and Push
       identifier: build_and_push
       spec:
         connectorRef: dockerhub-connector  # Configurado previamente en Harness
         repo: tu-org/nginx
         tags:
           - latest
           - commit-${build.commitSha}
   

1. Añade una etapa Security Scan con Wiz:

   - step:
       type: Wiz
       name: Wiz Vulnerability Scan
       identifier: wiz_scan
       spec:
         wizConnectorRef: wiz-connector  # Configurado en Harness con tu token de Wiz
         targetName: "nginx-app"
         policy: "Harness-Medium"  # Usa una política predefinida o personalizada
         failOnSeverity: "High"   # Bloquea si hay vulnerabilidades de alta severidad
   

1. Guarda y ejecuta el pipeline. Resultado esperado:

– Si todo está bien, la imagen se empuja a tu registry privado y se etiqueta con el commit SHA.

Paso 5: Despliegue seguro con GitOps y Dynatrace

Ahora configuraremos el pipeline de despliegue (CD) que usa GitOps para aplicar cambios y Dynatrace para validar el estado del clúster.

1. Crea un CD Pipeline en Harness:

– Stages:

– Git Sync: Para sincronizar el repositorio con el clúster.

– Health Check: Para validar el despliegue con Dynatrace.

1. Configura la etapa Git Sync:

   - step:
       type: GitOpsSync
       name: Sync with Git
       identifier: gitops_sync
       spec:
         applicationName: vks-gitops-app
         syncOption:
           prune: true
           selfHeal: true
   

1. Añade una etapa Health Check con Dynatrace:

   - step:
       type: Dynatrace
       name: Dynatrace Health Check
       identifier: dynatrace_health
       spec:
         dynatraceConnectorRef: dynatrace-connector  # Configurado con tu token de Dynatrace
         metricQueries:
           - "builtin:service.response.time:filter=and(or(service.name(nginx))):splitBy():avg:auto:sort(value(avg,descending)):limit(10)"
           - "builtin:service.errors.total.rate:filter=and(or(service.name(nginx))):splitBy():sum:auto"
         thresholds:
           responseTime: 100  # ms
           errorRate: 0.05   # 5%
   

1. Configura un Rollback Automático si falla el Health Check:

   - step:
       type: RollbackGitOps
       name: Auto Rollback
       identifier: auto_rollback
       spec:
         applicationName: vks-gitops-app
         prune: true
   

1. Ejecuta el pipeline. Resultado esperado:

– Dynatrace verifica que la nueva versión cumpla con los umbrales definidos.

– Si falla (ej. latencia >100ms o error rate >5%), Harness automáticamente revierte el despliegue a la versión anterior.

Consideraciones y buenas prácticas

Limitaciones conocidas:

1. Latencia en rollbacks: Si Dynatrace tarda más de 30 segundos en detectar una regresión, el rollback puede no ser instantáneo. Configura umbrales realistas (ej. espera 2 minutos antes de revertir).
2. Costo de herramientas: Wiz y Dynatrace son SaaS y pueden generar costos variables según el volumen de escaneos o métricas. Monitorea el consumo mensual en sus consolas.
3. Permisos del Harness Delegate: El Delegate requiere permisos elevados (cluster-admin) para aplicar manifests. Aíslalo en un namespace dedicado (ej. harness) para reducir la superficie de ataque.

Alternativas:

• Para entornos sin Dynatrace: Usa Prometheus + Grafana como alternativa para métricas. Harness tiene integraciones nativas con ambos.
• Para escaneo de imágenes: Si Wiz no es viable, considera Trivy (open-source) como paso en el pipeline de CI.

Buenas prácticas:

1. Políticas de Wiz: Define políticas específicas para tu entorno (ej. «No permitir pods con privileged: true«).
2. Testing en staging: Usa un clúster VKS de staging para probar pipelines antes de aplicarlos a producción.
3. Canary Deployments: Para aplicaciones críticas, configura un pipeline de canary con Harness y usa Dynatrace para comparar métricas entre versiones.

Conclusión

Hemos construido un pipeline de CI/CD y GitOps en VKS que:

1. Automatiza el despliegue de aplicaciones usando Git como origen de verdad.
2. Valida imágenes de contenedores con Wiz antes de llegar al clúster.
3. Monitorea el estado del clúster en tiempo real con Dynatrace y revierte automáticamente si detecta regresiones.

Este enfoque no solo acelera la entrega de aplicaciones, sino que también reduce riesgos operativos al integrar seguridad y observabilidad desde las primeras etapas del ciclo de vida. Con esta configuración, tu equipo de plataforma puede ofrecer un «camino dorado» (Golden Path) para los desarrolladores: rápido, seguro y observable por defecto.

Fuentes

• Streamlining CI/CD and GitOps on VMware vSphere Kubernetes Service with Harness, Wiz, and Dynatrace
• CISA Alerts: Vulnerabilidades en Kubernetes
• Envoy Proxy Blog: Best Practices para GitOps