Docker voor WordPress: Waarom Geïsoleerde Containers Alles Veranderen

Traditionele WordPress hosting plaatst meerdere sites op één server. Ze delen PHP, ze delen toegang tot het bestandssysteem en vaak delen ze een databaseserver. Dit is prima, totdat het dat niet meer is – en als het niet meer is, is het een serieus probleem.

PAGEnza voorziet elke WordPress site in zijn eigen Docker container. Deze post legt uit wat dat in de praktijk betekent en waarom het belangrijk is voor bureaus die meerdere klantensites beheren.

Het gedeelde hostingprobleem

Op een typisch gedeeld hostingplan of zelfs een basis VPS met meerdere WordPress installaties:

Resource-concurrentie: één site die een piek in het verkeer krijgt, vertraagt elke andere site op de server. Een slecht geoptimaliseerde plugin op site A degradeert de prestaties op site B.

Beveiligingslekken: als één WordPress installatie gecompromitteerd raakt – via een kwetsbare plugin, een zwak wachtwoord of een verouderde core-versie – kan een aanvaller die toegang krijgt tot het bestandssysteem vaak bestanden van andere sites op dezelfde server lezen.

PHP-versieconflicten: site A heeft PHP 7.4 nodig voor een oude plugin. Site B heeft PHP 8.2 nodig voor een nieuwere. Op gedeelde hosting kies je er één.

Database-blootstelling: gedeelde databaseservers betekenen dat één verkeerd geconfigureerde gebruikerspermissie de gegevens van andere sites kan blootleggen.

Docker containers lossen al deze problemen op infrastructuurniveau op.

Wat een container eigenlijk is

Een Docker container is een lichtgewicht, geïsoleerd proces dat zijn eigen:

• Bestandssysteem heeft (de container kan geen bestanden buiten zijn grenzen zien)
• Netwerkstack heeft (zijn eigen IP-adres, zijn eigen poorten)
• Procesruimte heeft (het kan de processen van andere containers niet zien)
• Resource limieten heeft (CPU- en geheugenlimieten)

Het deelt de host-kernel met andere containers, maar alles boven de kernel is geïsoleerd. Het is geen volledige virtuele machine – het start in seconden, niet in minuten, en gebruikt een fractie van de resources.

Voor WordPress draait een enkele container: Nginx, PHP-FPM en WordPress-bestanden. De database draait in een aparte container, alleen verbonden met die specifieke WordPress container.

Hoe PAGEnza een site voorziet

Wanneer je een nieuwe klantensite aanmaakt in PAGEnza, gebeurt het volgende in minder dan 45 seconden:

1. Een nieuwe Docker container wordt opgestart vanuit een basis WordPress-image
2. WordPress wordt geconfigureerd met een nieuwe database op de gedeelde MariaDB-instantie (geïsoleerd tot de inloggegevens van die container)
3. De PAGEnza plugin wordt automatisch geïnstalleerd en geactiveerd
4. Een Nginx virtuele host wordt geconfigureerd met de subdomein van de klant
5. SSL wordt uitgegeven via Let's Encrypt
6. De container wordt geregistreerd in de reverse proxy met de juiste routeringsregels

De klant krijgt een URL zoals klantnaam.pagenza.com die live is binnen 45 seconden na het klikken op "Site aanmaken". Geen handmatige serverconfiguratie, geen SSH, geen DNS-wachttijd (voor het subdomein – DNS-propagatie voor aangepaste domeinen is apart).

Containerisolatie in de praktijk

Geheugenlimieten: elke container heeft een configureerbare geheugenlimiet. Als een uit de hand gelopen plugin een geheugenpiek veroorzaakt op de site van één klant, kan deze niet het geheugen verbruiken dat aan andere containers is toegewezen. De site kan vertragen of een 503-foutmelding geven – maar dit heeft geen invloed op andere klanten.

Bestandssysteemisolatie: de WordPress-bestanden voor klant A zijn volledig onzichtbaar voor de container van klant B. Een gecompromitteerde plugin op de site van klant A heeft geen toegang tot de bestanden van klant B.

Netwerkisolatie: containers communiceren alleen via gedefinieerde netwerkbruggen. De databasecontainer voor klant A accepteert alleen verbindingen van de WordPress-container van klant A – niet van enige andere container op het systeem.

PHP per container: omdat elke container zijn eigen PHP-FPM-instantie draait, kun je verschillende PHP-versies voor verschillende klanten gebruiken. De legacy plugin van klant A die PHP 7.4 nodig heeft, draait prima naast de moderne stack van klant B op PHP 8.2.

Aangepaste domeinen

De standaardconfiguratie geeft elke klant een *.pagenza.com subdomein. Voor klanten die hun eigen domein willen, is het proces:

1. De klant wijst het A-record van hun domein naar het PAGEnza server IP
2. In het PAGEnza dashboard voer je het aangepaste domein in
3. De reverse proxy-configuratie wordt automatisch bijgewerkt
4. SSL wordt uitgegeven voor het aangepaste domein via Let's Encrypt

De WordPress siteurl en home opties worden bijgewerkt om overeen te komen. Vanuit het perspectief van de klant werkt hun site gewoon op hun domein – geen omleiding, geen subdomein zichtbaar voor bezoekers.

Wat dit betekent voor bureaus

Het praktische voordeel voor bureaus die meerdere klantensites beheren:

Onboarding snelheid: het inrichten van een nieuwe klantensite duurt minder dan een minuut. Geen serverinstallatie, geen cPanel, geen handmatige WordPress-installatie.

Klantenscheiding: de site van elke klant is echt geïsoleerd. Een klant die een problematische plugin installeert, heeft alleen invloed op zijn eigen site.

Schaalbaarheid: het toevoegen van een nieuwe klant vereist niet het inrichten van een nieuwe server. De containerinfrastructuur schaalt naar de capaciteit van de host, en het toevoegen van meer capaciteit is een kwestie van meer host-nodes toevoegen.

Noodherstel: omdat elke site in een container is geplaatst, werkt back-up en herstel op containerniveau. Het herstellen van de site van één klant heeft geen invloed op andere klanten.

De keerzijde is dat containerhosting per site meer kost dan gedeelde hosting. Maar voor bureaus waar sitebetrouwbaarheid en klantenscheiding niet-onderhandelbaar zijn, kloppen de economische cijfers – vooral wanneer de besparingen op inrichtingstijd worden meegerekend.