En el panorama actual del desarrollo de software, la contenerización se ha convertido en un pilar fundamental para garantizar entornos consistentes, despliegues rápidos y escalabilidad horizontal. En este artículo, segunda parte de una serie dedicada a la construcción de infraestructura en AWS, exploramos cómo aplicar Docker y Docker Compose para preparar una aplicación de notas (note-taker) antes de migrarla a la nube. Este enfoque no solo facilita la transición a servicios cloud como AWS ECS o EKS, sino que también sienta las bases para una arquitectura robusta, mantenible y lista para integrar capacidades de inteligencia artificial, ciberseguridad y automatización.
La decisión de contenerizar primero, antes de tocar la infraestructura cloud, responde a una necesidad práctica: asegurar que la aplicación funcione de manera idéntica en local, en un entorno de pruebas y en producción. Muchos equipos cometen el error de lanzarse directamente a construir VPCs, subnets y balanceadores, solo para descubrir que el código no se comporta igual dentro del contenedor que en la máquina del desarrollador. Aquí, en Q2BSTUDIO, entendemos que la contenerización temprana reduce drásticamente los problemas de “funciona en mi máquina” y acelera el ciclo de entrega.
Nuestro proyecto consiste en una aplicación web con un backend Node.js y un frontend React, más una base de datos PostgreSQL. Para cada componente, escribimos Dockerfiles específicos, optimizados para producción. En el backend, elegimos node:22-slim en lugar de versiones Alpine porque necesitábamos compilar dependencias nativas como sqlite3 (aunque luego migramos a PostgreSQL). La imagen slim ofrece las librerías necesarias sin el peso adicional de una imagen completa. Usamos npm ci --omit=dev para instalar solo dependencias de producción, reduciendo el tamaño final del contenedor y minimizando la superficie de ataque —un aspecto clave de ciberseguridad en entornos cloud.
Para el frontend, optamos por una construcción multi-etapa. Una primera etapa construye la aplicación React con Node.js Alpine; la segunda sirve los archivos estáticos mediante Nginx. ¿Por qué Nginx? Porque es mucho más ligero y rápido que mantener un servidor Node funcionando solo para entregar HTML y JS. Además, Nginx actúa como proxy inverso para redirigir las peticiones /api y /health al backend, resolviendo un problema común en aplicaciones React: el frontend no sabe cómo llegar al backend si están en contenedores separados. Nuestra configuración de Nginx, con directivas proxy_pass y try_files, permite que React maneje el enrutamiento del lado del cliente sin errores 404 al recargar la página.
Docker Compose orquesta los tres servicios: backend, frontend y base de datos. Incorporamos health checks para que el backend espere a que PostgreSQL esté listo mediante pg_isready. Mapeamos puertos cuidadosamente para evitar conflictos con servicios locales como XAMPP o Docker Desktop. Todos los servicios comparten una red personalizada llamada app-network, lo que permite la comunicación por nombre de servicio. Esta práctica es idéntica a cómo se configuran las redes en AWS ECS o en un clúster de Kubernetes.
Durante el desarrollo, nos enfrentamos a un problema típico: el backend forzaba SSL en modo producción, pero la base de datos en local no soportaba conexiones SSL. Al tener NODE_ENV=production en docker-compose, la aplicación rechazaba la conexión. La solución fue refinar la lógica de SSL para que aceptara una variable de entorno explícita (PGSSL). Este tipo de incidentes subraya la importancia de no asumir comportamientos de producción en entornos de prueba. En Q2BSTUDIO, recomendamos siempre parametrizar la configuración de seguridad y separar claramente los entornos mediante variables.
Una vez que la aplicación está completamente contenerizada y funcionando localmente, el siguiente paso es migrar la infraestructura a AWS usando Terraform. La contenerización previa nos permite desplegar en cualquier servicio de contenedores: ECS con Fargate, EKS con Kubernetes, o incluso en instancias EC2 con Docker. Además, facilita la integración con servicios gestionados como RDS para la base de datos, o ElastiCache para caché. La misma imagen Docker que probamos localmente se despliega en producción sin cambios, garantizando consistencia.
Para empresas que buscan aplicaciones a medida, este flujo de trabajo es ideal. La contenerización no solo acelera el desarrollo, sino que también permite incorporar fácilmente inteligencia artificial (como agentes IA que procesen notas) o sistemas de análisis con Power BI que consulten la base de datos. La ciberseguridad se beneficia de imágenes más ligeras y de la posibilidad de escanear vulnerabilidades en cada capa del contenedor. Asimismo, la automatización de procesos mediante pipelines CI/CD (GitHub Actions, GitLab CI) se vuelve trivial cuando el build ya está empaquetado en Docker.
En Q2BSTUDIO, aplicamos esta metodología en todos nuestros proyectos cloud. Combinamos contenerización con servicios cloud AWS/Azure para ofrecer soluciones escalables, seguras y mantenibles. La infraestructura como código con Terraform y la orquestación con Kubernetes son el complemento natural. Si tu organización está evaluando migrar a la nube o modernizar sus aplicaciones, comenzar por la contenerización es el primer paso inteligente.
En resumen, contenerizar antes de cloudificar no es un rodeo, es un atajo. Te evita dolores de cabeza, reduce costes de debugging y acelera el time-to-market. En las próximas entregas exploraremos la configuración de IAM, VPC y el despliegue continuo en AWS. Permanece atento.
