← Vissza: Blog

Blog

Docker WordPresshez: Miért változtat meg mindent az izolált konténer

Egy ügyfél nem tehet tönkre egy másikat. Egy webhely nem fertőzhet meg egy másikat. Ez a PAGEnza tárhelyplatformjának architektúrája.

A hagyományos WordPress tárhely több webhelyet helyez egy szerverre. Megosztják a PHP-t, megosztják a fájlrendszer-hozzáférést, és gyakran megosztanak egy adatbázis-szervert. Ez addig rendben van, amíg nem okoz problémát – és amikor mégis, az komoly gond.

A PAGEnza minden WordPress webhelyet saját Docker konténerbe helyez. Ez a bejegyzés elmagyarázza, mit jelent ez a gyakorlatban, és miért fontos ez ügynökségek számára, amelyek több ügyfél webhelyét kezelik.

A megosztott tárhely problémája

A tipikus megosztott tárhelycsomagban vagy akár egy több WordPress telepítéssel rendelkező alapvető VPS-en:

Erőforrás-konfliktus: egy webhely forgalmi csúcsa lelassítja a szerveren lévő összes többi webhelyet. Egy rosszul optimalizált bővítmény az A webhelyen rontja a B webhely teljesítményét.

Biztonsági átszivárgás: ha egy WordPress telepítés kompromittálódik – egy sebezhető bővítményen, gyenge jelszón vagy elavult verziójú verzión keresztül –, egy támadó, aki fájlrendszer-hozzáférést szerez, gyakran olvashat fájlokat más, ugyanazon a szerveren lévő webhelyekről.

PHP verziókonfliktusok: az A webhelynek PHP 7.4-re van szüksége egy régi bővítményhez. A B webhelynek PHP 8.2-re van szüksége egy újabbhoz. Megosztott tárhelyen csak egyet választhatsz.

Adatbázis-kitettség: a megosztott adatbázis-szerverek azt jelentik, hogy egy rosszul konfigurált felhasználói engedély más webhelyek adatait teheti ki.

A Docker konténerek mindezt infrastruktúra szinten megoldják.

Mi is valójában egy konténer?

A Docker konténer egy könnyű, izolált folyamat, amelynek sajátja van:

  • Fájlrendszer (a konténer nem látja a határain kívüli fájlokat)
  • Hálózati verem (saját IP-cím, saját portok)
  • Folyamattér (nem látja más konténerek folyamatait)
  • Erőforráskorlátok (CPU és memória sapkák)

Megosztja a gazdagép kernelét más konténerekkel, de a kernel feletti minden izolált. Nem egy teljes virtuális gép – másodpercek alatt indul, nem percek alatt, és az erőforrások töredékét használja.

WordPress esetén egyetlen konténer futtatja: Nginx, PHP-FPM és a WordPress fájlokat. Az adatbázis egy külön konténerben fut, amely csak az adott WordPress konténerhez csatlakozik.

Hogyan helyez el a PAGEnza egy webhelyet?

Amikor új ügyfél webhelyet hoz létre a PAGEnza-ban, a következő történik kevesebb mint 45 másodperc alatt:

  1. Egy új Docker konténer indul el egy alap WordPress képből
  2. A WordPress konfigurálva van egy friss adatbázissal a megosztott MariaDB példányon (az adott konténer hitelesítő adataihoz izolálva)
  3. A PAGEnza bővítmény automatikusan települ és aktiválódik
  4. Egy Nginx virtuális gazda van konfigurálva az ügyfél aldomainjével
  5. SSL kerül kiadásra a Let's Encrypt-en keresztül
  6. A konténer regisztrálva van a fordított proxyban a megfelelő útválasztási szabályokkal

Az ügyfél egy olyan URL-t kap, mint clientname.pagenza.com, amely az "Új webhely létrehozása" gombra kattintás után 45 másodpercen belül élő.

Konténer izoláció a gyakorlatban

Memóriakorlátok: minden konténernek van konfigurálható memóriakapacitása. Ha egy elszabadult bővítmény memóriacsúcsot okoz az egyik ügyfél webhelyén, az nem fogyaszthatja el a többi konténernek allokált memóriát. A webhely lelassulhat vagy 503-as hibát adhat vissza – de ez nem érinti a többi ügyfelet.

Fájlrendszer izoláció: az A ügyfél WordPress fájljai teljesen láthatatlanok a B ügyfél konténerének. Az A ügyfél webhelyén lévő kompromittált bővítménynek nincs útja a B ügyfél fájljaihoz.

Hálózati izoláció: a konténerek csak meghatározott hálózati hidakon keresztül kommunikálnak. Az A ügyfél adatbázis konténere csak az A ügyfél WordPress konténeréből fogad kapcsolatokat – nem a rendszer bármely más konténeréből.

PHP konténerenként: mivel minden konténer saját PHP-FPM példányt futtat, különböző PHP verziókat futtathat különböző ügyfelek számára. Az A ügyfél örökölt bővítménye, amelynek PHP 7.4-re van szüksége, jól fut a B ügyfél modern, PHP 8.2-es veremével párhuzamosan.

Egyéni domainek

Az alapértelmezett beállítás minden ügyfélnek egy *.pagenza.com aldomainet biztosít. Azoknak az ügyfeleknek, akik saját domainjüket szeretnék, a folyamat a következő:

  1. Az ügyfél a domainjének A rekordját a PAGEnza szerver IP-címére irányítja
  2. A PAGEnza irányítópulton megadja az egyéni domaint
  3. A fordított proxy konfigurációja automatikusan frissül
  4. SSL kerül kiadásra az egyéni domainhez a Let's Encrypt-en keresztül

A WordPress siteurl és home opciók frissülnek, hogy megfeleljenek. Az ügyfél szempontjából a webhelye egyszerűen működik a domainjén – nincs átirányítás, nincs aldomain látható a látogatók számára.

Mit jelent ez az ügynökségek számára?

A több ügyfél webhelyét futtató ügynökségek gyakorlati előnyei:

Bevezetési sebesség: egy új ügyfél webhelyének kiépítése kevesebb mint egy percet vesz igénybe. Nincs szerverbeállítás, nincs cPanel, nincs manuális WordPress telepítés.

Ügyfél szétválasztás: minden ügyfél webhelye valóban izolált. Egy ügyfél, aki problémás bővítményt telepít, csak a saját webhelyét érinti.

Skálázhatóság: egy új ügyfél hozzáadása nem igényel új szerver kiépítését. A konténer infrastruktúra a gazdagép kapacitásához igazodik, és a kapacitás növelése további gazdagép csomópontok hozzáadásával történik.

Vészhelyreállítás: mivel minden webhely konténerizált, a biztonsági mentés és visszaállítás konténer szinten működik. Egyetlen ügyfél webhelyének visszaállítása nem érinti a többi ügyfelet.

A kompromisszum az, hogy a konténeres tárhely webhelyenként többe kerül, mint a megosztott tárhely. De azoknál az ügynökségeknél, ahol a webhely megbízhatósága és az ügyfelek szétválasztása nem alkuvó, a gazdaságosság megéri – különösen, ha figyelembe vesszük a kiépítési idő megtakarítását.