Contenedores como empaquetado estándar. Por qué «funciona en mi máquina» ya no es un argumento.
Categoría · DevOps e Infra
Qué es Docker.
Docker empaqueta una aplicación junto con todas sus dependencias (runtime, bibliotecas, configuración) en una imagen autocontenida. Esa imagen se ejecuta de forma idéntica en cualquier host, ya sea un portátil, un runner de CI o un servidor de producción.
A diferencia de una máquina virtual, un contenedor no trae su propio sistema operativo, sino que comparte el kernel del host. Eso lo hace ligero: segundos en lugar de minutos para arrancar, megabytes en lugar de gigabytes.
Por qué containerizamos de forma sistemática.
Cada producto que construimos y operamos corre en un contenedor. Así, el entorno pasa a ser parte del código: la frase "funciona en mi máquina" deja de ser un argumento, porque el entorno es el mismo en todas partes.
Eso reduce el esfuerzo de onboarding de nuevos desarrolladores a un "docker compose up" y hace que los despliegues sean reproducibles. Justo eso necesitamos para cadenas de operación trazables y auditables.
Dónde está el límite.
Docker resuelve el empaquetado, no la orquestación. En cuanto varios contenedores tienen que escalar a través de máquinas, funcionar a prueba de fallos y reemplazarse automáticamente, hace falta una capa por encima: normalmente Kubernetes.
Para un único servidor con unos pocos servicios, basta con Docker Compose. Son la carga y la exigencia de disponibilidad las que deciden si hace falta más.
