Domina los contenedores, volúmenes y redes de Docker

ago. 1, 2025

Domina el ciclo de vida de tus contenedores, redes y volúmenes antes de dar el salto a producción.

Si has seguido la serie hasta aquí, ya has recorrido un camino nada despreciable. Empezamos con el Capítulo 1, donde descubrimos qué es una imagen, creamos nuestros primeros contenedores con docker run y aprendimos a limpiarlos. En el Capítulo 2 nos metimos de lleno en la administración básica: comandos como ps, logs, stop e inspect dejaron de sonarnos a chino y empezamos a sentirnos cómodos moviéndonos por el universo Docker. El viaje continuó con el Capítulo 3, en el que dockerizamos una API Node/Express: escribimos nuestro primer Dockerfile, compilamos la imagen y desplegamos la aplicación sin miedo a “en mi máquina funciona”. Y en el Capítulo 4 dimos un salto cualitativo al introducir Docker Compose: añadimos PostgreSQL y Redis, levantamos todo con un único docker compose up y, sobre la marcha, prometimos que más adelante abriríamos la famosa “letra pequeña” de Docker.

Ha llegado ese momento. Antes de aventurarnos en temas un poco más avanzados —optimización de imágenes, despliegues en cloud u orquestación— necesitamos entender cómo Docker gestiona realmente los recursos fundamentales que sostienen tu infraestructura:

A lo largo del capítulo iremos siguiendo un pequeño ejemplo práctico que funcionará como laboratorio de pruebas. Con él veremos, paso a paso, qué ocurre cuando detenemos, eliminamos o recreamos contenedores y recursos: los registros de Nginx se quedarán a salvo en un bind mount, la base de datos vivirá en un volumen persistente y la caché demostrará qué significa guardar los datos solo en memoria.

Cada bloque te presentará un concepto y, acto seguido, te pedirá uno o dos comandos para que veas el efecto en tiempo real. Nada de teoría suspendida en el aire: aprenderás tocando teclas.

En concreto, descubrirás cómo:

En concreto, descubrirás cómo:

1. Arrancar, detener y reiniciar contenedores individuales sin perder datos ni afectar al resto del entorno.
2. Inspeccionar y gestionar imágenes, contenedores y redes activas mediante comandos esenciales.
3. Probar diferentes formas de almacenamiento: volúmenes temporales en memoria (tmpfs), volúmenes persistentes nombrados y bind mounts en el host.
4. Comprobar qué datos sobreviven al reiniciar, detener o eliminar servicios.
5. Entender cómo funcionan las redes internas y externas y cómo influyen en la comunicación entre contenedores.

¿Listo para ensuciarte las manos? Vamos a crear y explicar la estructura de archivos, luego empezaremos a experimentar.

Configuración del ejemplo práctico

1. Estructura de ficheros

Antes de profundizar, echemos un vistazo a los archivos que conforman nuestro entorno. Esta es la fotografía inicial:

    .
    ├── docker-compose.yml          # orquesta todos los servicios
    ├── api/                        # código de la API Node/Express
    │   ├── Dockerfile
    │   ├── package.json
    │   └── server.js
    ├── db/                         # scripts para inicializar PostgreSQL
    │   └── init.sql
    ├── nginx/                      # proxy inverso
    │   └── nginx.conf
    └── logs/                       # se crea en tiempo de ejecución (bind mount)
        ├── api/
        └── nginx/
    

Para este ejemplo utilizaremos seis archivos de configuración, son los siguientes:

1.0 .env — variables de entorno de ejemplo

    # .env
    POSTGRES_USER=labuser
    POSTGRES_PASSWORD=labsupersecret
    POSTGRES_DB=labdb

    # otras variables que usa la API
    PGHOST=db
    PGPORT=5432
    PGUSER=$POSTGRES_USER
    PGPASSWORD=$POSTGRES_PASSWORD
    PGDATABASE=$POSTGRES_DB
    REDIS_HOST=cache
    REDIS_PORT=6379
    NODE_ENV=development
    

