Docker: cuándo usarlo y cuándo te complica la vida
Publicado el 2026-09-12 por frfrand
Qué problema resuelve de verdad, los cuatro casos donde suma sin discusión, los tres donde es peso muerto, y los errores que convierten una buena idea en un dolor de cabeza.
Docker se explica muchas veces por lo que no es. Se dice que aísla, y aísla poco comparado con una máquina virtual. Se dice que es liviano, y eso es cierto pero secundario.
Lo que Docker resuelve de verdad es la reproducibilidad.
La idea central
Escribís un archivo que describe el entorno: de qué imagen base partís, qué dependencias instalás, qué versiones exactas, cómo se arranca la aplicación.
De ahí sale una imagen: un sistema de archivos congelado. Esa imagen es idéntica en tu laptop, en el servidor de integración y en producción.
Eso mata de raíz el problema más viejo del oficio: "en mi máquina funciona". No funciona en tu máquina: funciona en esa imagen, que es la misma en todos lados.
Los cuatro casos donde suma sin discusión
Varios servicios con versiones distintas. Un proyecto necesita Node 18 y otro Node 22. Un proyecto quiere Postgres 14 y otro Postgres 17. Sin contenedores eso es un dolor de cabeza permanente; con contenedores, no es nada.
Software difícil de instalar. Algunas herramientas tienen procesos de instalación largos y frágiles. Una imagen oficial resuelve en un comando lo que de otro modo lleva una tarde.
Un equipo que necesita el mismo entorno. Que la persona nueva esté productiva en veinte minutos en vez de dos días es una diferencia real.
Integración continua. Cada ejecución parte de un entorno limpio y reproducible, sin que se acumule estado entre corridas.
Los tres casos donde es peso muerto
Vale ser honesto acá, porque es lo que casi nunca se dice.
Una aplicación simple en un servidor chico. Si tenés una app de Node en un VPS, meterla en un contenedor agrega piezas: el demonio, las imágenes, los volúmenes, la red interna. Y suma consumo de memoria en una máquina donde la memoria importa.
Sitios estáticos. Un sitio compilado son archivos. nginx los sirve directamente, más rápido y sin nada en el medio.
Cuando nadie en el equipo sabe Docker. Una capa que sólo una persona entiende es una capa frágil. El día que esa persona no está, el despliegue se vuelve un misterio.
Y un cuarto, más sutil: si lo que querías era aislamiento, un contenedor no es lo que buscás. Comparte el kernel. Para aislar de verdad hace falta una máquina virtual.
Los cuatro errores que duelen
Usar la etiqueta latest. Si tu imagen base es "node:latest", la próxima construcción puede traer otra versión mayor y romper todo. Y adiós reproducibilidad, que era el punto entero. Fijá versiones.
Guardar datos adentro del contenedor. El contenedor es descartable. Si tu base de datos escribe adentro, al recrearlo se pierde. Para eso están los volúmenes.
Meter secretos en la imagen. Todo lo que entra en una capa queda en la imagen, aunque después lo borres en otra capa. Cualquiera que descargue esa imagen puede recuperarlo. Los secretos van como variables en tiempo de ejecución.
Correr como root adentro. Es el comportamiento por defecto y no es obligatorio. Una instrucción USER en el Dockerfile reduce bastante el daño posible de una vulnerabilidad.
La regla corta
Docker es una herramienta de empaquetado, no un muro de seguridad.
Si el problema que tenés es "necesito que esto corra igual en todos lados", es excelente. Si el problema es "necesito que esto no pueda tocar aquello", necesitás otra cosa.
En ArduMaker Docker se instala en tu VPS con un clic y se administran contenedores, logs, imágenes, volúmenes y redes desde el panel. El aislamiento fuerte ya lo da el VPS; los contenedores adentro resuelven el empaquetado.
