Distribución de aplicaciones con Docker: guía completa

Distribución de aplicaciones con Docker significa convertirla en una imagen portable que cualquier entorno puede descargar y ejecutar de forma idéntica. Sin diferencias entre el portátil del desarrollador, el servidor de staging y producción en cloud.

El flujo es siempre el mismo: construir la imagen, etiquetarla, subirla a un registro y descargarla donde se necesite. Pero en la práctica, distribuir bien implica también optimizar el tamaño de la imagen, usar un registro adecuado al contexto, etiquetar con criterio y automatizar todo el proceso en un pipeline CI/CD.

Si todavía no tienes claro qué es una imagen Docker y cómo funciona su arquitectura, el artículo sobre qué es Docker cubre los fundamentos antes de entrar en la distribución.

El flujo de distribución: build, tag, push, pull, run

Distribuir una aplicación con Docker tiene cinco pasos que se ejecutan en orden. Entender qué ocurre en cada uno es la base para automatizarlo correctamente en un pipeline.

1. docker build — construir la imagen

El primer paso es construir la imagen a partir del Dockerfile del proyecto:

docker build -t miapp:v1.0.0 .

El flag -t asigna un nombre y etiqueta a la imagen. El punto final indica que el contexto de build es el directorio actual, donde Docker busca el Dockerfile.

Una buena práctica es incluir un archivo .dockerignore junto al Dockerfile para excluir del contexto de build archivos que no necesita la imagen: node_modules, .git, archivos de test, documentación. Reduce el tiempo de build y el tamaño de la imagen.

2. docker tag — etiquetar la imagen

Etiquetar la imagen la asocia con un registro y un nombre de repositorio específicos:

# Para Docker Hub
docker tag miapp:v1.0.0 usuario/miapp:v1.0.0

# Para Amazon ECR
docker tag miapp:v1.0.0 123456789.dkr.ecr.eu-west-1.amazonaws.com/miapp:v1.0.0

# Para GitHub Container Registry
docker tag miapp:v1.0.0 ghcr.io/organizacion/miapp:v1.0.0

3. docker push — subir al registro

Sube la imagen al registro. Requiere autenticación previa con docker login:

# Autenticación en Docker Hub
docker login

# Autenticación en AWS ECR
aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin 123456789.dkr.ecr.eu-west-1.amazonaws.com

# Push de la imagen
docker push usuario/miapp:v1.0.0

4. docker pull — descargar en destino

En el servidor de destino, staging o producción, se descarga la imagen del registro:

docker pull usuario/miapp:v1.0.0

5. docker run — ejecutar el contenedor

Crea y arranca el contenedor a partir de la imagen descargada:

docker run -d -p 3000:3000 --name miapp usuario/miapp:v1.0.0

Para el despliegue completo de aplicaciones en entornos locales con Docker, el artículo sobre despliegue de aplicaciones locales con Docker cubre el proceso en detalle.

Multi-stage builds: imágenes optimizadas para distribución

Una de las mejoras más importantes que se puede hacer antes de distribuir una imagen es reducir su tamaño. Imágenes más pequeñas se descargan más rápido, ocupan menos espacio en el registro y tienen menos superficie de ataque.

Los multi-stage builds usan múltiples etapas en un solo Dockerfile: la primera instala todas las herramientas de build necesarias, la segunda copia solo el resultado compilado en una imagen base limpia y mínima.

# Etapa 1: build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

# Etapa 2: imagen de producción
FROM node:20-alpine AS production
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/server.js"]

El resultado es una imagen que solo contiene el código compilado y las dependencias de producción, sin las herramientas de build, los archivos de test ni el código fuente original. El diferencial de tamaño puede ser de cientos de megabytes en proyectos reales.

Para entender en profundidad el Dockerfile y todas sus instrucciones, el artículo sobre qué es un Dockerfile cubre el tema completo con ejemplos.

Registros de imágenes: Docker Hub y registros privados

El registro es donde se almacenan y desde donde se distribuyen las imágenes. La elección del registro adecuado depende del contexto de uso.

En entornos enterprise la recomendación habitual es usar el registro del proveedor cloud principal de la organización. Integra mejor con los servicios de IAM del proveedor, garantiza que las imágenes no salen del entorno de la organización y elimina la dependencia de los límites de Docker Hub en pipelines de producción.

Etiquetado semántico de imágenes

El etiquetado de imágenes puede parecer un detalle menor pero tiene consecuencias reales en la reproducibilidad y el control de versiones de los despliegues.

La etiqueta latest que Docker aplica por defecto apunta siempre a la última imagen subida. Si el pipeline de CI/CD hace pull de latest en producción y alguien sube una imagen rota, production se cae. Por eso en entornos profesionales no se despliega nunca latest en producción.