⚠ Advertencia
Este archivo está pensado solo para desarrollo: incluye contraseñas en texto plano y valores que no deberías exponer en producción.
En un entorno real utilizarías proveedores de secretos (Docker Secrets, HashiCorp Vault, variables de entorno del orquestador…) y generarías credenciales únicas por entorno.

1.1 docker-compose.yml — la pieza central

    version: "3.9"

    services:
    api:
        build: ./api
        container_name: lab_api
        env_file: .env
        depends_on:
        db:
            condition: service_healthy
        cache:
            condition: service_started
        volumes:
        - ./logs/api:/usr/src/app/logs
        networks:
        - backend
        - frontend
        ports:
        - "3000:3000"
        healthcheck:
        test: ["CMD", "node", "-e", "require('http').get('http://localhost:3000/health',r=>process.exit(r.statusCode===200?0:1)).on('error',()=>process.exit(1))"]
        interval: 30s
        retries: 3

    db:
        image: postgres:15
        container_name: lab_db
        env_file: .env
        volumes:
        - db-data:/var/lib/postgresql/data
        - ./db/init.sql:/docker-entrypoint-initdb.d/init.sql:ro
        healthcheck:
        test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER"]
        interval: 10s
        retries: 5
        networks:
        - backend

    cache:
        image: redis:7
        container_name: lab_cache
        tmpfs:
        - /data
        networks:
        - backend

    nginx:
        image: nginx:1.27-alpine
        container_name: lab_proxy
        ports:
        - "80:80"
        volumes:
        - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
        - ./logs/nginx:/var/log/nginx
        depends_on:
        - api
        networks:
        - frontend

    volumes:
    db-data:

    networks:
    backend:
        driver: bridge
        internal: true
    frontend:
        driver: bridge
    

Hay varios puntos clave a tener en cuenta en este compose:

• volumes: declara db-data, un named volume que persiste la base de datos aunque borres el contenedor db.
• El bind mount ./logs/api guarda los registros de la API directamente en tu máquina.
• La red backend es internal: true; ni Nginx ni tu host pueden acceder a PostgreSQL o Redis por error.
• El healthcheck evita que la API acepte tráfico antes de que PostgreSQL esté operativo.

1.2 Carpeta api/ — para comunicarnos con los servicios internos

Dockerfile

    FROM node:lts-slim
    WORKDIR /usr/src/app
    COPY package*.json ./
    RUN npm install --omit=dev
    COPY . .
    EXPOSE 3000
    CMD ["node", "server.js"]
    

• Base node:lts-slim para mantener la imagen ligera.
• Copia primero package*.json para aprovechar la caché de capas.

package.json

    {
    "name": "docker-resources-api",
    "version": "1.0.0",
    "description": "Mini API para el laboratorio de gestión de recursos Docker",
    "main": "server.js",
    "type": "module",
    "scripts": {
        "start": "node server.js"
        },
    "dependencies": {
        "express": "^5.1.0",
        "pg": "^8.16.3",
        "ioredis": "^5.6.1"
        }
    }
    

server.js

El archivo api/server.js es el “cerebro” de nuestro ejemplo práctico. Aglutina las rutas HTTP que usaremos para demostrar cómo viven los datos en Docker y, de paso, ilustra la conexión a dos servicios internos: Redis (memoria) y PostgreSQL (disco).

    import express from 'express';
    import pkg from 'pg';
    import Redis from 'ioredis';

    const { Pool } = pkg;
    const app = express();
    const pool = new Pool();          // se conecta a db:5432 por DNS interno
    const redis = new Redis({ host: 'cache' });

    app.get('/health', (_, res) => res.send('OK'));

    app.get('/visits', async (_, res) => {
    const visits = await redis.incr('counter');
    res.json({ visits });
    });
    
    app.get('/pgvisits', async (_, res) => {
    const { rows } = await pool.query(
        'UPDATE pg_visits SET counter = counter + 1 WHERE id = 1 RETURNING counter;'
    );
    res.json({ pgVisits: rows[0].counter });
    });    

    // server.js
    app.get('/', (_, res) =>
      res.send(`
        <h1>Docker Resources API</h1>
        <p>Rutas disponibles:</p>
        <ul>
          <li><a href="/visits">/visits</a> – contador Redis</li>
          <li><a href="/pgvisits">/pgvisits</a> – contador PostgreSQL</li>
          <li><a href="/health">/health</a> – health‑check</li>
        </ul>
      `)
    );

    app.listen(3000, () =>
    console.log('API listening on http://localhost:3000')
    );
    

