Llega el momento de la práctica seria. En esta lección no vas a leer teoría: vas a teclear, a equivocarte y a ver resultados en tu navegador. Empezarás con el contenedor más simple posible —uno que imprime algo y muere— para entender el ciclo más corto que existe. Después levantarás un servidor web real en segundo plano, publicarás su puerto y lo visitarás desde el navegador, aprendiendo por el camino qué significa exactamente -p 8080:80, que es probablemente la opción que más veces escribirás en tu carrera. Recorrerás el ciclo completo de ese contenedor: verlo, leer sus logs, pararlo, arrancarlo y borrarlo. Luego entrarás dentro de un contenedor con un shell interactivo para tocar su sistema de archivos aislado con tus propias manos. Y terminarás sirviendo la primera página web de Aurora Libros desde un contenedor, montando un fichero de tu máquina dentro de él.

1. Antes de empezar: comprobaciones
2. Tu primer contenedor: en primer plano
3. Qué ocurre cuando el proceso termina
4. Un contenedor de servicio en segundo plano
5. El mapeo de puertos explicado
6. El ciclo completo: logs, stop, start y rm
7. Un contenedor interactivo: entrar dentro
8. Sirviendo la página de Aurora Libros con -v
9. Limpieza final

Asegúrate de que todo está en orden:

El primero debe mostrar los bloques Client y Server. El segundo, una tabla (probablemente vacía) sin errores. Si algo falla, vuelve a la lección 01-02.

Comprueba también que el puerto que vamos a usar está libre:

ss -tln lista los puertos TCP en escucha (-t TCP, -l en escucha, -n sin resolver nombres). Si no hay coincidencias, grep falla y el || ejecuta el echo. Si algo estuviera escuchando en 8080, usa 8081 en todos los comandos de la lección.

Empecemos por lo mínimo:

Parece trivial, pero han pasado muchas cosas. Desglose de la línea:

Y la secuencia interna, que ya conoces de la lección 01-03: el cliente llamó al daemon, el daemon comprobó que tenía alpine:3.20 en local, creó un contenedor apilando una capa de escritura sobre las capas de la imagen, pidió a containerd que arrancara el proceso echo, este escribió en su salida estándar, y esa salida se transmitió por el socket hasta tu terminal.

Como no has usado -d, el contenedor se ejecuta en primer plano: tu terminal queda conectada a su salida y no recupera el control hasta que el proceso termina.

Probemos algo un poco más largo:

Aquí el comando es sh -c "...": se lanza un shell dentro del contenedor y se le pasa una cadena con varias órdenes. Es el patrón habitual cuando necesitas encadenar comandos, porque docker run solo acepta un ejecutable con sus argumentos, no una línea de shell con ; o &&.

Y algo que dura un rato, para que veas el primer plano de verdad:

Las líneas salen de una en una, con un segundo de pausa. Tu terminal está bloqueada mientras tanto: eso es primer plano. Si pulsas Ctrl+C durante la ejecución, envías una señal de interrupción al proceso y el contenedor termina antes de tiempo.

Esta es la regla más importante de toda la lección:

Un contenedor vive exactamente lo que vive su proceso principal. Cuando ese proceso termina, el contenedor pasa a estado Exited. No hay nada más que "apagar".

Compruébalo:

Vacío: ninguno de los tres contenedores anteriores sigue vivo.

Los tres están ahí, parados, con código de salida 0 (terminaron bien). Ocupan un poco de disco cada uno.

Este comportamiento explica un tropiezo clásico de principiantes:

El segundo comando no muestra nada, y la reacción típica es "el contenedor no arranca". Sí arrancó: la imagen alpine tiene como comando por defecto /bin/sh, un shell que, al no tener terminal interactiva ni entrada, no encuentra nada que hacer y termina inmediatamente. El contenedor hizo su trabajo y murió en milisegundos.

Para que un contenedor siga vivo necesita un proceso que no termine: un servidor web esperando peticiones, una base de datos, o un shell con una terminal interactiva conectada. Eso es lo que veremos ahora.

Vamos a levantar un servidor web Nginx, que es exactamente eso: un proceso que se queda escuchando indefinidamente.

Analicemos opción por opción, porque cada una resuelve un problema concreto:

Esa larga cadena hexadecimal de la última línea es el ID completo del contenedor. Como usaste --name, no te hará falta.

Ahora sí:

Up 8 seconds: está vivo, y seguirá vivo porque Nginx no termina nunca por sí solo. Nota que docker ps sin -a ya lo muestra, a diferencia de los contenedores anteriores.

La columna PORTS merece un apartado propio porque es donde más gente se atasca.

