Docker pentru WordPress: De ce containerele izolate schimbă totul

Găzduirea tradițională WordPress plasează mai multe site-uri pe un singur server. Ele partajează PHP, partajează accesul la sistemul de fișiere și, adesea, partajează un server de baze de date. Acest lucru este în regulă până când nu mai este — și când nu mai este, este o problemă serioasă.

PAGEnza provizionează fiecare site WordPress într-un container Docker propriu. Această postare explică ce înseamnă acest lucru în practică și de ce contează pentru agențiile care gestionează mai multe site-uri ale clienților.

Problema găzduirii partajate

Pe un plan tipic de găzduire partajată sau chiar pe un VPS de bază cu mai multe instalări WordPress:

Competiție pentru resurse: un site care primește un vârf de trafic încetinește toate celelalte site-uri de pe server. Un plugin prost optimizat pe site-ul A degradează performanța pe site-ul B.

Contaminare de securitate: dacă o instalare WordPress este compromisă — printr-un plugin vulnerabil, o parolă slabă sau o versiune de bază învechită — un atacator care obține acces la sistemul de fișiere poate citi adesea fișiere de la alte site-uri de pe același server.

Conflicte de versiuni PHP: site-ul A necesită PHP 7.4 pentru un plugin vechi. Site-ul B necesită PHP 8.2 pentru unul mai nou. Pe găzduirea partajată, alegi una.

Expunere baze de date: serverele de baze de date partajate înseamnă că o permisiune de utilizator configurată greșit poate expune datele altor site-uri.

Containerele Docker rezolvă toate acestea la nivel de infrastructură.

Ce este de fapt un container

Un container Docker este un proces ușor, izolat, care are propriul său:

• Sistem de fișiere (containerul nu poate vedea fișierele din afara limitelor sale)

• Stivă de rețea (propriul său IP, propriile sale porturi)

• Spațiu de procese (nu poate vedea procesele altor containere)

• Limite de resurse (limite CPU și memorie)

Acesta partajează kernelul gazdă cu alte containere, dar tot ce este deasupra kernelului este izolat. Nu este o mașină virtuală completă — pornește în secunde, nu în minute, și folosește o fracțiune din resurse.

Pentru WordPress, un singur container rulează: Nginx, PHP-FPM și fișierele WordPress. Baza de date rulează într-un container separat, conectat doar la acel container WordPress specific.

Cum provizionează PAGEnza un site

Când creezi un nou site pentru un client în PAGEnza, iată ce se întâmplă în mai puțin de 45 de secunde:

1. Un nou container Docker este pornit dintr-o imagine WordPress de bază
2. WordPress este configurat cu o bază de date proaspătă pe instanța MariaDB partajată (izolată la credențialele containerului respectiv)
3. Pluginul PAGEnza este instalat și activat automat
4. Un host virtual Nginx este configurat cu subdomeniul clientului
5. SSL este emis prin Let's Encrypt
6. Containerul este înregistrat în proxy-ul invers cu regulile de rutare corecte

Clientul primește un URL precum clientname.pagenza.com care este live în 45 de secunde de la apăsarea butonului "Creează site". Nicio configurare manuală a serverului, nicio SSH, nicio așteptare DNS (pentru subdomeniu — propagarea DNS a domeniului personalizat este separată).

Izolarea containerelor în practică

Limite de memorie: fiecare container are o limită de memorie configurabilă. Dacă un plugin scăpat de sub control cauzează un vârf de memorie pe site-ul unui client, acesta nu poate consuma memoria alocată altor containere. Site-ul poate încetini sau returna un 503 — dar nu va afecta alți clienți.

Izolarea sistemului de fișiere: fișierele WordPress ale clientului A sunt complet invizibile pentru containerul clientului B. Un plugin compromis pe site-ul clientului A nu are nicio cale către fișierele clientului B.

Izolarea rețelei: containerele comunică doar prin punți de rețea definite. Containerul bazei de date pentru clientul A acceptă conexiuni doar de la containerul WordPress al clientului A — nu de la niciun alt container din sistem.

PHP per container: deoarece fiecare container rulează propria sa instanță PHP-FPM, poți rula versiuni PHP diferite pentru clienți diferiți. Pluginul vechi al clientului A care necesită PHP 7.4 rulează bine alături de stiva modernă a clientului B pe PHP 8.2.

Domenii personalizate

Configurația implicită oferă fiecărui client un subdomeniu *.pagenza.com. Pentru clienții care doresc propriul domeniu, procesul este:

1. Clientul indică înregistrarea A a domeniului său către IP-ul serverului PAGEnza
2. În tabloul de bord PAGEnza, introduci domeniul personalizat
3. Configurația proxy-ului invers este actualizată automat
4. SSL este emis pentru domeniul personalizat prin Let's Encrypt

Opțiunile WordPress siteurl și home sunt actualizate pentru a corespunde. Din perspectiva clientului, site-ul său funcționează pur și simplu la domeniul său — fără redirecționare, fără subdomeniu vizibil pentru vizitatori.

Ce înseamnă asta pentru agenții

Beneficiul practic pentru agențiile care rulează mai multe site-uri ale clienților:

Viteză de onboarding: provizionarea unui nou site pentru un client durează mai puțin de un minut. Nicio configurare de server, nicio cPanel, nicio instalare manuală WordPress.

Separare clienți: site-ul fiecărui client este cu adevărat izolat. Un client care instalează un plugin problematic afectează doar propriul său site.

Scalabilitate: adăugarea unui nou client nu necesită provizionarea unui nou server. Infrastructura containerelor scalează la capacitatea gazdei, iar adăugarea de capacitate suplimentară este o chestiune de adăugare de mai multe noduri gazdă.

Recuperare în caz de dezastru: deoarece fiecare site este containerizat, backup-ul și restaurarea operează la nivel de container. Restaurarea site-ului unui singur client nu afectează niciun alt client.

Compromisul este că găzduirea în containere costă mai mult pe site decât găzduirea partajată. Dar pentru agențiile unde fiabilitatea site-ului și separarea clienților sunt non-negociabile, economia funcționează — mai ales când se iau în considerare economiile de timp la provizionare.