02 - Docker

Los proyectos no viven solo del código: alrededor hay una base de datos, un almacenamiento de ficheros, un proxy… Cada pieza es un servidor ajeno, con su instalación y su configuración. Docker permite empaquetar cada pieza con todo lo que necesita y ejecutarla aislada y reproducible, en cualquier máquina y sin instalar nada más.

Instalar y configurar cada servidor a mano tiene dos problemas: el trabajo no se traslada (lo que funciona en una máquina no va igual en otra: versiones y configuraciones distintas) y las piezas comparten el sistema, así que una actualización toca a todas. Docker resuelve ambos: cada servidor se empaqueta en una imagen con su versión exacta y corre en un contenedor aislado del resto.

La imagen es la plantilla; el contenedor, la instancia. De una imagen salen tantos contenedores como se quieran.

Ambos aíslan; el contenedor comparte el kernel del host y por eso es tan ligero. Para servidores de aplicación es el enfoque dominante.

Los nombres de imagen siguen el patrón usuario/imagen:tag: usuario identifica al publicador y es opcional —si falta, la imagen es oficial—; imagen es obligatorio; tag señala la versión y también es opcional. Sin tag se descarga latest, que no siempre es la más nueva: es la versión que los creadores etiquetaron como tal. Fijar la versión (mariadb:11, no mariadb) es lo reproducible.

Docker Hub es el registro público: en la web se busca y se distinguen las imágenes oficiales. En una terminal sin entorno gráfico, lo mismo lo hace docker search.

$ docker search mariadb
$ docker pull mariadb:11
$ docker images
$ docker rmi mariadb:11

• La salida de docker images muestra REPOSITORY, TAG, IMAGE ID, fecha y tamaño.
• Los comandos tienen variantes largas equivalentes (docker image pull, docker image rm…); las cortas son de uso habitual.
• Una imagen en uso por algún contenedor no se deja eliminar: primero hay que eliminar el contenedor.

docker run crea y arranca un contenedor desde una imagen; si no está en local, la descarga antes. Sus opciones completan la configuración del contenedor en el momento de crearlo:

$ docker run -d -p 8080:80 nginx                       # un servidor web en el 8080 del host
$ docker run -d --name db \
    -e MARIADB_ROOT_PASSWORD=secreto \
    -p 3306:3306 mariadb:11

El contenedor se para y se arranca sin perderse; se elimina y ya no hay nada:

$ docker ps                    # contenedores en ejecución (con -a, también los parados)
$ docker stop db               # lo detiene
$ docker start db              # lo vuelve a arrancar: el mismo contenedor, con lo que tiene dentro
$ docker logs -f db            # sigue la salida del contenedor
$ docker rm db                 # lo elimina (con -f también si está en marcha)

• Solo rm destruye el contenedor y con él lo que guardó dentro; los datos valiosos van en volúmenes (sección 5).

docker exec ejecuta comandos en un contenedor en marcha, sin detenerlo:

$ docker exec -it db bash      # una terminal dentro del contenedor (para salir, exit)
$ docker exec db ls /app       # un comando suelto, sin terminal

• -it asigna un terminal interactivo: es lo que permite abrir una shell.
• El contenedor debe estar en ejecución; si no, no se puede hacer exec.

Puertos: -p 9000:9000 conecta el puerto del host con el del contenedor. Sin él, el servicio no es accesible desde fuera; entre contenedores no hace falta: se ven por la red interna (tema 08).

Volúmenes: el sistema de ficheros del contenedor es efímero: al eliminar el contenedor se pierde lo que guardó dentro. Un volumen vive fuera del contenedor y persiste:

$ docker run -d --name db -v db-data:/var/lib/mysql mariadb:11

Los datos de MariaDB quedan en el volumen db-data y sobreviven al contenedor.

$ docker volume create db-data     # crear el volumen por adelantado
$ docker volume inspect db-data    # sus datos: el Mountpoint es la carpeta real del host

• Los nombrados son la forma normal de persistir datos de servidores (bases de datos, almacenamiento).
• Los bind mounts sirven para compartir una carpeta del host con el contenedor: configuración, código, contenido estático.

Los servidores oficiales ya vienen empaquetados; la aplicación propia se define en un Dockerfile: un fichero de texto que describe cómo se construye una imagen —de qué parte, qué añade y con qué comando arranca.

FROM python:3
WORKDIR /app
COPY app.py .
CMD ["python", "app.py"]

$ docker build -t miapp:1.0 .      # construye la imagen desde este directorio
$ docker run miapp:1.0

• La imagen base oficial de python ya trae el intérprete; el Dockerfile solo añade el código y el arranque.
• El fichero se llama exactamente Dockerfile, sin extensión: Docker lo busca con ese nombre.
• -t fija nombre y *tag* de la imagen (miapp:1.0); sin tag tomaría latest.
• La imagen construida corre igual en cualquier máquina. Si la aplicación espere peticiones, publica su puerto como cualquier contenedor (-p).

Cada contenedor nace aislado en su propia red. Para que dos contenedores se vean, comparten una red: un conmutador virtual —de tipo bridge por defecto— donde se alcanzan por el nombre del contenedor, como un hostname.

$ docker network create mi-red
$ docker run -d --name db --network mi-red mariadb:11
$ docker run -d --name app --network mi-red alpine
$ docker exec app ping db          # db responde a su nombre: la red los une

• Otros *drivers* existen —host comparte la pila de red de la máquina, none aísla del todo, overlay conecta varias máquinas—; para el uso habitual basta el bridge de siempre.
• La clave del módulo está aquí: entre contenedores no son necesarias las direcciones ni los puertos publicados; los nombres bastan. Lo retoma la arquitectura del tema 08.

Con varios contenedores, los comandos manuales no escalan: hay que recordar orden, puertos y variables de cada uno. Docker Compose describe el sistema completo —servicios, redes y volúmenes— en un fichero compose.yaml y lo levanta con un solo comando:

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html

  db:
    image: mariadb:11
    environment:
      MARIADB_ROOT_PASSWORD: secreto
      MARIADB_DATABASE: miapp
    volumes:
      - db-data:/var/lib/mysql

volumes:
  db-data:

• Cada entrada de services es un servicio: la receta de su contenedor —imagen, puertos, entorno, volúmenes—.
• Los volúmenes nombrados se declaran al final, una vez, y los servicios los comparten.
• El *bind mount* de la sección 5 se usa igual; en compose.yaml, una ruta que empieza por . es relativa al propio fichero.
• Compose crea una red propia del proyecto entre los servicios: web alcanza a db por su nombre, con la red de la sección 7 hecha automáticamente.

Con un solo servicio Compose parece excesivo; su valor aparece al describir sistemas con varios servidores: es el caso del tema de arquitectura (tema 08).