De Código Local a ACR Rápido

Introducción: la misión del CI/CD moderno

#

Este artículo nace de una presentación de InnerSource que compartí en mi equipo. Al prepararla, me di cuenta de que valía la pena convertirla en una guía práctica para el blog: menos formato de diapositiva y más pasos accionables para que puedas replicarlo.

El objetivo es claro: pasar de código local a una imagen publicada en Azure Container Registry (ACR) con un pipeline automatizado, pruebas y escaneo de seguridad incluidos. Para eso combinaremos Quarkus, Docker multi-stage, GitHub Actions y Trivy en un flujo simple de mantener y rápido de ejecutar.

La idea central es esta: si un paso crítico falla, la imagen no se publica. Con esa regla, el proceso gana confiabilidad y reduce errores humanos desde el primer commit.

Tecnologías clave

#

• Quarkus (Java optimizado para la nube)
• Docker con multi-stage builds y Dockerfile limpio
• GitHub Actions como orquestador CI/CD
• Azure Container Registry (ACR) como destino privado y escalable
• Trivy para el escaneo de seguridad
• Dev Containers para entornos reproducibles

¿Por qué Quarkus? Build-time y rendimiento

#

¿Recuerdas cuando arrancar una app Java era sinónimo de «toma un café»? Quarkus cambió eso. Empuja trabajo al build-time para que el runtime sea liviano y súper rápido. Con GraalVM o builds optimizados obtienes arranques ultrarrápidos y menor consumo de memoria — ideal para microservicios y entornos serverless.

Beneficios que me hacen sonreír:

• Startup ultra rápido (adiós cold-starts)
• Imágenes más pequeñas con builds nativos o runtime reducidos
• Live coding: ves cambios al instante
• Menos latencia, menos recursos y menos drama en producción

Arquitectura del pipeline CI/CD, contenedores y timeline

#

Arquitectura del pipeline

#

Imagina: código local → commit → GitHub → pipeline → imagen en ACR. Dentro del pipeline separas jobs para velocidad y control:

1. Desarrollo local en Dev Container
2. Commit y push a GitHub
3. GitHub Actions dispara jobs: build + tests (Maven), build de imagen Docker (multi-stage), escaneo con Trivy
4. Push a ACR
5. Opcional: webhook a AKS o Container Apps para despliegue automático

Timeline objetivo: ~13 minutos

#

• 3 min: build + tests (Maven cacheado)
• 5 min: build de imagen Docker (capas cacheadas)
• 2 min: escaneo con Trivy
• 3 min: push y overhead

Regla de oro: si falla un paso, la imagen no se publica.

Desarrollo local estandarizado: Dev Containers

#

El clásico «en mi máquina funciona» mata proyectos. Usa Dev Containers en VS Code para un entorno idéntico entre devs y CI. Ventajas:

• Java 21, extensiones de Quarkus y Maven preconfigurados
• Onboarding más rápido y menos «works on my machine»
• Consejo: en application.properties usa quarkus.http.host=0.0.0.0 para exponer el servicio desde el container

Estrategia de contenedores: Docker multi-stage

#

Multi-stage builds es pura practicidad: compilas en una etapa y copias solo lo esencial a una imagen final mínima. Resultado: menor tamaño y menor superficie de ataque.

Buenas prácticas:

• Optimiza el Dockerfile para separar build y runtime
• Usa imágenes distroless o Alpine para runtime
• Ejecuta con usuario no-root (USER 1000)
• Objetivo razonable: reducir imágenes de ~900MB a 400MB o menos

Automatización con GitHub Actions

#

GitHub Actions orquesta todo: separa jobs, cachea Maven y capas Docker, y pasa artefactos entre trabajos cuando haga falta. Guarda credenciales en GitHub Secrets o usa identidades gestionadas de Azure.

Consejos de pipeline:

• Cache Maven (~/.m2/repository) para acelerar builds
• Usa docker/build-push-action para aprovechar cache de capas
• Configura Trivy para que falle el pipeline si aparecen vulnerabilidades HIGH o CRITICAL

Seguridad automatizada, destino ACR e impacto

#

Seguridad automatizada: Trivy

#

Antes de publicar, Trivy analiza la imagen capa por capa. Integra el escaneo en el pipeline y define políticas claras. Comandos locales rápidos para probar:

trivy image --severity HIGH,CRITICAL myregistry.azurecr.io/myapp:latest

Recomendaciones: ajusta severidad según riesgo, programa rescans periódicos y actualiza imágenes base. Complementa con SCA y escaneo de licencias.

Destino: Azure Container Registry (ACR)

#

ACR es un registro privado, integrado con AKS y Container Apps. Soporta webhooks, replicación y políticas que ayudan a mantener despliegues auditables.

Buenas prácticas de push:

• Automatiza desde el pipeline
• Usa identidades gestionadas o service principals en Secrets
• Evita credenciales en texto plano

Impacto real: métricas y beneficios

#

Más allá del entusiasmo técnico, lo que importa:

• Imágenes más ligeras (~50% menos con multi-stage)
• Arranques drásticamente más rápidos con Quarkus
• Menos errores humanos gracias a un pipeline automatizado
• Ahorro en infra: instancias más pequeñas y arranques más rápidos reducen costos

Playbook corto: de código a ACR en minutos

#

1. Crea proyecto Quarkus: mvn io.quarkus:quarkus-maven-plugin:create
2. Desarrolla en Dev Container y configura quarkus.http.host=0.0.0.0
3. Commit & push a GitHub
4. Workflow: build/test (Maven) → build Docker (multi-stage) → trivy scan → push a ACR
5. Valida en ACR y configura webhook a AKS/Container Apps

Consejos finales y próximos pasos

#

Has conseguido un pipeline reproducible que transforma código local en una imagen segura y optimizada en Azure Container Registry, todo en minutos y sin intervención manual. Puntos a seguir:

• Añadir pruebas de integración y contract testing
• Integrar SCA y escaneo de licencias
• Implementar firma de imágenes y políticas de bloqueo si el escaneo falla
• Automatizar promociones de entornos (staging → prod) con gates y approvals

Recursos útiles

#

• Quarkus
• Trivy
• Azure Container Registry docs
• GitHub Actions docs

Como parte de esta presentación, el workshop completo (código, workflow, Dockerfile y configuración de devcontainer) está compartido en este repositorio:

https://github.com/darkmtrance/quarkus-example