Un contenedor tiene su propia pila de red: su propia interfaz, su propia dirección IP interna y sus propios puertos. Nginx escucha en el puerto 80 de esa red interna, que desde tu máquina no es accesible directamente. La opción -p crea un puente.

La sintaxis se lee siempre de fuera hacia dentro:

• El primero es el de tu máquina: el que escribes en el navegador. Lo eliges tú y debe estar libre.
• El segundo es el del contenedor: en el que escucha la aplicación. No lo eliges tú, lo determina la aplicación (Nginx usa el 80, PostgreSQL el 5432, Redis el 6379, y la API de Aurora Libros usará el 3000).

Variantes útiles:

Sin -p, el contenedor funciona perfectamente pero es inalcanzable desde fuera. Es lo correcto para servicios internos: en el módulo 4, aurora-db y aurora-cache no publicarán puertos, porque solo deben ser accesibles desde aurora-api, no desde Internet.

Solo las cabeceras, para ver el estado HTTP:

-I pide solo las cabeceras (método HEAD). El 200 OK confirma que el servidor responde.

Abre ahora http://localhost:8080 en tu navegador: verás la página de bienvenida de Nginx. Acabas de servir una web desde un contenedor sin haber instalado Nginx en tu sistema. Si ejecutas nginx -v en tu terminal, lo más probable es que no exista el comando: todo está dentro del contenedor.

Ahí están tus dos visitas: la de curl y la del navegador, identificadas por su user agent. La IP 172.17.0.1 es la de tu máquina vista desde la red interna de Docker.

Opciones muy útiles:

Prueba docker logs -f aurora-web-demo, recarga el navegador y verás aparecer la línea en tiempo real. Ctrl+C corta el seguimiento sin afectar al contenedor (una duda muy habitual: no, no lo paras).

Devuelve el nombre de lo que ha parado. Verifica:

Dos cosas: docker ps ya no lo muestra, y en docker ps -a la columna PORTS está vacía (el mapeo del puerto 8080 se ha liberado). Confírmalo:

Nadie escucha. El contenedor sigue existiendo, pero no está en ejecución.

Vuelve a funcionar, con la misma configuración. Y aquí hay un detalle conceptual importante: no tuviste que repetir -p 8080:80. La configuración se fijó al crear el contenedor y forma parte de él. docker start solo lo reanuda.

Corolario: no puedes cambiar el mapeo de puertos de un contenedor existente. Si necesitas otro puerto, hay que borrarlo y crear uno nuevo. Es una manifestación de la filosofía de contenedores desechables.

Verás los logs del primer arranque y los del segundo, uno detrás de otro: los logs se conservan mientras el contenedor exista.

Si intentas docker rm sin parar primero:

Puedes forzarlo con docker rm -f aurora-web-demo, que para y borra en un paso. Es cómodo en desarrollo, pero mata el proceso sin darle tiempo a cerrar ordenadamente.

Verifica:

El contenedor ha desaparecido de la lista; la imagen nginx:alpine sigue ahí. Una vez más: borrar un contenedor no borra su imagen.

Hasta ahora ejecutabas comandos sueltos. Ahora vas a abrir un shell dentro de un contenedor y moverte por él.

Tres opciones nuevas:

-i y -t casi siempre van juntos (-it): con -i sin -t podrías escribir pero sin prompt ni formato; con -t sin -i verías el prompt pero no podrías escribir.

Tu prompt cambia:

Estás dentro del contenedor. Explora:

El nombre de host es el ID corto del contenedor, no el de tu máquina.

Un sistema de archivos Linux completo... que no es el tuyo. Compruébalo:

Alpine, aunque tu máquina sea Ubuntu, Windows o macOS.

Vacíos: tus documentos no están aquí. El aislamiento del sistema de archivos es real.

Esto es revelador: solo hay dos procesos, y el shell tiene el PID 1. En tu máquina hay cientos de procesos y el PID 1 es systemd. El contenedor tiene su propio espacio de nombres de procesos y no ve los del anfitrión (el mecanismo exacto, en la lección 05-07).

Y sin embargo:

El kernel es el de tu anfitrión. Espacio de usuario de Alpine, kernel de Ubuntu. Esa frase resume qué es un contenedor.

Alpine usa apk como gestor de paquetes:

No está instalado. Instalémoslo:

• apk add instala paquetes (el equivalente de apt install).
• --no-cache evita guardar el índice de paquetes en disco; es la opción estándar en contenedores porque reduce el tamaño.

Funciona. Y algo importante: has instalado curl en el contenedor, no en tu máquina. Tu sistema no se ha tocado.

Crea también un fichero para la siguiente comprobación:

Ahora sal:

Vuelves a tu prompt normal.

