Docker
Persistencia, inicialización, health, backups y límites de producción.
Containerizar una base de datos estandariza el proceso y su configuración, pero no convierte el estado en reemplazable.
container reemplazable
+ image versionada
+ volume persistente
+ backups externos
+ topología de réplica/failover
→ servicio de datos operableEl error más común es aplicar el modelo stateless de una API a un motor stateful. Reiniciar o recrear un proceso es sencillo; conservar consistencia, disponibilidad y capacidad de recuperación exige procedimientos propios del motor.
Docker no aporta automáticamente:
services:
db:
image: postgres:17
environment:
POSTGRES_USER: app
POSTGRES_DB: app
POSTGRES_PASSWORD_FILE: /run/secrets/db_password
secrets:
- db_password
volumes:
- db-data:/var/lib/postgresql/data
networks: [data]
healthcheck:
test: ["CMD-SHELL", "pg_isready -U app -d app"]
interval: 5s
timeout: 3s
retries: 10
stop_grace_period: 60s
volumes:
db-data:
networks:
data:
internal: true
secrets:
db_password:
file: ./secrets/db_password.txtEl ejemplo sirve para desarrollo y un single host controlado. No demuestra HA ni backup.
La ruta del mount debe coincidir con la versión e imagen utilizadas.
volume correcto
→ directorio real del motor
→ datos sobreviven al containerMontar una ruta equivocada produce una falsa sensación de persistencia. Verifica:
docker inspect db --format '{{json .Mounts}}'
docker volume inspect project_db-dataImágenes oficiales suelen ejecutar scripts de inicialización únicamente cuando el directorio de datos está vacío.
volume vacío
→ entrypoint inicializa cluster
→ ejecuta scripts iniciales
volume existente
→ scripts no vuelven a ejecutarsePor eso no son un sistema de migrations recurrentes.
Úsalos para:
No los uses para:
Las migrations deben ser:
Patrón Compose:
services:
migrate:
image: registry.example.com/api@sha256:...
command: ["npm", "run", "migrate"]
depends_on:
db:
condition: service_healthy
restart: "no"No ejecutes migrations destructivas simultáneamente desde cada réplica de la API.
Para despliegues sin downtime:
1. expand: agregar nueva columna/tabla compatible
2. desplegar código que soporta viejo y nuevo modelo
3. migrar/backfill
4. cambiar lecturas/escrituras
5. contract: retirar estructura antiguaUna migration que renombra o elimina una columna antes de actualizar todas las instancias puede romper el rollout.
Un volume local sobrevive al container, pero normalmente no a la pérdida completa del host o disco.
host A / volume db-data
≠
host B / volume db-dataEl mismo nombre en otro host no contiene automáticamente los mismos datos.
Para varios nodos necesitas:
Persistencia no es backup.
Un backup protege frente a:
Ejemplo PostgreSQL:
docker exec db pg_dump -U app -Fc app > backup.dumpVentajas:
Costes:
Pueden ser más rápidos o permitir PITR, pero deben coordinarse con el motor. Copiar archivos activos arbitrariamente puede producir una copia inconsistente.
Un backup solo es válido después de restaurarlo.
Procedimiento:
Ejemplo:
docker volume create db-restore
# iniciar instancia aislada y ejecutar pg_restoreDefine:
Cambiar:
postgres:14 → postgres:17no es equivalente a actualizar una API. El formato del directorio puede ser incompatible.
Antes de una versión mayor:
Opciones pueden incluir:
No asumas que volver al tag anterior funciona después de modificar el formato.
Una database debe recibir la señal y disponer de tiempo para checkpoint y cierre.
docker stop --time 60 dbEvita docker kill salvo incidente controlado. El motor suele poder recuperarse mediante WAL/journal, pero eso no elimina riesgo ni tiempo de recovery.
pg_isready indica disponibilidad del servidor, no necesariamente:
Combina:
Una database utiliza:
Un límite arbitrario puede causar OOM o degradar consultas.
Observa:
No dimensionar solo con datos actuales. Incluye:
Disco lleno puede dejar el motor no disponible o comprometer durabilidad.
La database normalmente debe permanecer en una network interna.
API → db:5432
host/internet ✕ dbNo publiques el puerto por comodidad. Para administración usa:
La network no reemplaza password, TLS ni roles mínimos.
Evita usar superuser desde la aplicación.
Crea identidades separadas:
Cada una con permisos mínimos. Rotar el password puede requerir compatibilidad temporal y recreación de pools.
Dentro de una red privada, TLS puede seguir siendo necesario si:
Gestiona certificados, hostname verification y rotación. No desactives TLS para solucionar errores de confianza.
restart policy
→ recupera crash del procesoNo cubre:
HA requiere topología del motor y un mecanismo para elegir/descubrir el primary.
Antes de desplegar réplicas define:
Montar el mismo volume en dos instancias no crea un cluster y puede corromper datos.
Servicio administrado puede aportar:
Costes:
Operar en Docker es razonable para desarrollo, CI, edge o equipos con capacidad real de DBA/infra. Para producción crítica, compara el coste operativo completo.
Causas comunes:
docker compose down -v;Diagnóstico:
docker compose ls
docker volume ls
docker inspect db --format '{{json .Mounts}}'
docker volume inspect volume-nameNo ejecutes prune antes de identificar los volumes.
El volume ya está inicializado. Usa migration explícita.
Puede fallar por formato, extensión o encoding.
No protege frente a pérdida del host.
La aplicación necesita conocer consistencia eventual.
El límite incluye buffers y procesos del motor; ajusta queries y configuración.
Conserva backup y prueba rollback antes.
Upgrade no controlado.
Persistencia en ruta equivocada.
Copia inconsistente.
Carreras y locks.
Superficie innecesaria.
El host sigue siendo punto único de fallo.
CI/CD con Docker, donde el artefacto se construye una vez, se prueba por digest y se promociona sin reconstrucciones ocultas.