En el panorama actual del desenvolupament de programari, la contenidorització s'ha convertit en un pilar fonamental per garantir entorns consistents, desplegaments ràpids i escalabilitat horitzontal. En aquest article, segona part d'una sèrie dedicada a la construcció d'infraestructura a AWS, explorem com aplicar Docker i Docker Compose per preparar una aplicació de notes (note-taker) abans de migrar-la al núvol. Aquest enfocament no només facilita la transició a serveis cloud com AWS ECS o EKS, sinó que també estableix les bases per a una arquitectura robusta, mantenible i preparada per integrar capacitats d'intel·ligència artificial, ciberseguretat i automatització.
La decisió de contenidoritzar primer, abans de tocar la infraestructura cloud, respon a una necessitat pràctica: assegurar que l'aplicació funcioni de manera idèntica en local, en un entorn de proves i en producció. Molts equips cometen l'error de llançar-se directament a construir VPCs, subnets i balancejadors, només per descobrir que el codi no es comporta igual dins del contenidor que a la màquina del desenvolupador. Aquí, a Q2BSTUDIO, entenem que la contenidorització primerenca redueix dràsticament els problemes de 'funciona a la meva màquina' i accelera el cicle de lliurament.
El nostre projecte consisteix en una aplicació web amb un backend Node.js i un frontend React, més una base de dades PostgreSQL. Per a cada component, vam escriure Dockerfiles específics, optimitzats per a producció. Al backend, vam triar node:22-slim en lloc de versions Alpine perquè necessitàvem compilar dependències natives com sqlite3 (tot i que després vam migrar a PostgreSQL). La imatge slim ofereix les llibreries necessàries sense el pes addicional d'una imatge completa. Vam utilitzar npm ci --omit=dev per instal·lar només dependències de producció, reduint la mida final del contenidor i minimitzant la superfície d'atac —un aspecte clau de ciberseguretat en entorns cloud.
Per al frontend, vam optar per una construcció multi-etapa. Una primera etapa construeix l'aplicació React amb Node.js Alpine; la segona serveix els fitxers estàtics mitjançant Nginx. Per què Nginx? Perquè és molt més lleuger i ràpid que mantenir un servidor Node funcionant només per lliurar HTML i JS. A més, Nginx actua com a proxy invers per redirigir les peticions /api i /health al backend, resolent un problema comú en aplicacions React: el frontend no sap com arribar al backend si estan en contenidors separats. La nostra configuració de Nginx, amb directives proxy_pass i try_files, permet que React gestioni l'enrutament del client sense errors 404 en recarregar la pàgina.
Docker Compose orquestra els tres serveis: backend, frontend i base de dades. Vam incorporar health checks perquè el backend esperi que PostgreSQL estigui llest mitjançant pg_isready. Vam mapejar ports acuradament per evitar conflictes amb serveis locals com XAMPP o Docker Desktop. Tots els serveis comparteixen una xarxa personalitzada anomenada app-network, que permet la comunicació per nom de servei. Aquesta pràctica és idèntica a com es configuren les xarxes a AWS ECS o en un clúster de Kubernetes.
Durant el desenvolupament, vam afrontar un problema típic: el backend forçava SSL en mode producció, però la base de dades local no suportava connexions SSL. En tenir NODE_ENV=production a docker-compose, l'aplicació rebutjava la connexió. La solució va ser refinar la lògica d'SSL perquè acceptés una variable d'entorn explícita (PGSSL). Aquest tipus d'incidents subratlla la importància de no assumir comportaments de producció en entorns de prova. A Q2BSTUDIO, recomanem sempre parametritzar la configuració de seguretat i separar clarament els entorns mitjançant variables.
Un cop l'aplicació està completament contenidoritzada i funcionant localment, el següent pas és migrar la infraestructura a AWS utilitzant Terraform. La contenidorització prèvia ens permet desplegar en qualsevol servei de contenidors: ECS amb Fargate, EKS amb Kubernetes, o fins i tot en instàncies EC2 amb Docker. A més, facilita la integració amb serveis gestionats com RDS per a la base de dades, o ElastiCache per a memòria cau. La mateixa imatge Docker que vam provar localment es desplega a producció sense canvis, garantint consistència.
Per a empreses que busquen aplicacions a mida, aquest flux de treball és ideal. La contenidorització no només accelera el desenvolupament, sinó que també permet incorporar fàcilment intel·ligència artificial (com a agents d'IA que processin notes) o sistemes d'anàlisi amb Power BI que consultin la base de dades. La ciberseguretat es beneficia d'imatges més lleugeres i de la possibilitat d'escanejar vulnerabilitats a cada capa del contenidor. Així mateix, l'automatització de processos mitjançant pipelines CI/CD (GitHub Actions, GitLab CI) esdevé trivial quan el build ja està empaquetat a Docker.
A Q2BSTUDIO, apliquem aquesta metodologia en tots els nostres projectes cloud. Combinem contenidorització amb serveis cloud AWS/Azure per oferir solucions escalables, segures i mantenibles. La infraestructura com a codi amb Terraform i l'orquestració amb Kubernetes són el complement natural. Si la vostra organització està avaluant migrar al núvol o modernitzar les seves aplicacions, començar per la contenidorització és el primer pas intel·ligent.
En resum, contenidoritzar abans de cloudificar no és un rodeig, és un accés directe. Et evita mals de cap, redueix costos de depuració i accelera el time-to-market. En properes entregues explorarem la configuració d'IAM, VPC i el desplegament continu a AWS. Estigueu atents.