Las estrategias de etiquetado más usadas son:

• Versión semántica: v1.0.0, v1.2.3. Reproducible y predecible. Ideal para releases.
• Hash del commit de Git: abc1234. Trazabilidad total: la etiqueta vincula la imagen exactamente al commit del que se construyó.
• Rama + hash: main-abc1234. Combina contexto (rama) con trazabilidad (hash).
• Fecha: 2026-05-28. Útil para imágenes de datos o configuración que se actualizan periódicamente.

Una práctica robusta en CI/CD es publicar la misma imagen con dos etiquetas simultáneamente: el hash del commit (para trazabilidad) y la versión semántica (para despliegue controlado).

Distribución en pipelines CI/CD

El flujo manual de build-tag-push es útil para entender el proceso, pero en producción todo eso debe estar automatizado. El pipeline CI/CD es quien construye, etiqueta y sube las imágenes automáticamente cuando hay un cambio en el repositorio.

Un ejemplo de step de GitHub Actions que construye y publica la imagen en GitHub Container Registry:

- name: Build and push Docker image
  uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: |
      ghcr.io/organizacion/miapp:latest
      ghcr.io/organizacion/miapp:${{ github.sha }}

Este step se ejecuta automáticamente en cada push a la rama principal, construye la imagen con multi-stage build, la etiqueta con latest y con el hash del commit y la sube al registro. El siguiente step del pipeline puede desplegarla en Kubernetes o en cualquier entorno de destino.

Para ver Docker Compose integrado en el despliegue de aplicaciones web, el artículo sobre qué es Docker Compose cubre la orquestación multi-contenedor que habitualmente acompaña a la distribución.

Buenas prácticas de distribución con Docker

Lo que diferencia una imagen bien distribuida de una que genera problemas en producción no suele ser el flujo técnico, que es simple. Es el conjunto de decisiones que se toman alrededor de ese flujo.

• Usa imágenes base Alpine o distroless. Las imágenes Alpine son significativamente más pequeñas que las basadas en Debian o Ubuntu. Las imágenes distroless de Google contienen solo el runtime necesario, sin shell ni utilidades del sistema. Menos superficie de ataque y menos tamaño.
• Nunca uses latest en producción. Siempre etiquetas explícitas con versión o hash. El tag latest es mutable y no garantiza reproducibilidad.
• Escanea las imágenes antes de publicarlas. Docker Scout (integrado en Docker Desktop y Docker Hub) analiza las imágenes en busca de vulnerabilidades conocidas en las dependencias incluidas.
• No incluyas secretos en las imágenes. Las variables de entorno con credenciales, API keys o contraseñas nunca deben hardcodearse en el Dockerfile ni copiarse en la imagen. Se inyectan en tiempo de ejecución desde el sistema de gestión de secretos del proveedor cloud.
• Mantén el .dockerignore actualizado. Excluye del contexto de build todo lo que no necesita la imagen: tests, documentación, archivos de configuración local, historiales de git.

Cómo aprender distribución de aplicaciones con Docker

El flujo de distribución con Docker es accesible para cualquier desarrollador. Lo que tarda más en desarrollarse es el criterio para tomar las decisiones correctas a escala: qué registro usar según el contexto de la organización, cómo estructurar el pipeline para que las imágenes se construyan una sola vez y se promuevan entre entornos, y cómo integrar el escaneo de vulnerabilidades sin ralentizar el tiempo de despliegue.

Ese criterio se construye trabajando en proyectos reales donde esas decisiones tienen consecuencias directas en la seguridad y la velocidad de entrega del equipo.

Para aprender distribución de aplicaciones con Docker en proyectos reales, el DevOps y Cloud Computing Full Stack Bootcamp de KeepCoding cubre el recorrido completo en 6 meses.

Conclusión

Distribuir aplicaciones con Docker convierte el código en un artefacto portable, reproducible y desplegable en cualquier entorno.

El flujo build-tag-push-pull es simple. Para aprender distribución de aplicaciones con Docker en proyectos reales, el DevOps y Cloud Computing Full Stack Bootcamp de KeepCoding cubre el recorrido completo en 6 meses.

La clave está en hacerlo bien: imágenes optimizadas con multi-stage builds, etiquetado semántico que garantice reproducibilidad, registro adecuado al contexto de la organización y automatización completa en CI/CD.

Una imagen Docker bien construida y correctamente distribuida es la base de cualquier pipeline de despliegue moderno, desde el desarrollo local hasta Kubernetes en producción.

La documentación oficial sobre distribución de imágenes, registros y multi-stage builds está en docs.docker.com/build/building/multi-stage/.