Docker til WordPress: Hvorfor isolerede containere ændrer alt

Traditionel WordPress-hosting placerer flere websteder på én server. De deler PHP, de deler filsystemadgang, og ofte deler de en databaseserver. Dette er fint, indtil det ikke er det – og når det ikke er det, er det et alvorligt problem.

PAGEnza provisionerer hvert WordPress-websted i sin egen Docker-container. Dette indlæg forklarer, hvad det betyder i praksis, og hvorfor det er vigtigt for bureauer, der administrerer flere klientwebsteder.

Problemet med delt hosting

På en typisk delt hostingplan eller endda en grundlæggende VPS med flere WordPress-installationer:

Ressourcekonflikt: Et websted, der oplever en trafikspids, sænker alle andre websteder på serveren. Et dårligt optimeret plugin på websted A forringer ydeevnen på websted B.

Sikkerhedsblødning: Hvis én WordPress-installation bliver kompromitteret – via et sårbart plugin, en svag adgangskode eller en forældet kerneversion – kan en angriber, der får filsystemadgang, ofte læse filer fra andre websteder på samme server.

PHP-versionskonflikter: Websted A kræver PHP 7.4 til et gammelt plugin. Websted B kræver PHP 8.2 til et nyere. På delt hosting vælger du én.

Databaseeksponering: Delte databaseservere betyder, at én forkert konfigureret brugerrettighed kan eksponere andre websteders data.

Docker-containere løser alle disse problemer på infrastrukturniveau.

Hvad en container faktisk er

En Docker-container er en letvægts, isoleret proces, der har sit eget:

• Filsystem (containeren kan ikke se filer uden for sine grænser)
• Netværksstak (sin egen IP-adresse, sine egne porte)
• Procesrum (den kan ikke se andre containers processer)
• Ressourcebegrænsninger (CPU- og hukommelsesgrænser)

Den deler værts-kernen med andre containere, men alt over kernen er isoleret. Det er ikke en fuld virtuel maskine – den starter på sekunder, ikke minutter, og bruger en brøkdel af ressourcerne.

Til WordPress kører en enkelt container: Nginx, PHP-FPM og WordPress-filer. Databasen kører i en separat container, der kun er forbundet til den specifikke WordPress-container.

Hvordan PAGEnza provisionerer et websted

Når du opretter et nyt klientwebsted i PAGEnza, sker følgende på under 45 sekunder:

1. En ny Docker-container startes fra et grundlæggende WordPress-image
2. WordPress konfigureres med en frisk database på den delte MariaDB-instans (isoleret til containerens legitimationsoplysninger)
3. PAGEnza-pluginet installeres og aktiveres automatisk
4. En Nginx virtuel vært konfigureres med klientens underdomæne
5. SSL udstedes via Let's Encrypt
6. Containeren registreres i reverse proxyen med de korrekte routingregler

Klienten får en URL som klientnavn.pagenza.com, der er live inden for 45 sekunder efter at have klikket på "Opret websted." Ingen manuel serverkonfiguration, ingen SSH, ingen DNS-ventetid (for underdomænet – DNS-propagering af brugerdefinerede domæner er separat).

Containerisolering i praksis

Hukommelsesgrænser: Hver container har en konfigurerbar hukommelsesgrænse. Hvis et løbsk plugin forårsager en hukommelsesspids på én klients websted, kan det ikke forbruge hukommelse, der er allokeret til andre containere. Webstedet kan blive langsommere eller returnere en 503 – men det vil ikke påvirke andre klienter.

Filsystemisolering: WordPress-filerne for klient A er fuldstændig usynlige for klient B's container. Et kompromitteret plugin på klient A's websted har ingen vej til klient B's filer.

Netværksisolering: Containere kommunikerer kun gennem definerede netværksbroer. Databascontaineren for klient A accepterer kun forbindelser fra klient A's WordPress-container – ikke fra nogen anden container på systemet.

PHP pr. container: Da hver container kører sin egen PHP-FPM-instans, kan du køre forskellige PHP-versioner for forskellige klienter. Klient A's ældre plugin, der kræver PHP 7.4, kører fint ved siden af klient B's moderne stak på PHP 8.2.

Brugerdefinerede domæner

Standardopsætningen giver hver klient et *.pagenza.com underdomæne. For klienter, der ønsker deres eget domæne, er processen:

1. Klienten peger deres domænes A-record på PAGEnza-serverens IP
2. I PAGEnza-dashboardet indtaster du det brugerdefinerede domæne
3. Reverse proxy-konfigurationen opdateres automatisk
4. SSL udstedes til det brugerdefinerede domæne via Let's Encrypt

WordPress siteurl- og home-indstillingerne opdateres for at matche. Fra klientens perspektiv fungerer deres websted bare på deres domæne – ingen omdirigering, intet underdomæne synligt for besøgende.

Hvad dette betyder for bureauer

Den praktiske fordel for bureauer, der driver flere klientwebsteder:

Onboardinghastighed: Provisionering af et nyt klientwebsted tager under et minut. Ingen serveropsætning, ingen cPanel, ingen manuel WordPress-installation.

Klientadskillelse: Hvert klients websted er ægte isoleret. En klient, der installerer et problematisk plugin, påvirker kun deres eget websted.

Skalerbarhed: Tilføjelse af en ny klient kræver ikke provisionering af en ny server. Containerinfrastrukturen skalerer til værtens kapacitet, og tilføjelse af mere kapacitet er et spørgsmål om at tilføje flere værtsnoder.

Katastrofegendannelse: Da hvert websted er containeriseret, fungerer backup og gendannelse på container-niveau. Gendannelse af én klients websted påvirker ikke andre klienter.

Kompromiset er, at containerhosting koster mere pr. websted end delt hosting. Men for bureauer, hvor websteds-pålidelighed og klientadskillelse er ikke-forhandlingsbar, giver økonomien mening – især når besparelserne i provisioneringstid medregnes.