No aparece. Gracias a --rm, el contenedor se eliminó automáticamente al terminar su proceso. Con él se fueron su capa de escritura, el curl que instalaste y el fichero /prueba.txt.

Confírmalo abriendo otro:

Es la lección 01-05 en carne y hueso: cada contenedor nace limpio de la imagen inmutable. Los cambios viven en su capa de escritura y mueren con él.

--rm es una opción excelente para pruebas y comandos puntuales: te ahorra la acumulación de contenedores parados. No la uses en servicios que quieras poder reanudar.

Nginx sirviendo su página por defecto está bien para probar, pero queremos nuestro contenido. Vamos a crear la primera página de Aurora Libros.

Crea index.html con este contenido:

La opción nueva es -v (--volume), y su sintaxis se lee igual que -p, de fuera hacia dentro:

Compruébalo:

Y en el navegador, en http://localhost:8080, verás la página de Aurora Libros con su catálogo. El fichero sigue estando en tu disco; el contenedor simplemente lo ve montado en su sistema de archivos.

Edita index.html en tu editor y añade un libro:

Guarda y recarga el navegador. El cambio aparece al instante, sin reconstruir nada ni reiniciar el contenedor. El montaje es una ventana en vivo entre tu disco y el contenedor.

Este patrón —montar el código fuente dentro del contenedor para desarrollar sin reconstruir— es la base del flujo de desarrollo local que verás en la lección 04-07.

Nota importante. Este uso de -v es puramente introductorio: es un bind mount, que monta una ruta de tu máquina. Existe otro tipo, los volúmenes gestionados por Docker, que es lo que necesitará aurora-db para no perder el catálogo. Las diferencias, cuándo usar cada uno y las implicaciones de permisos y rendimiento son el contenido completo de la lección 03-06.

Dejemos el sistema como estaba:

• Los dos primeros paran y borran el contenedor de Nginx.
• container prune -f elimina cualquier otro contenedor parado que hayas dejado por el camino.

Comprueba:

Sin contenedores; las imágenes (alpine:3.20, nginx:alpine, hello-world) intactas, listas para reutilizarse sin descargarlas de nuevo. Tu fichero ~/aurora-libros/web/index.html también sigue en su sitio: lo necesitarás en las próximas lecciones.

• Bind for 0.0.0.0:8080 failed: port is already allocated. El puerto del host ya está ocupado, casi siempre por otro contenedor tuyo. Búscalo con docker ps y páralo, o publica en otro puerto (-p 8081:80).
• Invertir el orden de -p. -p 80:8080 con Nginx no funciona: estarías reenviando el puerto 80 del host al 8080 del contenedor, donde no escucha nadie. Recuerda: host:contenedor, de fuera hacia dentro.
• docker run -d con un comando que termina. docker run -d alpine echo hola arranca y muere al instante. -d no mantiene vivo nada: solo desconecta tu terminal. Para seguir vivo hace falta un proceso que no termine.
• Rutas relativas en -v. -v ./web:/usr/share/nginx/html puede fallar según la versión y el shell. Usa siempre rutas absolutas: $(pwd)/web o ~/....
• Montar un directorio sobre uno que ya tiene contenido. El montaje oculta lo que hubiera en esa ruta dentro de la imagen. Si montas un directorio vacío sobre /usr/share/nginx/html, Nginx devolverá 403 o 404 porque ya no ve su index.html.
• Confundir Ctrl+C con parar el contenedor. En docker logs -f o docker attach, Ctrl+C solo corta tu conexión. En un contenedor en primer plano, sí interrumpe el proceso y lo termina.
• Consejo: usa --rm para todo lo desechable. Pruebas, comandos puntuales, shells exploratorios. Te ahorrará limpiezas.
• Consejo: nombra siempre con --name. aurora-web-demo es infinitamente más manejable que stupefied_swanson, y hace que los filtros por nombre funcionen.
• Consejo: si un contenedor muere nada más arrancar, docker logs primero. Los logs se conservan aunque esté parado, y ahí está casi siempre la explicación.

Levanta dos contenedores de Nginx simultáneamente a partir de la misma imagen: uno llamado aurora-web-es en el puerto 8080 y otro aurora-web-en en el 8081, cada uno sirviendo un index.html distinto (uno en español y otro en inglés). Comprueba con curl que cada puerto devuelve su página. Después responde: ¿cuántas copias de la imagen nginx:alpine hay en tu disco?, ¿cuánto ocupa la capa de escritura de cada contenedor (docker ps -as)? Al terminar, bórralos ambos en un único comando.

Ejecuta este contenedor, que está mal configurado a propósito:

(Crea antes /tmp/carpeta-que-no-uso vacía con mkdir -p /tmp/carpeta-que-no-uso.)

