A legtöbb WordPress-oldal megosztott tárhelyen vagy egy kézzel összerakott szerveren fut, ahol a PHP-verzió, a bővítmények és maga a WordPress mag évek alatt egy olyan állapotba kerül, amit senki nem tud pontosan visszaadni egy másik gépen. Amikor egy ilyen oldalon hibát kell javítani, vagy egy bővítményt frissíteni kell, a fejlesztő az éles szerveren kísérletezik, mert a helyi gépén nincs ugyanaz a környezet.
Mi romlik el egy kézzel karbantartott szerveren
Egyetlen nap alatt semmi. A baj az évek alatt gyűlik össze. Valaki felrak egy PHP-kiterjesztést, mert egy bővítmény kérte; valaki átír egy időkorlátot, mert egy import elszállt; valaki feltölt FTP-vel egy javított sablonfájlt, és ez a javítás soha nem kerül be a verziókövetésbe. A szerver állapota így egy olyan összeg lesz, amit senki nem írt le, és aminek a fele már nem is emlékszik magára.
Ez rendszerint a legrosszabbkor derül ki, tehát költözésnél, egy PHP-főverzió lejáratánál, vagy amikor a régi fejlesztő már nem elérhető. Ilyenkor az oldalt nem újratelepíteni kell, hanem visszafejteni.
Mi változik konténerben
Docker-konténerbe csomagolva az oldal PHP-verziója, a szerver konfigurációja és a bővítménylista egyetlen, verziókövetett fájlban rögzül. A fejlesztő a saját gépén ugyanazt a konténert indítja el, amit élesben futtatunk, tehát nem egy hasonló környezetet, hanem szó szerint ugyanazt.
Ennek három azonnali következménye van:
- egy bővítményfrissítés előbb helyben tesztelhető, és csak utána megy ki élesbe,
- ha valami elromlik, a régi image-re egy paranccsal vissza lehet állni, adatvesztés nélkül,
- egy új fejlesztő fél óra alatt fut fel a projektre, nem két nap alatt.
A tartalom és a feltöltött fájlok természetesen nem az image-ben laknak, hanem külön köteten és az adatbázisban. A visszaállás a kódot és a környezetet érinti, a cikkeket nem.
Az egyedi kód a legérzékenyebb pont
Ennek különösen akkor van súlya, ha az oldalon van egyedi fejlesztés is, egy saját bővítmény, egy egyedi sablon vagy egy API-integráció. Ott a „csak töltsd fel FTP-vel, majd meglátjuk” megközelítés a legveszélyesebb, mert nincs mihez visszatérni, ha nem vált be.
A konténerizált verzió ugyanazt adja, amit egy modern alkalmazás. Van egy build lépés, van egy tesztkörnyezet, és az éles váltás egy jól definiált, visszavonható esemény, nem egy este végzett kézi munka. A frissítés így nem bátorság kérdése lesz, hanem rutin.
Mibe kerül az átállás
A dockerizálás nem ingyenes. Az átállás igényel egy alapos felmérést arról, milyen bővítmények és egyedi kódok futnak az oldalon, mi az, ami valóban használatban van, és mi az, amit évek óta senki nem nyitott meg. Ez néhány napos munka, és a végén rendszerint kevesebb bővítmény marad, mint amennyi induláskor volt.
Ez a néhány nap viszont egyszer fizetendő ki, míg a kézi, dokumentálatlan szerverkezelés kockázata minden egyes frissítésnél újra jelentkezik.
Mikor nem éri meg
Egy statikus bemutatkozó oldalnál, amin évente egyszer változik egy telefonszám, és nincs rajta egyedi kód, a konténerizálás túl nagy apparátus. Ott a jó válasz inkább egy rendes mentés és egy karbantartott tárhely.
A határ ott van, ahol az oldal elkezd üzletileg számítani. Ha egy leállás bevételt visz, vagy ha van rajta olyan kód, amit mi írtunk, akkor a visszaállíthatóság már nem kényelmi kérdés.
