{"id":1282,"date":"2026-03-12T14:20:12","date_gmt":"2026-03-12T17:20:12","guid":{"rendered":"https:\/\/maurobernal.com.ar\/blog\/?p=1282"},"modified":"2026-03-12T14:20:12","modified_gmt":"2026-03-12T17:20:12","slug":"docker-compose-de-cero-a-produccion-parte-3","status":"publish","type":"post","link":"https:\/\/maurobernal.com.ar\/blog\/docker-compose-de-cero-a-produccion-parte-3\/","title":{"rendered":"Docker Compose de cero a producci\u00f3n \u2014 Parte 3: Proyectos reales y estrategias Dev vs Prod"},"content":{"rendered":"\n

Llegamos al cierre de la serie Docker Compose de cero a producci\u00f3n<\/strong>. En la Parte 1<\/a> vimos el archivo compose.yaml, en la Parte 2<\/a> los comandos y las dependencias robustas. Ahora lo llevamos a la pr\u00e1ctica: dos proyectos reales completos y la estrategia que uso para manejar configuraciones distintas entre desarrollo y producci\u00f3n.<\/p>\n\n\n\n

Proyecto 1: WordPress + MySQL<\/h2>\n\n\n\n

El ejemplo cl\u00e1sico de un stack de dos niveles: una aplicaci\u00f3n web y su base de datos. Este proyecto completo vive en un solo archivo.<\/p>\n\n\n\n

Estructura del proyecto<\/h3>\n\n\n\n
wordpress_project\/\n\u2514\u2500\u2500 compose.yaml<\/code><\/pre>\n\n\n\n
compose.yaml<\/h3>\n\n\n\n
services:\n  db:\n    image: mysql:8.0\n    container_name: wordpress_db\n    restart: unless-stopped\n    environment:\n      MYSQL_DATABASE: wordpress\n      MYSQL_USER: wp_user\n      MYSQL_PASSWORD: wp_password\n      MYSQL_ROOT_PASSWORD: root_secret_password\n    volumes:\n      - db_data:\/var\/lib\/mysql\n    networks:\n      - app_network\n    healthcheck:\n      test: [\"CMD\", \"mysqladmin\", \"ping\", \"-h\", \"localhost\"]\n      interval: 10s\n      timeout: 5s\n      retries: 5\n      start_period: 30s\n\n  wordpress:\n    image: wordpress:latest\n    container_name: wordpress_app\n    restart: unless-stopped\n    depends_on:\n      db:\n        condition: service_healthy   # Espera que MySQL est\u00e9 listo de verdad\n    ports:\n      - \"8000:80\"\n    environment:\n      WORDPRESS_DB_HOST: db:3306     # 'db' es el nombre del servicio = hostname\n      WORDPRESS_DB_USER: wp_user\n      WORDPRESS_DB_PASSWORD: wp_password\n      WORDPRESS_DB_NAME: wordpress\n    networks:\n      - app_network\n\nnetworks:\n  app_network:\n    driver: bridge\n\nvolumes:\n  db_data:\n    driver: local<\/code><\/pre>\n\n\n\n
Puesta en marcha<\/h3>\n\n\n\n
cd wordpress_project\ndocker compose up -d\n\n# Esperar unos segundos y visitar http:\/\/localhost:8000\n# El instalador de WordPress estar\u00e1 listo<\/code><\/pre>\n\n\n\n
Lo que me parece elegante de este ejemplo: WORDPRESS_DB_HOST: db:3306<\/code>. No hay IP, no hay configuraci\u00f3n de DNS manual. El nombre del servicio db<\/code> funciona directamente como hostname gracias a la red que Compose crea autom\u00e1ticamente. Esto es lo que hace que los entornos sean tan portables.<\/p>\n\n\n\n
Proyecto 2: API REST con Node.js y PostgreSQL<\/h2>\n\n\n\n
Este ejemplo es m\u00e1s representativo del trabajo diario: construimos nuestra propia imagen desde un Dockerfile y configuramos un entorno de desarrollo con hot-reload.<\/p>\n\n\n\n
Estructura del proyecto<\/h3>\n\n\n\n
api_project\/\n\u251c\u2500\u2500 compose.yaml\n\u251c\u2500\u2500 Dockerfile\n\u251c\u2500\u2500 index.js\n\u2514\u2500\u2500 package.json<\/code><\/pre>\n\n\n\n
Dockerfile<\/h3>\n\n\n\n
FROM node:18-alpine\nWORKDIR \/usr\/src\/app\nCOPY package*.json .\/\nRUN npm install\nCOPY . .\nEXPOSE 3000\nCMD [\"npm\", \"start\"]<\/code><\/pre>\n\n\n\n
index.js<\/h3>\n\n\n\n
const express = require('express');\nconst { Pool } = require('pg');\nconst app = express();\n\nconst pool = new Pool({\n  user: process.env.DB_USER,\n  host: process.env.DB_HOST,      \/\/ Viene del ambiente: 'db'\n  database: process.env.DB_NAME,\n  password: process.env.DB_PASSWORD,\n  port: 5432,\n});\n\napp.get('\/', async (req, res) => {\n  try {\n    const result = await pool.query('SELECT NOW()');\n    res.send(`Hora en la base de datos: ${result.rows[0].now}`);\n  } catch (err) {\n    res.status(500).send('Error conectando a la base de datos');\n  }\n});\n\napp.listen(3000, () => console.log('API corriendo en http:\/\/localhost:3000'));<\/code><\/pre>\n\n\n\n
compose.yaml<\/h3>\n\n\n\n
services:\n  db:\n    image: postgres:15-alpine\n    environment:\n      POSTGRES_DB: apidb\n      POSTGRES_USER: apiuser\n      POSTGRES_PASSWORD: apipassword\n    volumes:\n      - pg_data:\/var\/lib\/postgresql\/data\n    healthcheck:\n      test: [\"CMD-SHELL\", \"pg_isready -U apiuser -d apidb\"]\n      interval: 10s\n      timeout: 5s\n      retries: 5\n\n  api:\n    build: .\n    ports:\n      - \"3000:3000\"\n    volumes:\n      - .:\/usr\/src\/app       # Bind mount: cambios en el c\u00f3digo se reflejan al instante\n    environment:\n      DB_HOST: db\n      DB_USER: apiuser\n      DB_PASSWORD: apipassword\n      DB_NAME: apidb\n    depends_on:\n      db:\n        condition: service_healthy\n\nvolumes:\n  pg_data: {}<\/code><\/pre>\n\n\n\n
# La primera vez, --build para construir la imagen\ndocker compose up --build -d\n\n# Verificar que funciona\ncurl http:\/\/localhost:3000\n# \u2192 Hora en la base de datos: 2025-05-01 14:23:45.123456+00<\/code><\/pre>\n\n\n\n
El bind mount (- .:\/usr\/src\/app<\/code>) es el truco de desarrollo: cualquier cambio en el c\u00f3digo se refleja dentro del contenedor sin reconstruir la imagen. Para que los cambios se apliquen autom\u00e1ticamente en Node.js, agreg\u00e1 nodemon<\/code> como dependencia de desarrollo y usalo en el CMD.<\/p>\n\n\n\n
Gesti\u00f3n de entornos: desarrollo vs producci\u00f3n<\/h2>\n\n\n\n
Esta fue una de las lecciones m\u00e1s importantes que aprend\u00ed: nunca uses el mismo archivo compose.yaml sin modificaciones para desarrollo y producci\u00f3n<\/strong>. Las necesidades son opuestas: en desarrollo quer\u00e9s agilidad y debuggear f\u00e1cil; en producci\u00f3n, estabilidad, seguridad y recursos bien definidos.<\/p>\n\n\n\n
Estrategia con compose.override.yaml<\/h3>\n\n\n\n
Compose tiene un mecanismo autom\u00e1tico: si existe un compose.override.yaml<\/code> en el mismo directorio, lo fusiona autom\u00e1ticamente con el compose.yaml<\/code> base al ejecutar docker compose up<\/code>.<\/p>\n\n\n\n
# compose.yaml \u2014 Base (versionado en Git)\nservices:\n  api:\n    build: .\n    restart: unless-stopped\n    environment:\n      - APP_ENV=production<\/code><\/pre>\n\n\n\n
# compose.override.yaml \u2014 Desarrollo (puede NO versionarse si tiene configs locales)\nservices:\n  api:\n    ports:\n      - \"8000:8000\"\n      - \"9229:9229\"        # Puerto de debugging de Node.js\n    volumes:\n      - .:\/app             # Bind mount para hot-reload\n    environment:\n      - APP_ENV=development   # Sobreescribe el valor del base\n\n  # Servicio adicional solo para desarrollo\n  pgadmin:\n    image: dpage\/pgadmin4\n    ports:\n      - \"5050:80\"\n    environment:\n      PGADMIN_DEFAULT_EMAIL: dev@local.com\n      PGADMIN_DEFAULT_PASSWORD: dev<\/code><\/pre>\n\n\n\n
Estrategia con m\u00faltiples archivos expl\u00edcitos<\/h3>\n\n\n\n
# compose.prod.yaml \u2014 Producci\u00f3n\nservices:\n  api:\n    restart: always\n    deploy:\n      resources:\n        limits:\n          cpus: '1.0'\n          memory: 512M\n    logging:\n      driver: \"json-file\"\n      options:\n        max-size: \"10m\"\n        max-file: \"3\"<\/code><\/pre>\n\n\n\n
# Desarrollo (usa override autom\u00e1tico)\ndocker compose up -d\n\n# Producci\u00f3n (combina base + prod expl\u00edcitamente)\ndocker compose -f compose.yaml -f compose.prod.yaml up -d<\/code><\/pre>\n\n\n\n
Archivos .env para variables de entorno<\/h3>\n\n\n\n
Para evitar hardcodear valores en los archivos YAML (especialmente secretos), uso archivos .env<\/code>. Compose los carga autom\u00e1ticamente si existen en el mismo directorio.<\/p>\n\n\n\n
# .env (NO versionar si tiene contrase\u00f1as reales \u2014 agregarlo al .gitignore)\nTAG=15-alpine\nPOSTGRES_USER=miusuario\nPOSTGRES_PASSWORD=supersecreto\nPOSTGRES_DB=miapp<\/code><\/pre>\n\n\n\n
# compose.yaml usando las variables del .env\nservices:\n  db:\n    image: postgres:${TAG}\n    environment:\n      POSTGRES_USER: ${POSTGRES_USER}\n      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}\n      POSTGRES_DB: ${POSTGRES_DB}<\/code><\/pre>\n\n\n\n
Cada desarrollador tiene su propio .env<\/code> local con sus credenciales. El archivo compose.yaml<\/code> se versiona sin datos sensibles. Para producci\u00f3n, las variables se inyectan desde el CI\/CD o desde un gestor de secretos.<\/p>\n\n\n\n
Builds multi-stage para producci\u00f3n<\/h3>\n\n\n\n
Las im\u00e1genes de desarrollo son gordas (incluyen herramientas de build, dependencias de dev, etc.). Las de producci\u00f3n deben ser m\u00ednimas. Los builds multi-stage resuelven esto con un solo Dockerfile:<\/p>\n\n\n\n
# Dockerfile\n# ---- Etapa de Build ----\nFROM node:20-alpine AS builder\nWORKDIR \/app\nCOPY package.json .\nRUN npm install\nCOPY . .\nRUN npm run build\n\n# ---- Etapa de Producci\u00f3n ----\nFROM node:20-slim AS production\nWORKDIR \/app\nCOPY --from=builder \/app\/dist .\/dist\nCOPY --from=builder \/app\/node_modules .\/node_modules\nEXPOSE 3000\nCMD [\"node\", \"dist\/index.js\"]<\/code><\/pre>\n\n\n\n
# compose.yaml\nservices:\n  api:\n    build:\n      context: .\n      target: production   # Solo construye hasta la etapa 'production'<\/code><\/pre>\n\n\n\n
La imagen de producci\u00f3n solo contiene lo necesario para correr \u2014 sin el compilador, sin herramientas de build, sin dependencias de desarrollo. M\u00e1s peque\u00f1a, m\u00e1s segura, m\u00e1s r\u00e1pida de desplegar.<\/p>\n\n\n\n
El checklist final para ir a producci\u00f3n con Compose<\/h2>\n\n\n\n