Docker for WordPress: Hvorfor isolerte containere endrer alt

Tradisjonell WordPress-hosting plasserer flere nettsteder på én server. De deler PHP, de deler filsystemtilgang, og ofte deler de en databaseserver. Dette er greit helt til det ikke er det – og når det ikke er det, er det et alvorlig problem.

PAGEnza provisjonerer hvert WordPress-nettsted i sin egen Docker-container. Dette innlegget forklarer hva det betyr i praksis og hvorfor det er viktig for byråer som administrerer flere klientnettsteder.

Problemet med delt hosting

På en typisk delt hostingplan eller til og med en grunnleggende VPS med flere WordPress-installasjoner:

Ressurskonflikt: Ett nettsted som får en trafikkspurt, bremser ned alle andre nettsteder på serveren. Et dårlig optimalisert plugin på nettsted A forringer ytelsen på nettsted B.

Sikkerhetslekkasje: Hvis én WordPress-installasjon blir kompromittert – via et sårbart plugin, et svakt passord eller en utdatert kjerneversjon – kan en angriper som får filsystemtilgang, ofte lese filer fra andre nettsteder på samme server.

PHP-versjonskonflikter: Nettsted A trenger PHP 7.4 for et gammelt plugin. Nettsted B trenger PHP 8.2 for et nyere. På delt hosting velger du én.

Databaseeksponering: Delte databaseservere betyr at én feilkonfigurert brukertillatelse kan eksponere andre nettsteders data.

Docker-containere løser alle disse på infrastrukturnivå.

Hva en container faktisk er

En Docker-container er en lett, isolert prosess som har sitt eget:

• Filsystem (containeren kan ikke se filer utenfor sine grenser)
• Nettverksstabel (sin egen IP-adresse, sine egne porter)
• Prosessområde (den kan ikke se andre containers prosesser)
• Ressursgrenser (CPU- og minnekapsler)

Den deler vertskjernen med andre containere, men alt over kjernen er isolert. Det er ikke en full virtuell maskin – den starter på sekunder, ikke minutter, og bruker en brøkdel av ressursene.

For WordPress kjører en enkelt container: Nginx, PHP-FPM og WordPress-filer. Databasen kjører i en separat container, koblet kun til den spesifikke WordPress-containeren.

Hvordan PAGEnza provisjonerer et nettsted

Når du oppretter et nytt klientnettsted i PAGEnza, skjer følgende på under 45 sekunder:

1. En ny Docker-container startes fra et grunnleggende WordPress-image
2. WordPress konfigureres med en fersk database på den delte MariaDB-instansen (isolert til den containerens legitimasjon)
3. PAGEnza-pluginet installeres og aktiveres automatisk
4. En Nginx virtuell vert konfigureres med klientens subdomene
5. SSL utstedes via Let's Encrypt
6. Containeren registreres i omvendt proxy med de riktige rutingreglene

Klienten får en URL som klientenavn.pagenza.com som er live innen 45 sekunder etter å ha klikket "Opprett nettsted." Ingen manuell serverkonfigurasjon, ingen SSH, ingen DNS-ventetid (for subdomenet – DNS-propagering for egendefinerte domener er separat).

Containerisolasjon i praksis

Minnegrenser: Hver container har en konfigurerbar minnekapsel. Hvis et løpsk plugin forårsaker en minneøkning på én klients nettsted, kan det ikke forbruke minne som er tildelt andre containere. Nettstedet kan bli tregere eller returnere en 503 – men det vil ikke påvirke andre klienter.

Filsystemisolasjon: WordPress-filene for klient A er fullstendig usynlige for klient B sin container. Et kompromittert plugin på klient A sitt nettsted har ingen vei til klient B sine filer.

Nettverksisolasjon: Containere kommuniserer kun gjennom definerte nettverksbroer. Databasecontaineren for klient A aksepterer kun tilkoblinger fra klient A sin WordPress-container – ikke fra noen annen container på systemet.

PHP per container: Fordi hver container kjører sin egen PHP-FPM-instans, kan du kjøre forskjellige PHP-versjoner for forskjellige klienter. Klient A sitt eldre plugin som trenger PHP 7.4 kjører fint ved siden av klient B sin moderne stabel på PHP 8.2.

Egendefinerte domener

Standardoppsettet gir hver klient et *.pagenza.com subdomene. For klienter som ønsker sitt eget domene, er prosessen:

1. Klienten peker domenets A-oppføring til PAGEnza-serverens IP
2. I PAGEnza-dashbordet skriver du inn det egendefinerte domenet
3. Omvendt proxy-konfigurasjonen oppdateres automatisk
4. SSL utstedes for det egendefinerte domenet via Let's Encrypt

WordPress siteurl- og home-alternativene oppdateres for å matche. Fra klientens perspektiv fungerer nettstedet deres bare på domenet deres – ingen omdirigering, ingen subdomene synlig for besøkende.

Hva dette betyr for byråer

Den praktiske fordelen for byråer som driver flere klientnettsteder:

Onboardinghastighet: Provisjonering av et nytt klientnettsted tar under et minutt. Ingen serveroppsett, ingen cPanel, ingen manuell WordPress-installasjon.

Klientseparasjon: Hvert klients nettsted er genuint isolert. En klient som installerer et problematisk plugin, påvirker kun sitt eget nettsted.

Skalerbarhet: Å legge til en ny klient krever ikke provisjonering av en ny server. Containerinfrastrukturen skalerer til vertens kapasitet, og å legge til mer kapasitet er et spørsmål om å legge til flere vertsnoder.

Katastrofegjenoppretting: Fordi hvert nettsted er containerisert, opererer sikkerhetskopiering og gjenoppretting på containernivå. Gjenoppretting av én klients nettsted påvirker ingen andre klienter.

Ulempen er at containerhosting koster mer per nettsted enn delt hosting. Men for byråer der nettsteds pålitelighet og klientseparasjon er ikke-forhandlingsbare, gir økonomien mening – spesielt når tidsbesparelsene ved provisjonering tas med i betraktningen.