Visita http://localhost:8080 y observa el error. Después: (a) ¿está el contenedor en ejecución?, (b) ¿qué código HTTP devuelve y por qué?, (c) usa docker logs para encontrar el mensaje de error exacto de Nginx, y (d) explica en términos de montajes qué ha pasado y cómo lo arreglarías.

Abre un contenedor interactivo de alpine:3.20 y otro de nginx:alpine (en dos terminales, ambos con --rm). En cada uno, averigua: (a) el sistema operativo del espacio de usuario, (b) la versión del kernel, (c) el PID 1 y cuántos procesos hay, y (d) si existe el directorio /usr/share/nginx/html y qué contiene. Explica las diferencias y las coincidencias entre los dos contenedores, y qué te dice cada una sobre la naturaleza de los contenedores.

Solución al ejercicio 1

Aquí se montan directorios en lugar de ficheros sueltos, que es lo habitual con Nginx. Los dos contenedores usan puertos distintos del host (8080 y 8081) pero ambos el 80 dentro: no hay conflicto, porque cada contenedor tiene su propia pila de red y su propio puerto 80.

Respuestas: hay una sola copia de la imagen en disco, compartida por los dos contenedores. Cada capa de escritura ocupa alrededor de 1 kB. El "virtual 52.5MB" incluye las capas compartidas de la imagen, que no se cuentan dos veces. Levantar el segundo contenedor costó prácticamente cero disco: es la densidad de la lección 01-01, medida.

rm -f para y borra en un paso, y acepta varios nombres.

Solución al ejercicio 2

(a) Sí, el contenedor está en ejecución:

Nginx arrancó correctamente. El problema no es el arranque, sino el contenido que sirve.

(b) Devuelve 403 Forbidden:

Es 403 y no 404 porque el directorio raíz existe (lo montaste) pero está vacío: no hay index.html que servir y Nginx no permite listar directorios por defecto.

(c) Los logs:

El mensaje es explícito: directory index ... is forbidden.

(d) Qué ha pasado: el montaje oculta el contenido original de esa ruta en la imagen. La imagen nginx:alpine trae su propio index.html en /usr/share/nginx/html, pero al montar encima un directorio vacío de tu máquina, ese contenido deja de ser visible (no se borra: sigue en la capa de la imagen, simplemente queda tapado). Nginx encuentra un directorio vacío y responde 403.

Arreglos posibles: poner un index.html en /tmp/carpeta-que-no-uso, montar un directorio que sí tenga contenido, o no montar nada si querías la página por defecto.

Nota que no hace falta reiniciar el contenedor: el montaje es en vivo, así que en cuanto el fichero existe en tu disco, Nginx lo sirve.

Solución al ejercicio 3

(La imagen de Nginx también trae un shell, así que se puede entrar en ella igual.)

En cada uno:

Resultados y su lectura:

Las conclusiones importantes: los contenedores comparten el kernel (b) pero tienen sistemas de archivos y espacios de procesos aislados (c, d); dos imágenes pueden compartir su base y diferenciarse solo en las capas superiores (a); y pasar un comando a docker run sustituye el comando por defecto de la imagen, por lo que entrar con sh en la imagen de Nginx te da el sistema de archivos de Nginx sin Nginx ejecutándose.

Ya has creado, gestionado y destruido contenedores con tus propias manos. Te llevas la regla que gobierna todo lo demás: un contenedor vive lo que vive su proceso principal; si ese proceso termina, el contenedor pasa a Exited, y por eso docker run alpine "no hace nada" mientras docker run nginx:alpine se queda vivo indefinidamente.

Sabes lanzar contenedores en primer plano y en segundo plano con -d, nombrarlos con --name, y sobre todo publicar puertos con -p host:contenedor, leyendo la sintaxis siempre de fuera hacia dentro; has comprobado que el mapeo se fija al crear el contenedor y que docker start lo reanuda con la misma configuración. Has recorrido el ciclo completo —logs, stop, start, rm—, has entrado dentro de un contenedor con -it para ver con tus ojos el aislamiento del sistema de archivos y de los procesos junto al kernel compartido, y has confirmado con --rm que todo lo que escribes dentro muere con el contenedor. Y has servido la primera página de Aurora Libros montando un fichero de tu disco con -v, con edición en vivo incluida.

Tienes las tres piezas del rompecabezas —imágenes, contenedores y comandos— y una página web funcionando. Lo que aún no tienes es el problema real que justifica todo esto. En la última lección del módulo, El Proyecto del Curso: la Plataforma Aurora Libros, conocerás la empresa, su arquitectura objetivo y el código completo de su API, e intentarás arrancarla sin Docker para vivir en primera persona el calvario que el resto del curso va a resolver.