3.2Pilotar el stack : up, down, logs, ps
Lo esencial en 30 segundos
- up -d lo crea todo : redes y volúmenes, build/pull de las imágenes, arranque en orden — --build fuerza la reconstrucción tras un cambio de código.
- Observar por servicio, prefijado compose : compose ps lista el stack, logs -f bdd sigue un servicio, exec web sh entra dentro — nunca el docker ps global que lo mezcla todo.
- down guarda, -v destruye : down detiene y suprime contenedores + red guardando los volúmenes ; down -v borra también los volúmenes — reset voluntario únicamente.
Mini-caso hilado — Idir y el down de más
Idir, devops junior en Argel, « limpia » su puesto con un docker compose down -v antes de una demo — y borra la base de pruebas rellenada la víspera por su colega. Adopta el ciclo seguro : up -d, compose ps, logs -f bdd, exec web sh, down SIN -v por defecto. En el segundo up, la base está intacta : ha entendido que down solo es una parada segura, y que -v es un reset que se decide, nunca una limpieza.
Este mismo caso vuelve en el curso, el esquema, el guion y el reto 48h.
1. up : construir y arrancar, ver : ps, logs, exec
docker compose up -d crea las redes y volúmenes, descarga o construye las imágenes, luego arranca los servicios en orden — en segundo plano (-d). Sin -d, los logs se adjuntan al terminal : práctico en desarrollo para ver nacer el stack, bloqueante en servicio. Tras un cambio de código, --build fuerza la reconstrucción : sin él, Compose reutiliza la imagen existente y su nuevo código no se aplica.
Para VER : docker compose ps lista los contenedores DEL proyecto, logs -f bdd sigue los registros de un servicio en directo (sin nombre, todo el stack, cada línea prefijada), exec web sh entra en un contenedor. Regla de oro : siempre prefijar con compose — docker ps mezcla todos los proyectos de la máquina y hace diagnosticar el contenedor equivocado.
2. down : parada segura por defecto, reset por decisión
docker compose down detiene y suprime contenedores + red, pero GUARDA los volúmenes : sus datos sobreviven, el segundo up los reencuentra. Es la parada segura, la del día a día. down -v borra ADEMÁS los volúmenes : reset voluntario para empezar de cero (base de pruebas por reinicializar), reservado a un stack desechable o asumido.
En caso de duda : sin -v. El drama clásico — down -v « para limpiar » antes de una demo — se evita con este defecto. Idir se ha puesto una regla tatuada : down solo para detener, -v solo cuando puede citar lo que acepta perder. El ciclo up → observar → down (sin -v) es seguro por construcción.
La limpieza de más
Limpiar es down solo ; -v es mudarse.
🔎 Ejemplo concreto — Ciclo completo : la base sobrevive al reinicio
Idir encadena el ciclo seguro en su stack web + base.
docker compose up -d
docker compose ps
docker compose logs -f bdd
docker compose exec web sh
docker compose down
docker compose up -d # los datos están ahí
# Reset VOLUNTARIO solo en stack desechable :
# docker compose down -vLectura : el segundo up reencuentra la base intacta — down solo preserva.
Lección : down sin -v = parada segura ; con -v = reset decidido, nunca una limpieza.
Vocabulario de la sección
- up
- Crear y arrancar todo el stack : redes, volúmenes, imágenes (build/pull), contenedores en orden — -d para segundo plano.
Ejemplo sencillo: El up -d de Idir cada mañana en la maqueta.
Lo que no es: arrancar cada contenedor a mano en el orden correcto.
Reflejo: --build tras cada cambio de código.
- down
- Detener y suprimir contenedores + red GUARDANDO los volúmenes : la parada segura del día a día.
Ejemplo sencillo: El down de la tarde de Idir, base intacta al día siguiente.
Lo que no es: una parada que borra la base.
Reflejo: down solo por defecto, siempre.
- down -v
- down + supresión de los VOLÚMENES : reset voluntario para empezar de cero, nunca una limpieza.
Ejemplo sencillo: El reset asumido de una base de pruebas desechable.
Lo que no es: una « limpieza » antes de una demo con datos reales.
Reflejo: citar lo que se acepta perder antes de todo -v.
- ps (compose)
- Listar los contenedores DEL proyecto únicamente — el perímetro justo para diagnosticar.
Ejemplo sencillo: compose ps muestra el stack de Idir, nada más.
Lo que no es: docker ps global que mezcla todos los proyectos.
Reflejo: siempre prefijar con compose.
- logs -f / exec
- Seguir los registros de un servicio en directo (logs -f bdd) y entrar en un contenedor (exec web sh).
Ejemplo sencillo: Idir sigue la base al arrancar y luego inspecciona la web.
Lo que no es: adivinar la avería sin leer los registros.
Reflejo: ps localiza, logs acusa, exec verifica.
En la práctica — Dominar el ciclo sin arriesgar los datos
- Arranque su stack en -d y lístelo con compose ps (compare con docker ps global).
- Siga los logs de la base (logs -f bdd) y entre en la web (exec web sh).
- Detenga con down, relance : verifique que los datos han sobrevivido.
- Pruebe down -v solo en un stack DESECHABLE, y constate la pérdida — una vez basta.
Guion listo para decir — explicar el ciclo a un recién llegado (30 s)
« up -d para arrancar, compose ps y logs para observar tu stack — nunca el ps global. Y para detener : down solo, los datos sobreviven. El -v es un reset que borra los volúmenes : solo en desechable, nunca para limpiar. »
Para decir en onboarding ; hacer ejecutar el ciclo una vez juntos.
Modelo copiar-pegar — stack desechable de entrenamiento
# Stack DESECHABLE : para entrenarse (down -v) sin riesgo.
services:
web:
image: nginx:1.27
ports:
- "8080:80"
networks:
- bacnet
bdd:
image: postgres:16.4
environment:
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- bacdata:/var/lib/postgresql/data
networks:
- bacnet
volumes:
bacdata:
networks:
bacnet:Independiente
El ciclo up → compose ps/logs → down solo y sus demos sobreviven a los reinicios.
PYME en Argel
Idir forma a su colega : down solo por la tarde, base intacta por la mañana.
Equipo de proyecto
Regla de equipo : -v prohibido fuera del stack desechable nombrado (bac, test).
Principiante
Esta semana : un ciclo completo + un reset -v en desechable, para sentir la diferencia.
✓ Buenas prácticas
- Siempre compose + verbo (ps, logs, exec) para quedarse en el perímetro del proyecto.
- down sin -v por defecto ; -d en servicio, adjunto solo en debug.
- Añada --build tras cada cambio de código, o monte el código en bind en dev.
✗ Errores frecuentes
- down -v « para limpiar » : los datos del proyecto se borran.
- docker ps en lugar de compose ps : se diagnostica el contenedor equivocado.
- Olvidar --build tras un cambio de código : la imagen antigua sigue corriendo.
Puntos clave
- UP lo crea todo (-d en segundo plano) ; --build fuerza la reconstrucción tras cambio de código.
- PS / LOGS / EXEC por servicio, siempre prefijados compose (perímetro del proyecto).
- DOWN guarda los volúmenes (parada segura) ; -v los destruye (reset voluntario únicamente).
- El ciclo up → observar → down (sin -v) es seguro por construcción.
Reto 48h — aplique mañana
Ejecute 1 ciclo completo en su stack (up -d, ps, logs, exec, down, re-up) y demuestre que los datos sobreviven.
- Arranco en segundo plano y reconstruyo con --build cuando cambia el código.
- Observo por servicio en el perímetro compose.
- Detengo con down solo ; -v solo en desechable asumido.
Preguntas frecuentes
¿up no aplica mi código nuevo, por qué ?
Porque la imagen NO se reconstruye : Compose reutiliza la imagen existente por defecto. Añada --build (up -d --build) tras cada cambio de código, o monte el código en bind mount en desarrollo para una recarga directa. Verifique con compose ps que el contenedor acaba de recrearse.
¿Cómo seguir varios servicios a la vez ?
Lance docker compose logs -f sin nombre de servicio : todo el stack desfila, cada línea prefijada con el nombre del servicio. Ideal al arrancar para ver el orden real y detectar quién falla. Luego, amplíe con logs -f bdd en el sospechoso, y exec para entrar dentro.
Quiere detener el stack guardando la base. ¿Qué comando ?