ProTecno
GuíaDocker desde cero3 / 3

Capítulo 3 de 3 · Docker desde cero

Llevar la imagen a producción

Etiquetas, registro, variables de entorno y comprobaciones de salud. Lo necesario para desplegar sin sustos y poder volver atrás.

2 min de lecturaActualizado el 2 de septiembre de 2026

dockerdesplieguedevops

Ya tienes una imagen pequeña y reproducible. Ahora hay que hacer que llegue a un servidor de forma que en cualquier momento puedas responder a dos preguntas: qué código hay corriendo exactamente, y cómo vuelvo a la versión anterior si esto sale mal.

Etiqueta por commit y olvídate de latest

SHA=$(git rev-parse --short HEAD)
docker build -t registry.ejemplo.com/api:"$SHA" -t registry.ejemplo.com/api:latest .
docker push registry.ejemplo.com/api:"$SHA"
docker push registry.ejemplo.com/api:latest

Despliega siempre con la etiqueta del SHA. latest puedes seguir publicándolo como comodidad para desarrollo, pero que nada en producción dependa de él.

La misma imagen en todos los entornos

Una regla que evita muchos problemas: la imagen es idéntica en staging y en producción. Lo único que cambia son las variables de entorno.

docker run -d \
  --name api \
  --env-file /etc/api/produccion.env \
  --restart unless-stopped \
  -p 3000:3000 \
  registry.ejemplo.com/api:"$SHA"

Comprobación de salud

Necesitas un endpoint /salud que compruebe de verdad las dependencias críticas, no uno que devuelva un 200 sin mirar nada:

HEALTHCHECK --interval=30s --timeout=3s --start-period=20s --retries=3 \
  CMD node -e "fetch('http://localhost:3000/salud').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"

Desplegar sin cortar el servicio

  1. Construye y publica la imagen con la etiqueta del SHA del commit.

  2. Arranca el contenedor nuevo en otro puerto y espera a que el healthcheck lo marque como healthy:

    docker inspect --format '{{.State.Health.Status}}' api-nuevo

  3. Cambia el upstream del proxy para que apunte al contenedor nuevo y recarga la configuración.

  4. Cuando el contenedor antiguo haya terminado de atender sus conexiones, páralo y elimínalo.

Hecho a mano son cuatro pasos. Cuando lo hayas hecho tres veces querrás automatizarlo, y ese es el momento de mirar Compose o un orquestador.

Limpiar el disco del servidor

Las imágenes viejas van llenando el disco sin hacer ruido hasta que un día no cabe el despliegue. Programa una limpieza:

docker system prune --all --filter "until=168h" --force

Hasta aquí la guía

Has pasado de ejecutar alpine a mano a publicar una imagen multi-etapa, etiquetada por commit, configurada por entorno y con su comprobación de salud. Cuando tengas que orquestar varios servicios, el siguiente paso es Compose si es una sola máquina, y Kubernetes solo cuando de verdad lo necesites, que suele ser más tarde de lo que parece.