Docker — contenidors aïllats per a llocs web estables
Tota la plataforma 4buildsite — l'editor, l'API, el motor de renderització i el servei que serveix els webs publicats — s'executa en contenidors Docker: paquets aïllats que contenen tot el que necessita cada servei. El teu web es renderitza de manera estàtica i es serveix com una versió completa, canviada de manera atòmica a cada publicació. En paraules planes: si alguna cosa va malament, tornes a la versió anterior en segons.
Què és un contenidor — i per què importa per al teu web
Un contenidor és un paquet estandarditzat que conté l'aplicació i absolutament tot el que necessita per executar-se: entorn d'execució, biblioteques, configuració. El contenidor s'executa aïllat de la resta del servidor, però utilitza directament el nucli Linux del host — sense un sistema operatiu separat per aplicació. Docker, llançat el 2013, va convertir aquesta tecnologia en un estàndard accessible; el format d'imatge està ara estandarditzat com a OCI (Open Container Initiative) i s'executa de manera idèntica en qualsevol servidor Linux o núvol.
L'analogia clàssica és el contenidor de transport marítim: sigui quina sigui la càrrega, té la mateixa forma estàndard i es pot passar a qualsevol vaixell, tren o camió. Igualment, els serveis de 4buildsite que construeixen i serveixen el teu web — l'editor, l'API FastAPI, el motor de renderització — s'empaqueten en imatges estàndard que s'executen igual al servidor de proves i a producció. Per a tu, com a propietari d'un web o d'una botiga, això significa previsibilitat: el que has vist a la previsualització és exactament el que obtenen els teus visitants.
- Contenidor = l'aplicació + les seves dependències, en un paquet aïllat
- Format OCI estàndard — la mateixa imatge s'executa en qualsevol servidor o núvol
- Sense sistema operatiu separat per servei — s'inicia en segons, no en minuts
- A 4buildsite, la contenidorització la gestiona la plataforma — tu només publiques
Aïllament: el teu web no depèn dels veïns
En un allotjament compartit clàssic, centenars de webs comparteixen el mateix servidor, els mateixos processos i sovint la mateixa instal·lació de PHP. Si un veí té un pic de trànsit o un script mal escrit consumeix tota la CPU, el teu web s'alenteix — el problema del «veí sorollós». 4buildsite l'ataca des de dues direccions. Primera: els webs publicats es renderitzen de manera estàtica — als servidors que els serveixen no s'executa cap codi per web (PHP, connectors, scripts), de manera que no hi ha cap script mal escrit d'un veí que consumeixi la CPU. Segona: els serveis de la plataforma s'executen cadascun en el seu propi contenidor, amb processos i fitxers separats (mitjançant namespaces) i l'opció de límits de CPU i memòria (mitjançant cgroups, els mecanismes del nucli Linux).
L'aïllament importa igual d'important per a la seguretat. En un allotjament compartit, un web compromès pot esdevenir una porta d'entrada als webs veïns del mateix servidor. A 4buildsite, un web publicat és un conjunt de fitxers estàtics — no hi ha codi per web que es pugui comprometre mitjançant connectors o temes — i els serveis de la plataforma que processen dades (comandes, pagaments, l'editor) viuen en contenidors separats: el sistema de fitxers està aïllat i un incident queda contingut dins d'aquell contenidor.
- Web publicat = fitxers estàtics — cap codi per web que pugui ser compromès
- Serveis de la plataforma: sistema de fitxers i processos separats per contenidor
- Rendiment previsible: servei estàtic
La mateixa versió a tot arreu: zero «a la meva màquina funciona»
La font més habitual de defectes al web clàssic és la distància entre l'entorn on es va provar un web i el servidor on s'executa en producció: una versió diferent del llenguatge, una extensió que falta, una configuració diferent. Una imatge Docker elimina tota aquesta classe de problemes: la imatge es construeix una vegada, amb totes les dependències fixades, i el mateix artefacte exacte s'executa en proves i en producció. No hi ha res «configurat manualment al servidor».
Per a tu, això es tradueix directament en estabilitat. Quan edites el teu web a l'editor visual de panel.4buildsite.net i prems publicar, la versió que arriba als visitants ha passat pels mateixos passos, pels mateixos serveis contenidoritzats, cada vegada. Menys sorpreses després de publicar.
Publicacions i retrocés en segons
A 4buildsite, publicar no significa «aturar el web, copiar fitxers i esperar que vagi bé». Cada publicació genera una versió nova i completa del teu web — renderitzada de manera estàtica, separada de la que està en directe — i el canvi és atòmic: en una sola operació, el servei de lliurament comença a servir la versió nova. Els visitants no veuen cap interrupció — ni tan sols enmig d'una comanda, amb articles al carro. El mateix principi s'aplica als serveis de la plataforma: la versió nova d'un contenidor s'inicia al costat de l'antiga i només rep trànsit després de superar les comprovacions d'estat.
Igual d'important és el camí de tornada. Cada versió publicada del web es conserva intacta, de manera que tornar a la versió anterior és simplement canviar-hi de nou — una operació de segons, no una restauració de còpia de seguretat de moltes hores. Si una publicació introdueix un problema, la teva botiga no es queda atrapada a la versió trencada. L'única matisació honesta: les dades (comandes, productes, contingut) viuen a la base de dades, separades de les versions publicades — per això es gestionen en volums persistents, separats dels fitxers del web.
- Cada publicació = una versió nova i completa, canviada de manera atòmica
- Retrocés = tornar a la versió anterior, en segons
- Publica canvis en qualsevol moment, fins i tot en plena temporada de vendes
Eficiència i cost: més rendiment pels mateixos diners
Una màquina virtual clàssica executa un sistema operatiu complet per a cada aplicació — gigabytes de memòria i minuts de temps d'arrencada gastats només en l'«empaquetatge». Els contenidors comparteixen el nucli del host, de manera que molts més webs caben al mateix servidor, cadascun amb el seu propi aïllament. Aquesta densitat és el motiu pel qual 4buildsite pot incloure l'allotjament i l'SSL a la subscripció, sense cost d'infraestructura separat per web.
Per al teu web publicat, escalar el trànsit és encara més senzill: com que són fitxers estàtics, servir-los és extremadament barat — un pic de visitants significa més fitxers lliurats, no processos addicionals trepitjant-se entre ells. I els serveis de la plataforma, en ser contenidors que s'inicien en segons, poden rebre instàncies addicionals quan cal. Pagues una subscripció previsible, no una infraestructura dimensionada permanentment per al dia més intens de l'any. Per saber com operem realment aquests contenidors — orquestració, servidor intermediari, CI/CD, monitorització — consulta la pàgina Cloud i DevOps.
Avantatges i limitacions
Avantatges
- El web publicat es serveix de manera estàtica i la plataforma s'executa en contenidors aïllats — un veí ocupat o compromès no pot afectar-lo.
- Les mateixes imatges de la plataforma en proves i en producció — zero «a la meva màquina funciona».
- Publicacions: la versió nova del web es genera per separat i es canvia de manera atòmica.
- Retrocés instantani a la versió publicada anteriorment si un canvi va malament.
- Els contenidors s'inicien en segons.
- Alta densitat per servidor — allotjament inclòs a la subscripció, sense cost separat.
Limitacions
- L'aïllament utilitza el nucli compartit del host — més feble que l'aïllament de maquinari d'una màquina virtual dedicada.
- El contenidor és efímer: les dades persistents (base de dades, fitxers pujats) necessiten volums i còpies de seguretat gestionats per separat.
- Les imatges i les seves capes consumeixen espai de disc — sense neteja periòdica s'acumulen.
- Per als equips que l'executen pel seu compte, Docker té una corba d'aprenentatge real — a 4buildsite la gestiona completament la plataforma.
Veredicte ràpid
La contenidorització amb Docker és l'estàndard de facto del sector per executar aplicacions web: aïllament, coherència entre proves i producció i retrocés instantani. A 4buildsite, la plataforma que construeix i serveix el teu web s'executa contenidoritzada, i les publicacions del teu web estan versionades, es canvien de manera atòmica i es poden revertir en segons — com s'opera la infraestructura (orquestració, servidor intermediari, CI/CD) es tracta a la pàgina Cloud i DevOps.
Taula d'especificacions
| Capacitat | Límit / llindar | Ús típic | |
|---|---|---|---|
| Aïllament de recursos | Límits de CPU/RAM per contenidor (cgroups, namespaces) | Nucli compartit — no és aïllament de maquinari com en una VM | Webs i botigues en infraestructura compartida |
| Inici / desplegament | El contenidor s'inicia en segons | La primera baixada de la imatge triga més | Publicacions i actualitzacions freqüents |
| Retrocés | Tornada a qualsevol imatge anterior en segons | Les dades de la base de dades no es reverteixen amb la imatge | Recuperació instantània quan una actualització va malament |
| Portabilitat | Imatge OCI — s'executa en qualsevol host Linux o núvol | Les imatges són per arquitectura (x86/ARM) | Moure's entre servidors sense reescriure l'aplicació |
| Densitat / cost | Desenes de contenidors aïllats en un sol servidor | Tots comparteixen el nucli i el disc del host | Baix cost per web — allotjament inclòs a la subscripció |
Docker vs màquines virtuals vs allotjament compartit (cPanel)
| Criteri | Docker (contenidors) | Màquines virtuals | Allotjament compartit (cPanel) |
|---|---|---|---|
| Aïllament | Per contenidor (processos, fitxers, recursos) | Complet (maquinari virtualitzat) | Feble — centenars de webs al mateix servidor |
| Velocitat d'inici / desplegament | Segons | Minuts (arrencada completa del SO) | Canvis directament al servidor en directe (FTP) |
| Sobrecàrrega de recursos | Mínima — sense SO separat per aplicació | Alta — un SO complet per màquina | Baixa, però compartida sense control entre veïns |
| Retrocés | Instantani — reiniciar la imatge anterior | Des d'una instantània — més lent | Manual, des d'una còpia de seguretat |
| Seguretat | Incident limitat al contenidor | L'aïllament més fort | Un web compromès pot afectar els veïns |
| Cost per web | Baix — alta densitat per servidor | Alt — pagues tota la màquina | Molt baix, però amb rendiment imprevisible |
Preguntes freqüents
Docker afecta la velocitat del meu web?
No. Els contenidors s'executen de manera nativa sobre el nucli Linux, sense capa de virtualització de maquinari, de manera que la sobrecàrrega és insignificant. La velocitat del web la determinen el codi, la memòria cau i la xarxa — i l'aïllament de recursos la fa, de fet, més previsible que en un allotjament compartit.
Per què no un allotjament cPanel clàssic, com amb WordPress?
En un allotjament compartit clàssic, centenars de webs comparteixen el mateix servidor sense límits estrictes: un veí ocupat t'alenteix i un de compromès et pot afectar. A 4buildsite, el web publicat es serveix de manera estàtica — sense codi per web que es pugui comprometre — i els serveis de la plataforma s'executen aïllats en contenidors. Coses que cPanel no ofereix.
Què passa si una publicació trenca el meu web?
La versió publicada anteriorment encara existeix, intacta, de manera que tornar-hi triga segons: el servei de lliurament hi torna a canviar. La botiga mai no es queda atrapada en una versió trencada i les dades de la base de dades romanen intactes.
Cal que sàpiga Docker per utilitzar 4buildsite?
No. La contenidorització la gestiona completament la plataforma: construeixes el teu web a l'editor visual de panel.4buildsite.net i el publiques. Docker funciona «sota el capó» — obtens els avantatges (aïllament, retrocés) sense cap configuració.
Docker és segur per a una botiga en línia?
Sí. L'aïllament de processos i del sistema de fitxers limita l'abast d'un incident a aquell contenidor, no a tot el servidor. Les dades de la targeta, de totes maneres, mai no passen pel contenidor — els pagaments els processa Stripe, a la infraestructura certificada de Stripe.
Docker és el mateix que una màquina virtual?
No. Una màquina virtual virtualitza el maquinari complet i executa el seu propi sistema operatiu — arrenca en minuts i consumeix molt. Un contenidor comparteix el nucli del host: s'inicia en segons, utilitza una fracció dels recursos i manté l'aplicació aïllada.