Durant anys, Docker va ser aquella tecnologia que apareixia al meu currículum però que mai havia dominat realment. Sabia els termes —contenidors, imatges, docker-compose— però no entenia com encaixaven fins que vaig construir un sistema multiinquilí de creació de chatbots amb intel·ligència artificial. Aquell projecte em va obligar a afrontar el problema clàssic: 'a la meva màquina funciona'. I va ser llavors quan Docker va passar de ser un concepte abstracte a una eina indispensable al meu flux MERN.
La metàfora que finalment ho va aclarir tot va ser pensar en una imatge com una recepta de cuina: llista cada ingredient i pas necessari perquè la teva aplicació funcioni —versió de Node, dependències, codi font, ordre d'inici—. Un contenidor és el plat preparat a partir d'aquesta recepta. Pots cuinar el mateix plat cent vegades, en cent fogons diferents, i el resultat serà idèntic cada vegada. El Dockerfile no és més que la targeta de la recepta escrita en un llenguatge que Docker entén. Quan vaig deixar de veure els contenidors com a 'mini màquines virtuals' i vaig començar a veure'ls com a 'entorns garantits idèntics', tota la resta —capes, volums, xarxes— es va convertir en detalls que podia consultar sobre la marxa, no en conceptes per memoritzar per endavant.
El meu aprenentatge va ser gradual. Primer vaig dockeritzar una sola peça: l'API Express. Un Dockerfile mínim, un EXPOSE, un CMD. El vaig executar amb docker run i vaig veure com el mateix codi s'aixecava dues vegades en contenidors independents. Després vaig introduir docker-compose quan vaig necessitar MongoDB juntament amb l'API. En aquell moment Docker va deixar de ser acadèmic i es va fer útil: un sol docker-compose up reemplaçava una pàgina sencera d'instruccions de configuració. Després vaig trencar coses a propòsit: vaig matar contenidors a mig execució, vaig configurar malament els ports, vaig oblidar el .dockerignore i vaig veure com node_modules inflava la meva imatge. Depurar és on els conceptes realment es fixen.
En un stack MERN típic, Docker no és un únic contenidor, sinó diversos que es comuniquen entre si. Un docker-compose.yml bàsic inclou serveis per al frontend React, l'API Express i MongoDB. Cadascun té el seu propi entorn aïllat i es parlen a través de la xarxa interna de Docker utilitzant noms de servei en lloc de localhost. Per al meu projecte de chatbots, això va significar que el pipeline de RAG, la capa d'API i la base de dades podien versionar-se i desplegar-se junts, i la mateixa configuració que funcionava a la meva màquina funcionava idèntica en producció. El veritable benefici no va ser aprendre ordres de Docker, sinó el que va eliminar: ja no més documents d'incorporació que diguessin 'instal·la Node 18.x, després Mongo, després configura aquestes set variables d'entorn'. Només docker-compose up.
Per a una empresa com Q2BSTUDIO, que desenvolupa aplicacions a mida, la consistència entre entorns no és un luxe, és la diferència entre una demo i un producte desplegable. Quan treballem en projectes que integren intel·ligència artificial, ciberseguretat i cloud AWS/Azure, la capacitat d'empaquetar tot el stack amb Docker garanteix que l'equip de desenvolupament, el de QA i el client final vegin exactament el mateix comportament. A més, en entorns on despleguem agents d'IA o sistemes de BI/Power BI, Docker permet escalar serveis de forma independent i mantenir la seguretat en aïllar components crítics.
La meva recomanació per a qualsevol desenvolupador MERN que comenci avui és: no comencis amb docker-compose ni molt menys amb Kubernetes. Comença per dockeritzar una sola ruta d'Express. Executa-la dues vegades i observa com funciona idèntica. Després afegeix Mongo. Després el teu frontend. El stack es construeix sol un cop el primer contenidor fa clic —i farà clic més ràpid del que semblen indicar els manuals.
Si vols aprofundir en com aplicar aquestes tècniques a la teva infraestructura, t'invitem a conèixer els nostres serveis cloud a AWS i Azure, on integrem contenidors de manera segura i escalable.