El cliente no necesita saber los puertos internos: Docker resuelve los nombres de servicio (db, cache) y la red frontend expone solo el puerto 80 del proxy Nginx.

1.3 Carpeta db/ — script de inicialización de la base de datos

    CREATE TABLE IF NOT EXISTS pg_visits (
      id      SERIAL PRIMARY KEY,
      counter INT NOT NULL
    );
    INSERT INTO pg_visits (counter) VALUES (0);
    

• Se ejecuta solo la primera vez, cuando el volumen db-data está vacío.

1.4 Carpeta nginx/ — proxy inverso

    
    http {
      upstream api_upstream { server api:3000; }
      server {
        listen 80;
        location / {
          proxy_pass http://api_upstream;
          proxy_set_header Host $host;
          proxy_set_header X-Forwarded-For $remote_addr;
        }
      }
    }
        

• Encamina el tráfico externo a la API sin exponer directamente el puerto 3000.

Con esta infraestructura clara, estás listo para explorar imágenes, contenedores, volúmenes y redes en las siguientes secciones.

2. Ejemplo práctico

Partiremos con los conceptos más básicos—y a la vez más frecuentes—: qué es una imagen, qué es un contenedor y cómo se comportan cuando los utilizamos.

2.0 Arrancando el entorno

  
  docker compose up -d
  

2.1 Inspecciona lo que tienes

    # ¿Qué contenedores están vivos?
    docker compose ps
    
    # ¿Y qué imágenes hay disponibles?
    docker image ls
    

Recuerda
Una imagen es solo‑lectura; un contenedor añade una capa RW encima que desaparece al destruirlo con docker rm.

2.2 Detén y vuelve a levantar la API

  
    # Detén solo la API (la BD y Redis siguen vivos)
    docker compose stop api
    
    # Vuelve a levantarla
    docker compose start api
    

La API recupera sin problema su estado porque no guardaba datos en el contenedor: los logs están en el bind mount ./logs/api y la información persistente en db-data o en la RAM de Redis.

3. Volúmenes y montajes — dónde viven los datos

Para ilustrar los diferentes tipos de almacenamiento de datos en Docker, vamos a ver varios mini‑experimentos que muestran cómo cambian (o no) según el tipo utilizado.

A. Redis (tmpfs)

Por qué lo hacemos
Comprobar que los datos guardados solo en RAM se pierden al reiniciar el servicio.

Pasos

  
    # 1 – consulta el contador
    curl -s http://localhost/visits
    
    # 2 – reinicia solo Redis
    docker compose restart cache
    
    # 3 – vuelve a consultar
    curl -s http://localhost/visits
    

Resultado esperado
El contador vuelve a 1 → Redis estaba usando tmpfs; al reiniciar se borró todo.

B. PostgreSQL (named volume)

Por qué lo hacemos
Ver que un volumen nombrado persiste incluso si el contenedor se destruye o reinicia.

Pasos

    # 1 - incrementa el contador varias veces
    curl -s http://localhost/pgvisits
    curl -s http://localhost/pgvisits
    
    # 2 – reinicia Postgres
    docker compose restart db
    
    # 3 – comprueba de nuevo
    curl -s http://localhost/pgvisits
    

Resultado esperado
El número sigue aumentando → la tabla vive en el volumen db-data. Los datos persisten entre sesiones.

C. Bind mount de logs (Nginx)

Por qué lo hacemos
Ver que Docker recrea la carpeta montada si no existe al arrancar el contenedor.

Pasos

    # 1 – quita el contenedor del proxy
    docker compose rm -sf nginx
    
    # 2 – borra la carpeta de logs en el host
    rm -rf logs/nginx
    
    # 3 – vuelve a lanzar Nginx
    docker compose up -d nginx
    

