Contenedores y DevOps en la empresa: por dónde empezar

En muchas empresas, la aplicación funciona en un servidor que alguien configuró a mano hace años. Desplegar una versión significa copiar archivos o ejecutar comandos por SSH, los ordenadores de los desarrolladores no se parecen al servidor y nadie quiere tocar la versión del entorno de ejecución. Los contenedores y las prácticas DevOps cambian esto: la aplicación se construye, se prueba y se despliega siempre de la misma forma. Este artículo describe el orden que funciona, los errores que más cuestan y cuándo merece la pena Kubernetes.

Qué cambian los contenedores

Una imagen de contenedor empaqueta la aplicación con todo lo que necesita para funcionar: el entorno de ejecución, las bibliotecas y los archivos de configuración (documentación de Docker, en inglés). La misma imagen funciona en el portátil de un desarrollador, en pruebas y en producción, así que «en mi ordenador funciona» deja de ser un argumento.

• Las actualizaciones se vuelven rutina. Una nueva versión del entorno de ejecución es un cambio en una línea del Dockerfile, una nueva compilación y una ronda de pruebas. El artículo sobre el fin del soporte de PHP 8.2 muestra este camino para aplicaciones PHP.
• Sin dependencia de un proveedor. Las imágenes siguen los estándares abiertos de la Open Container Initiative, de modo que funcionan en cualquier plataforma que los admita, en sus propios servidores o en la nube (OCI, en inglés).

Qué significa DevOps en la práctica

DevOps no es una herramienta ni un puesto de trabajo, sino una forma de trabajar: todo bajo control de versiones, cada cambio compilado y probado automáticamente, versiones pequeñas, frecuentes y repetibles, la infraestructura descrita como código y un equipo que ve lo que ocurre en producción.

El orden que funciona

1. Hacer inventario. Qué aplicaciones funcionan dónde, con qué versiones, quién las despliega y cómo. Aquí aparece la mayor parte del riesgo: versiones sin soporte y pasos manuales que solo conoce una persona.
2. Contenerizar primero una aplicación. Un Dockerfile basado en una imagen base de confianza y mínima, con la versión fijada, una compilación en varias etapas (multi-stage) que deja las herramientas de compilación fuera de la imagen final, y un usuario sin privilegios de root (buenas prácticas de Docker, en inglés). La configuración queda fuera de la imagen, en el entorno (The Twelve-Factor App).
3. Un entorno de desarrollo con un solo comando. Docker Compose describe la aplicación con su base de datos, su caché y los demás servicios en un único archivo y arranca todo el conjunto con un solo comando (documentación de Docker, en inglés). Una persona nueva en el equipo clona el repositorio y tiene un entorno que funciona.
4. Un pipeline para cada cambio. Con cada commit, el sistema de integración continua compila la imagen, ejecuta las pruebas, la analiza en busca de vulnerabilidades conocidas y la sube a un registro (documentación de Docker: GitHub Actions, en inglés). Los registros y las propias herramientas de Docker incluyen estos analizadores, por ejemplo el análisis de imágenes de Amazon ECR o Docker Scout (en inglés).
5. La misma imagen en todos los entornos. Pruebas y producción ejecutan la misma imagen con distinta configuración; desarrollo, preproducción (staging) y producción se mantienen lo más parecidos posible (The Twelve-Factor App). El despliegue es un paso del pipeline, no una tarea manual.
6. Infraestructura como código y monitorización. Los servidores, las redes, las bases de datos y el DNS se describen en código, por ejemplo con Terraform, y se cambian con la misma revisión que la aplicación. Las aplicaciones escriben sus registros en la salida estándar, donde la plataforma los recoge (The Twelve-Factor App); las métricas y las alertas muestran los problemas antes que los usuarios.

Dónde ejecutar los contenedores

No todas las empresas necesitan Kubernetes.

• Pocas aplicaciones, un equipo pequeño: un servidor con Docker Compose o un servicio de contenedores gestionado en el que el proveedor se ocupa de los servidores, por ejemplo Amazon ECS con AWS Fargate.
• Muchos servicios, varios equipos, requisitos especiales de escalado, red o seguridad: Kubernetes, preferiblemente como clúster gestionado, por ejemplo Amazon EKS. Kubernetes es una plataforma para ejecutar cargas de trabajo en contenedores, no una plataforma completa y lista para usar (documentación de Kubernetes): las actualizaciones, los complementos, el control de acceso y la monitorización siguen siendo trabajo de su equipo o de un colaborador externo.

Los errores que más cuestan

• Secretos dentro de la imagen. Los argumentos de compilación y las variables de entorno definidos en el Dockerfile permanecen en la imagen final y en cada copia de ella; los secretos van en montajes de secretos durante la compilación y en un almacén de secretos durante la ejecución (documentación de Docker, en inglés).
• Versiones que cambian solas. Etiquetas como latest pueden apuntar mañana a otra imagen. Fije las versiones y, para las imágenes base, valore usar el digest, que siempre se refiere a la misma imagen (buenas prácticas de Docker, en inglés). Lo mismo vale para los componentes del pipeline: en marzo de 2026, unos atacantes movieron casi todas las etiquetas de versión de la GitHub Action de Trivy, un analizador de vulnerabilidades muy utilizado, a un código que roba credenciales (aviso de Aqua Security, en inglés). GitHub recomienda fijar las dependencias de los workflows con un archivo de bloqueo (lockfile) o con el SHA completo del commit (documentación de GitHub).
• Imágenes que se compilan una vez y nunca más. Una imagen no se actualiza sola. Vuelva a compilarla con regularidad para que lleguen las correcciones de seguridad de la imagen base (misma página).
• Datos dentro del contenedor. Los archivos escritos dentro de un contenedor se pierden cuando el contenedor se destruye, por ejemplo cuando una nueva versión lo sustituye; las bases de datos y los archivos subidos van en volúmenes o en servicios gestionados (documentación de Docker, en inglés).
• Contenedores tratados como servidores. Entrar y cambiar cosas a mano anula la ventaja: el cambio desaparece con el siguiente despliegue y nadie sabe que existió. Los cambios pasan por la imagen y por el pipeline.
• Kubernetes demasiado pronto. Un clúster para dos aplicaciones da más trabajo del que ahorra.

Un ejemplo

En Talk-A-Bot, la plataforma y al menos 86 proyectos de clientes funcionaban en tres nubes, cada una con su propia configuración y con pasos de despliegue manuales. Con tantos servicios, Kubernetes era la plataforma adecuada: todo se consolidó en una única plataforma en AWS sobre Amazon EKS, con la infraestructura en Terraform, charts de Helm estandarizados y despliegues GitOps. Los costes de infraestructura bajaron un 77 %. Los detalles están en el caso práctico de Talk-A-Bot.

Cómo puedo ayudarle

Introduzco contenedores y prácticas DevOps en empresas: una evaluación de qué funciona dónde, la contenerización, un entorno de desarrollo reproducible, pipelines de CI/CD, infraestructura como código y formación, para que su equipo pueda gestionarlo por su cuenta. Si lo desea, también alojo y opero las aplicaciones en contenedores. Los cambios en el código de la aplicación siguen en manos de sus desarrolladores.