Docker es útil cuando elimina una variación concreta: versiones del runtime, librerías nativas, dependencias de workers o diferencias entre entornos. Se convierte en carga cuando un equipo pequeño hereda redes, imágenes y almacenamiento persistente sin un beneficio claro.
Cuándo suele ayudar Docker
- varios servicios necesitan runtimes o dependencias distintas
- la misma imagen probada debe pasar por staging y producción
- los workers necesitan entornos previsibles y reemplazables
- desarrollo necesita integraciones locales reproducibles
- los despliegues requieren rollback a artefactos inmutables
Construye una vez, etiqueta con una versión inmutable y promociona la misma imagen. Configuración y secretos deben quedar fuera. Ejecuta como usuario sin privilegios, usa imágenes base mínimas y mantenidas, y analiza dependencias en CI.
Cuándo puede complicar el sistema
Una aplicación convencional en un único servidor puede ser más clara con paquetes del sistema, un gestor de procesos y un despliegue documentado. Docker solo aporta valor si el equipo puede operar registro, redes, volúmenes, logs, health checks y actualizaciones.
No introduzcas Kubernetes solo porque existen contenedores. Un despliegue pequeño con Compose puede ser correcto si se entienden su modelo de fallos, backups y recuperación manual.
Persistencia y red necesitan diseño explícito
Los contenedores son desechables; los datos de clientes no. Mantén bases de datos y ficheros en servicios gestionados o volúmenes con backup explícito. Prueba la restauración fuera del host de producción. Limita redes, publica solo los puertos necesarios y termina TLS en un proxy controlado.
Si buscas alternativas fuera de contenedores, la comparación de PM2, Supervisor y systemd cubre modelos más sencillos.
Errores comunes
- usar etiquetas
latestmutables en producción - incluir secretos dentro de imágenes o ficheros Compose
- ejecutar todos los procesos como root
- guardar la base de datos en un volumen sin restauración probada
- confundir health check con disponibilidad real
- dejar logs solo en el disco local del contenedor
- construir imágenes distintas para cada entorno
- añadir orquestación sin responsable operativo
Checklist práctico de producción
- fijar versiones de imágenes base y dependencias
- generar etiquetas inmutables y trazables
- analizar imágenes y parchearlas periódicamente
- usar mínimo privilegio y filesystem de solo lectura si es viable
- inyectar secretos desde un almacén apropiado
- definir límites de CPU, memoria y reinicio
- configurar readiness, liveness y cierre ordenado
- centralizar logs, métricas y marcas de despliegue
- hacer backups y probar restauraciones
- documentar rollback y recuperación del host
Trazabilidad y estabilidad
Registra revisión Git, digest de imagen, versión de configuración y hora de despliegue. Monitoriza reinicios, presión de memoria, fallos de salud y resultados de negocio, no solo uptime. Aplica la base de logs, alertas y monitorización y prueba el cierre ordenado para no abandonar trabajos.
Cuándo tiene sentido contratar a una persona técnica
Contrata a un perfil DevOps o de plataforma cuando haya varios hosts, una caída sea costosa, existan datos regulados o nadie pueda restaurar volúmenes y revertir imágenes con confianza. Debe simplificar la operación, automatizar controles repetibles y dejar un runbook ejecutable.
Conclusión
Elige Docker por repetibilidad y aislamiento, no por moda. Si el coste operativo supera la variación que elimina, conviene un despliegue más simple. Para revisar una arquitectura de producción, consulta mis servicios técnicos o contacta conmigo indicando topología y requisitos de recuperación.