Resultado esperado
La carpeta logs/nginx y los archivos access.log / error.log se crean otra vez en tu host. Al simplemente haber reiniciado el contenedor con la API, los datos de visitas de Redis y PostgreSQL siguen intactos.

4. Redes Docker — quién ve a quién

Antes de que un byte de información viaje de un contenedor a otro, debe haber una red que los conecte. En Docker las redes actúan como pequeñas LAN virtuales: determinan qué servicios “se ven” entre sí, qué puertos se expone al exterior y qué tráfico queda completamente aislado. Si dos contenedores no comparten red, es como si vivieran en máquinas distintas.

4.1 Redes internas y externas

Objetivo
Saber cuántas redes ha creado Docker Compose, qué contenedores cuelgan de cada una y si la red back-end está realmente aislada del host.

    # Muestra todas las redes del sistema
    docker network ls
    
    # Inspeccionando la red podemos ver su configuración
    docker network inspect dockerresources_backend
    
    # Ver si es interna (no accesible desde el host)
    docker network inspect dockerresources_backend | grep "Internal"
    

backend es privada (internal: true); el host no puede acceder.

4.2 Desenchufa y enchufa Redis

Objetivo
Ver qué pasa cuando una aplicación pierde la conexión con otro servicio porque están desconectadas o en redes distintas.

    # 1 – Averigua el nombre exacto de la red backend
    docker network ls | grep _backend
    
    # 2 – Desconecta el contenedor de Redis
    docker network disconnect dockerresources_backend lab_cache
    
    # 3 – Llama al contador volátil
    curl -s --max-time 2 http://localhost/visits   # ⟶ timeout
    
    # 4 – Re‑conecta Redis
    docker network connect dockerresources_backend lab_cache
    
    # 5 – Inténtalo de nuevo
    curl -s http://localhost/visits   # ⟶ vuelve a contar
    

• Un contenedor fuera de la red correcta “no existe” para la API.
• Reconectarlo es inmediato y no corrompe los datos de Redis.

5. Es hora de romperlo todo (limpieza total)

En este bloque vamos a borrar absolutamente todos los recursos que hemos creado en el laboratorio —contenedores, imágenes, volúmenes y redes—para que veas qué sobrevive y qué no.

Requisito: En caso de querer conservar el estado actual del entorno hasta este punto, asegúrate de hacer un backup de los volúmenes y aquello que quieras conservar.

5.1 Parar y desmontar la pila

    # Detén y elimina todos los contenedores del proyecto
    docker compose down
      

5.2 Eliminar imágenes del proyecto

    # Borra la imagen construida de la API
    docker rmi docker-resources-api 2>/dev/null || true
    
    # (Opcional) Borra las imágenes base si no las usas en otros proyectos
    docker rmi node:lts-slim postgres:15 redis:7 nginx:1.27-alpine 2>/dev/null || true
    

5.3 Volúmenes y redes

    # Elimina el volumen con datos de Postgres
    docker volume rm dockerresources_db-data
    
    # Elimina las redes creadas por Compose (si siguen ahí)
    docker network rm dockerresources_backend dockerresources_frontend 2>/dev/null || true
     

En este punto tu proyecto está “vacío”: solo queda el código y los ficheros de configuración de los servicios Docker. Si levantamos el servicio de nuevo, éste creará todo de nuevo junto a una imagen fresca de la API.

Para terminar, hagamos balance. En este capítulo hemos abierto la tapa del “motor” de Docker y hemos jugado con todos sus engranajes principales: creamos imágenes ligeras con un Dockerfile, vimos cómo los contenedores añaden una fina capa de lectura-escritura que puede borrarse sin piedad, descubrimos que los datos importantes deben vivir en volúmenes y comprobamos que las redes son autopistas internas que puedes desconectar y reconectar en caliente. Además, también vimos cómo identificar rápidamente qué hay corriendo en tu host, a limpiar recursos huérfanos sin desmontar el entorno, etc; todo ello utilizando comandos reales simulando un entorno funcional. Para próximos capítulos seguiremos ahondando en temas más avanzados. Happy Coding!