Docker es fácil de empezar y fácil de hacer mal. En local todo funciona; en producción aparecen los problemas: imágenes que pesan un montón, contenedores que se reinician solos, secretos filtrados o datos que desaparecen. Esta es la parte que no suele explicarse.
Imágenes pequeñas y reproducibles
Una imagen de 2 GB tarda más en construirse, en subirse y en arrancar. Algunas normas:
- Usa imágenes base ligeras (
alpine,slim,distroless) cuando puedas. - Aprovecha el multi-stage build: compila en una etapa y copia solo lo necesario a la imagen final.
- Fija versiones concretas (
node:22.11-alpine, nonode:latest). - Copia primero el fichero de dependencias y luego el código, para aprovechar la caché de capas.
FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER node
CMD ["node", "dist/server.js"]Un ejemplo sencillo, pero que ya marca diferencia frente a copiar todo y ejecutar como root.
Seguridad: lo que casi nadie hace
- No ejecutes como root. Crea un usuario y úsalo (
USER node). - No dejes secretos en la imagen. Ni claves ni tokens ni ficheros
.env. - Pasa los secretos en tiempo de ejecución, no de construcción.
- Escanea las imágenes en busca de vulnerabilidades de forma periódica.
- Mantén las imágenes base actualizadas; las vulnerabilidades envejecen mal.
Datos: el error clásico
Los contenedores son efímeros: si guardas datos dentro del contenedor, los pierdes al recrearlo. Todo lo que deba persistir (bases de datos, ficheros subidos) debe ir a volúmenes o almacenamiento externo gestionado.
Si usas Docker Compose con una base de datos para desarrollo, que sea solo para desarrollo. En producción, usa un servicio gestionado (RDS, Azure SQL, etc.) salvo que tengas una razón muy buena para no hacerlo.
Logs y monitorización
Un contenedor que no logs no se puede depurar. Reglas simples:
- Escribe logs a stdout/stderr, no a ficheros dentro del contenedor.
- Usa un formato estructurado (JSON) para poder buscarlos.
- Centraliza los logs (CloudWatch, Loki, etc.).
- Añade healthchecks para que el orquestador sepa si el contenedor está sano.
Configuración y doce factores
Aplica los principios de 12-factor: configuración por variables de entorno, procesos sin estado, paridad entre entornos. Un contenedor que se comporta distinto en local y en producción es una fábrica de sorpresas.
Despliegue sin downtime
Con contenedores, el objetivo es desplegar sin cortar el servicio:
- Levanta la nueva versión, espera a que esté lista y solo entonces retira la antigua.
- Usa rolling deployments o blue/green.
- Asegúrate de que las migraciones de base de datos son compatibles hacia atrás.
Esto se apoya en un buen pipeline de CI/CD. Si aún no tienes uno, empieza por ahí (te lo explicamos en esta guía de GitHub Actions).
Cuándo Docker no basta
Docker resuelve el empaquetado, no la orquestación. Si tienes muchas aplicaciones, necesitas algo que coordine contenedores, redes y escalado. Ahí entran las plataformas gestionadas o Kubernetes, aunque en PYMEs conviene empezar por lo simple (lo tratamos en Kubernetes para PYMEs).
Resumen
Docker en producción es un 20% de “docker run” y un 80% de detalles: imágenes ligeras, sin root, secretos fuera de la imagen, datos persistentes, logs centralizados y despliegues sin downtime. Ese 80% es exactamente lo que separa un prototipo de un sistema en el que puedes confiar.
Si quieres una base así desde el primer día, el CloudStart Pack incluye containerización y pipeline completo. Y si ya tienes contenedores pero no te fías de ellos, una auditoría cloud es el punto de partida.