Redes y puertos en Docker Compose, y los comandos del día a día

Hola, bienvenido. Docker Compose crea una red para cada proyecto y registra cada servicio con su nombre en un DNS interno, así que desde un contenedor llegas a otro con el nombre del servicio, como mysql, sin saber su IP. Los puertos solo hacen falta para entrar desde tu máquina: con ports publicas uno, y sin él el servicio solo es accesible desde dentro de la red.

En esta lección vamos a ver esa red por dentro, a publicar el puerto de MySQL para conectarte con tu cliente de base de datos, y a repasar los comandos que vas a usar cada día con Compose, incluido cómo limpiar lo que Docker va acumulando. Es la última lección de la primera sección, y al terminarla tendrás todas las piezas que vamos a buscar en Laravel Sail.

Cuando lanzamos docker compose up -d por primera vez, Compose creó una red llamada tasks_default, con el nombre del proyecto delante. Puedes verla con:

Las 3 primeras las crea Docker al instalarse, y en tu máquina puede haber más si tienes otros proyectos. Todos los servicios de tasks están conectados a tasks_default, y cada uno se registra con su nombre en el DNS interno de Docker. Lo comprobamos preguntando desde el contenedor de app por el nombre mysql:

Por eso funciona DB_HOST: mysql: PDO pregunta por mysql, el DNS de Docker responde con la IP del contenedor y la conexión llega. Y por eso funciona fastcgi_pass app:9000 en Nginx. La IP que veas en tu máquina será otra, y además cambia cada vez que se recrea el contenedor. La propia documentación de Compose lo recomienda: usa siempre el nombre del servicio, nunca la IP.

Esto también explica el Connection refused que vimos en la lección de Compose. Sin DB_HOST, la aplicación intentaba conectar con 127.0.0.1, y dentro de un contenedor 127.0.0.1 y localhost son el propio contenedor. En el de app solo está PHP-FPM, así que nadie respondía en el 3306.

Hay un caso concreto en el que el DNS nos puede jugar una mala pasada. Nginx resuelve el nombre app al arrancar y se queda con esa IP. Si recreas el contenedor de app y le toca otra IP mientras web sigue en marcha, Nginx responde con un 502 Bad Gateway, porque sigue llamando a la IP antigua. La solución es reiniciar web, como veremos en los comandos del día a día.