Cuando trabajas con varios contenedores en paralelo, entender la secuencia de apagado en Docker Compose marca la diferencia entre dejar tu equipo saturado o liberarlo por completo. Aquí te muestro cómo controlar el orden en que se detienen tus servicios y por qué docker-compose down ahorra recursos que probablemente estás desperdiciando sin darte cuenta.
Cómo se define la secuencia de arranque en Docker Compose
El orden en que tus contenedores inician depende de las dependencias que declaras dentro del archivo docker-compose.yaml. Si configuras bien esas relaciones, Docker Compose respeta la jerarquía sin que tengas que intervenir.
En el ejemplo de la carpeta Apagado se definen tres servicios encadenados:
- Un servicio
db que corre una base de datos sencilla.
- Un servicio
app que se construye desde la carpeta Frontend con su propio Dockerfile basado en Nginx, y que depende de db.
- Un servicio
web que jala una imagen de Nginx y depende de app.
La palabra clave aquí es depends_on. Al declararla, le indicas a Docker Compose que db debe arrancar primero, después app y al final web. Cuando ejecutas docker-compose up desde la terminal, ves en pantalla esa secuencia respetada al pie de la letra [00:48].
¿Qué hace depends_on en docker-compose? Define el orden de arranque entre servicios. Si A depende de B, Docker Compose levanta B primero y luego A.
Por qué el apagado con Control C funciona como efecto dominó inverso
Aquí viene lo interesante. Cuando presionas Ctrl + C en la terminal donde corre Docker Compose, los contenedores no se detienen en el mismo orden en que arrancaron, sino al revés.
Siguiendo el ejemplo anterior, el primero en detenerse es web, después app y por último db. Esto tiene sentido porque proteges los servicios base hasta el final: la base de datos sigue viva mientras los servicios que dependen de ella se cierran ordenadamente.
Esta lógica te permite diseñar arquitecturas donde el cierre limpio importa, por ejemplo cuando una aplicación necesita guardar estado antes de que la base de datos se apague [02:05].
En qué se diferencia docker compose down de Control C
Aquí está el detalle que muchos pasan por alto. Detener con Ctrl + C apaga los contenedores, pero los deja registrados en Docker Desktop ocupando espacio. Si abres la sección de Contenedores, ahí siguen, listos para reiniciarse pero también consumiendo recursos del sistema.
El comando docker-compose down hace algo distinto: además de detener los contenedores, los elimina junto con las redes y otros elementos que se hayan desplegado durante esa sesión. Es una limpieza general del ambiente.
¿Qué elimina docker-compose down? Borra contenedores, redes y recursos asociados que Docker Compose creó al levantar el entorno, dejando tu sistema limpio.
Cómo ejecutar docker compose down correctamente
Hay un requisito que no puedes saltarte: el comando debe ejecutarse desde la misma ubicación donde corriste docker-compose up. Si estás en otra carpeta, no funciona.
El flujo práctico es así:
- Abre una nueva pestaña en tu terminal.
- Navega con
cd a la carpeta donde está tu archivo docker-compose.yaml.
- Ejecuta
docker-compose down.
- Verifica en Docker Desktop que los contenedores ya no aparecen.
Este paso adicional implica un poco más de trabajo que solo presionar Ctrl + C, pero el ahorro de recursos vale la pena, sobre todo si sueles olvidar eliminar imágenes manualmente [03:45].
Cuándo conviene usar cada método de apagado
No siempre necesitas hacer una limpieza total. Si estás en medio de una sesión de desarrollo y vas a reiniciar los contenedores en minutos, Ctrl + C puede ser suficiente porque conserva el estado para volver a levantar todo rápido.
En cambio, cuando terminas tu jornada o cambias de proyecto, docker-compose down es el aliado que mantiene tu equipo libre de contenedores zombis y redes huérfanas. Docker Compose se encarga de la limpieza por ti, así no tengas que recordar cada recurso que desplegaste.
La próxima vez que cierres tu entorno, piensa qué quieres: pausar para retomar pronto, o limpiar para liberar todo. Comparte en los comentarios cómo organizas tu flujo de apagado en proyectos con varios servicios.
