Docker, ACR y Azure Container Apps
Docker, Azure Container Registry y Azure Container Apps aparecen juntos en muchos diagramas. No son tres nombres para la misma capa. Cada uno resuelve una etapa distinta del recorrido al runtime.
En IXATU Operations la cadena tiene dos vistas complementarias:
código → imagen → contenedorGitHub
↓
Docker build
↓
ACR
↓
Azure Container AppsConfundir esas etapas produce despliegues difíciles de razonar. Separarlas permite construir una vez, identificar el artefacto y promoverlo sin reconstruirlo.
Código, imagen y contenedor
El código es la materia prima versionada. Un Dockerfile describe cómo convertirla en una imagen con runtime, dependencias, configuración base y archivos necesarios.
La imagen es un artefacto inmutable. Todavía no es un proceso. Puede almacenarse, escanearse, etiquetarse y reconocerse por su digest.
El contenedor es una ejecución de esa imagen con una configuración concreta. Añade variables, secretos, red, identidad, límites y escala del entorno donde vive.
código
↓ build
imagen
↓ ejecución
contenedorEsta distinción explica por qué una misma imagen puede producir comportamientos válidamente distintos en DEV y PROD sin convertirse en software diferente.
Docker crea el paquete reproducible
Docker fija un proceso de build repetible y una frontera de ejecución. Una web React puede compilarse y terminar como archivos estáticos servidos por Nginx.
Una API puede partir de Python, instalar dependencias bloqueadas y ejecutar FastAPI con un servidor ASGI. Web y API son aplicaciones distintas, con imágenes, escalado e ingress propios.
La imagen no debe contener secretos ni URLs específicas de PROD. Esos valores pertenecen a la configuración por entorno y llegan cuando se crea o actualiza el contenedor.
Un Dockerfile reproducible reduce diferencias, pero no garantiza bytes idénticos si las bases o dependencias flotan. Versionar inputs y conservar el digest vuelve verificable el resultado real.
ACR almacena; no ejecuta
Azure Container Registry recibe y distribuye imágenes. ACR no ejecuta contenedores: es un registry, no un runtime ni un orquestador.
Un pipeline puede publicar una imagen con una etiqueta legible y registrar además su digest. Las etiquetas ayudan a navegar; el digest identifica de forma estable el contenido promovido.
La identidad que ejecuta Container Apps puede obtener AcrPull. Con Managed Identity, el runtime descarga la imagen autorizada sin guardar usuario y contraseña del registry en la aplicación.
El permiso debe ser mínimo y explícito. Que una identidad pueda leer una imagen no implica que pueda publicar otra, administrar el registry o operar el resto de Azure.
Container Apps es el runtime
Azure Container Apps crea revisiones y ejecuta contenedores. Gestiona escala, variables, referencias a secretos, identidad e ingress alrededor de la imagen elegida.
Un Container Apps Environment proporciona una frontera compartida para red y observabilidad. No debe confundirse con la variable lógica ENVIRONMENT=DEV; una es infraestructura y la otra, configuración.
IXATU puede desplegar una web y una API como Container Apps diferentes. La web sirve React mediante Nginx; la API ejecuta FastAPI y accede a los datos autorizados.
Separarlas permite asignar exposición, recursos e identidad distintos. También evita que el proceso público de la web herede permisos de datos que sólo necesita la API.
Ingress external e internal
El ingress external publica una entrada alcanzable desde fuera del environment, sujeto a las capas de autenticación y autorización configuradas.
El ingress internal restringe la exposición a la red prevista del entorno. Reduce superficie, pero no demuestra por sí solo quién llama ni concede autorización de aplicación.
Una topología habitual deja la web como entrada pública prevista y mantiene la API con ingress internal. La web resuelve su API_UPSTREAM hacia el destino configurado para cada entorno.
Los límites exactos dependen de red, DNS, environment y plataforma. Llamar internal a un endpoint no lo convierte automáticamente en caller exclusivo ni sustituye una política de identidad.
Promover por digest
El flujo responsable construye una imagen, la valida en DEV y autoriza el mismo digest en PROD.
build once
↓
ACR: imagen@sha256:…
↓
DEV valida
↓ aprobación
PROD ejecuta el mismo digestNo se mueven contenedores vivos entre entornos. Se crea una ejecución nueva de la misma imagen con la configuración del destino.
Tampoco se hace rebuild para PROD. Una recompilación posterior puede cambiar dependencias o capas, aunque conserve la misma etiqueta o el mismo commit.
DEV, PROD y configuración
DEV y PROD pueden consumir el mismo registry o registries separados. La decisión debe responder a aislamiento, promoción y permisos, no a la idea equivocada de que cada entorno necesita código distinto.
URLs, secretos, conexiones y escala se aplican en el runtime. El artículo sobre configuración por entornos desarrolla por qué cambiar esos valores no altera el artefacto promovido.
Jobs cuando la tarea tiene principio y fin
Container Apps Jobs encaja mejor que una app siempre activa cuando el trabajo es finito, programado o disparado por un evento: una reconciliación, un lote o una comprobación puntual.
Elegir Job no elimina las mismas obligaciones. La tarea necesita imagen identificada, configuración, identidad mínima, observabilidad y una política explícita sobre mutaciones.
Errores conceptuales frecuentes
- Tratar ACR como si fuese el runtime.
- Usar
latestcomo identidad de promoción. - Reconstruir la imagen al pasar de DEV a PROD.
- Incluir secretos o endpoints de entorno durante el build.
- Desplegar web y API como un proceso inseparable por comodidad.
- Interpretar ingress internal como autenticación o caller exclusivo.
- Conceder permisos amplios porque Managed Identity evita contraseñas.
- Confundir una imagen almacenada con un contenedor en ejecución.
Una cadena con responsabilidades visibles
Docker empaqueta, ACR conserva y distribuye, y Azure Container Apps ejecuta. Managed Identity conecta esas capas sin trasladar credenciales al código.
El digest conserva la identidad del artefacto. La configuración define cada ejecución. El ingress acota exposición, pero la seguridad completa necesita más capas.
Cuando cada componente responde sólo por su función, el camino desde un commit hasta PROD deja de ser una sucesión de cajas opacas y se convierte en una promoción que puede explicarse y auditarse.