Docker resuelve un problema concreto: una aplicación puede comportarse de forma distinta cuando cambia el equipo, el sistema o las dependencias con las que se ejecuta. Al empaquetar el código y parte de su entorno en una imagen, permite distribuir y ejecutar el mismo artefacto en distintos sistemas que admiten contenedores.
Esto reduce el conocido «en mi máquina funciona», facilita las pruebas y evita instalar versiones incompatibles de bibliotecas en el sistema anfitrión. No hace que las aplicaciones sean automáticamente portables, seguras ni reproducibles: esas propiedades dependen también de la configuración, los datos, la arquitectura y el mantenimiento.
👉 Y recuerda, si quieres aprender más de Linux, visita el curso de Linux gratis.
🐳 Si quieres aprender más de Docker, visita el curso de Docker gratis.
Por qué falla una aplicación al cambiar de entorno
El código no es lo único que necesita una aplicación. También puede depender de una versión concreta del lenguaje, bibliotecas del sistema, certificados, herramientas de compilación y servicios como una base de datos o una cola de mensajes. Si cada equipo instala esas piezas a mano, las diferencias se acumulan.
Imagina una API que se desarrolla con Python 3.12 y PostgreSQL 16. En el portátil funciona porque ya están instaladas sus dependencias. En integración continua se usa otra versión de Python; en producción falta una biblioteca nativa, y el servicio de base de datos tiene una configuración distinta. El código puede ser idéntico y, aun así, el resultado cambia.
| Problema | Consecuencia | Qué aporta Docker | Qué debe seguir definiendo el equipo |
|---|---|---|---|
| Versiones de runtime o bibliotecas distintas | Errores que solo aparecen en algunos entornos | Permite declarar una base y dependencias para la imagen | Elegir versiones mantenidas y actualizar las vulnerables |
| Instalación manual del entorno | Configuraciones difíciles de repetir y documentar | El entorno de la aplicación se describe junto con el proyecto | Configurar variables, permisos y servicios externos |
| Varios proyectos necesitan versiones incompatibles | Conflictos en el sistema anfitrión | Cada imagen contiene sus propias dependencias de espacio de usuario | Asignar recursos y revisar los límites del aislamiento |
| Pruebas y producción construyen artefactos distintos | El resultado probado no coincide con el desplegado | Una imagen construida puede publicarse y promoverse entre entornos | Controlar la configuración y desplegar la referencia correcta |
Qué estandariza una imagen Docker
El Dockerfile documenta cómo se construye una imagen: qué sistema de archivos base se usa, qué dependencias se instalan, qué archivos se incorporan y qué proceso se inicia por defecto. La imagen resultante reúne esas capas y metadatos en un artefacto identificable que puede almacenarse en un registro.
Cuando se crea un contenedor, Docker añade una capa escribible para los cambios que ocurren durante esa ejecución. Esa capa pertenece al contenedor y no convierte sus datos en persistentes. Los datos que deban sobrevivir a su eliminación necesitan volúmenes o montajes adecuados.
La diferencia clave es que el equipo puede construir una imagen una vez, probarla y desplegar ese mismo artefacto en otros entornos. Para identificarlo con precisión se puede utilizar su digest. Una etiqueta como “latest” es solo un nombre de referencia y puede apuntar a una imagen distinta tras una actualización; no fija por sí sola una versión inmutable.
Cómo ayuda cuando una aplicación usa varios servicios
Una aplicación web puede necesitar una API, PostgreSQL y Redis. Sin una definición compartida, cada persona debe instalar y configurar esos servicios por separado. Docker Compose permite declarar los servicios, sus redes y sus volúmenes en un archivo del proyecto, para que el equipo parta de una descripción común.
En una red de Compose, los servicios pueden localizarse por el nombre del servicio. Por ejemplo, la API se conecta al servicio de base de datos a través de su nombre dentro de esa red; no necesita depender de una dirección IP fija del contenedor. El puerto de PostgreSQL puede quedarse en la red interna si no hace falta acceder a él desde el anfitrión.
Compose organiza los componentes, pero no garantiza que una aplicación esté lista en cuanto arranca su contenedor. El equipo debe definir comprobaciones de salud y la lógica de reintento que necesite. Tampoco conviene guardar datos importantes en la capa escribible del contenedor: hay que configurar almacenamiento persistente y copias de seguridad.
Del build a producción: el mismo artefacto
Un flujo de entrega más coherente construye la imagen durante integración continua, ejecuta las pruebas con ella, la publica en un registro y despliega esa misma imagen en los entornos siguientes. Así se evita reconstruirla por separado en pruebas y producción, donde podrían cambiar las dependencias obtenidas o el contexto de construcción.
- El proceso de integración construye una imagen a partir de una revisión del proyecto.
- Las pruebas comprueban el artefacto que se pretende publicar.
- La imagen se identifica y se almacena en un registro.
- Los entornos despliegan esa imagen con su propia configuración y secretos.
Usar la misma imagen reduce diferencias del artefacto, pero no iguala automáticamente los entornos. Las variables, los permisos, la red, los servicios externos y la arquitectura de CPU pueden cambiar el comportamiento. Además, una reversión de la aplicación no revierte por sí sola una migración incompatible de la base de datos.
Qué problemas no resuelve Docker por sí solo
- Errores del programa: empaquetar una aplicación no corrige fallos de lógica ni pruebas insuficientes.
- Gestión de datos: la capa escribible de un contenedor no sustituye a un volumen, una política de retención o una copia de seguridad.
- Secretos y configuración: contraseñas y claves deben suministrarse con mecanismos apropiados, no incrustarse en la imagen.
- Seguridad completa: los contenedores comparten el kernel del anfitrión. El aislamiento depende también de privilegios, capacidades, configuración y actualizaciones.
- Portabilidad absoluta: una imagen para una arquitectura o un kernel puede no funcionar igual en otra plataforma.
- Operación en producción: monitorización, escalado, alta disponibilidad y recuperación requieren decisiones y herramientas adicionales.
Cuándo aporta valor
Docker resulta especialmente útil cuando varios equipos necesitan ejecutar la misma aplicación, cuando proyectos distintos requieren dependencias incompatibles, cuando un entorno tiene varios servicios o cuando se quiere probar y desplegar el mismo artefacto. También ayuda a documentar cómo se construye el entorno, siempre que los archivos de construcción se mantengan junto al código.
Puede añadir trabajo innecesario para una herramienta sencilla que ya se instala y ejecuta de forma fiable en el sistema. La decisión depende de si la repetibilidad, el aislamiento de dependencias y la distribución justifican mantener imágenes y configurar su ejecución.
Lecciones relacionadas del curso
- Flujo básico: Dockerfile, imagen y contenedor: cómo se relacionan las piezas que intervienen en la ejecución.
- Cómo funcionan las capas de una imagen Docker: cómo se compone y reutiliza el sistema de archivos de una imagen.
- Docker Compose: cómo se describen aplicaciones formadas por varios servicios.
- Qué ocurre con los datos de un contenedor: por qué separar los datos persistentes del ciclo de vida del contenedor.
