Akik régebbről ismernek azok tudják, hogy elég sokat foglalkoztam a Drupal tartalomkezelővel. Ebben az bejegyzésben arról szeretnék írni, hogy mi kell ahhoz, hogy a Drupal-t lehessen Docker környezetben futtatni.
A feltételes mód nem véletlen. Ahhoz, hogy egy alkalmazást a felhőben futtassunk számos követelménynek meg kell felelnie. Számos olyan problémával is meg kell tudnia küzdenie az alkalmazásnak magának, amivel nem kell megküzdeni, ha egy szerveren futtatjuk azt. A Drupal alaprendszer beállításánál figyelnünk kell majd ezekre és lehetséges, hogy kiegészítő modulokra is szükségünk lesz a tökéletes megoldáshoz. A kiegészítő modulokat pedig mindig meg kell majd vizsgálnunk ebből a szempontból is és lesz olyan, amikor majd trükköznünk kell.
Ezért mielőtt nekiállsz jól fontold meg, hogy kell-e neked a felhőinfrastruktúra által nyújtott számos előny. Tényleg ki fogod-e használni a könnyed, akár automatikus skálázódás előnyeit?
Mielőtt valaki félreértené szeretném tisztázni, hogy természetesen egy-egy konkrét telepítést, megfelelő szakértelemmel és hozzáállással akár cloud-native-vé is tehetünk, de ez nem minden esetben lesz könnyen megoldható. Nem mindegy ugyanis, hogy az alkalmazást kiszolgáló infrastruktúrával fedjük el ezeket a dolgokat, vagy maga az alkalmazás képes erre.
Session
Ne legyünk igazságtalanok a Drupallal szemben és jegyezzük meg, hogy a fenti megállapítás sok mindenre ráhúzható, még magára a PHP-ra is. Pl. alapból a PHP nem cloud-native, ha a munkamenet(session) kezelését nézzük. Alapesetben a munkamenethez kapcsolódó információkat a <span class="sy0">/</span>tmp mappában, egy fájlban tárolja a PHP. Képzeljük el, mi van akkor ha egyszerre két konténer szolgálja ki a PHP kéréseket. Na ilyenkor egyszer az egyik konténer <span class="sy0">/</span>tmp mappájába, másszor a másik konténer /tmp mappájában tárolja az adatokat. Könnyen belátható, hogy ez nem nagyon fog működni. Természetesen memecached vagy redish PHP kiegészítőkkel ez gyorsan orvosolható. Ekkor infrastruktúra szintjén tudjuk ezt megoldani egy legacy PHP alkalmazásban.
Szerencsére ebből a szempontból a Drupal elég jól fel van készítve, hisz alapból adatbázisban tárolja a munkamenet információkat.
Adatbázis
Az adatbázis kapcsolódása is egy olyan dolog, amihez nem mindig elég egy <a href="http://www.php.net/mysql_connect"><span class="kw3">mysql_connect</span></a><span class="br0">(</span><span class="br0">)</span>. Sőt sokszor igény van arra, hogy ne csak egy szerverhez tudjon kapcsolódni az alkalmazás, hanem az adatmódosító lekérdezéseket a Master, míg a sima lekérdezések a Slave-ek valamelyikén fusson. Erre a PDO sem nyújt megoldást, erre az alkalmazást külön fel kell készíteni. A Drupalban lehetőségünk van akár erre is, hisz egy központi helyen tudjuk beállítani ezt. Ebben a Drupal szerintem nagyon erős és jó megoldást használ, a hatos verziótól kezdve. Ha esetleg nem egy Drupal oldalnál kell megoldanunk egy ilyen problémát, akkor jól jöhet a ProxySQL csomag, ami ezt a hibát hivatott megoldani. Ha jól olvasom, akkor a Wordpress csak a HyperDB plugin segítségével képes erre. Egyedi kódnál a refaktor helyett szinte minden esetben egyszerűbb a ProxySQL használata.
Az se mindegy, hogy milyen választ ad az alkalmazásunk, ha nem elérhető az adatbázis. Ebben szintén erős a Drupal, hisz ilyenkor egy megfelelő, konfigurálható és testreszabható oldal jelenik meg.
Fájlkezelés
Itt alapvetően háromféle fájlkezelésről kell beszélni. Első körben vannak a publikus, mindenki számára elérhető fájlok. Ebben a Drupal nagyon erős, hisz nem csak a helyüket tudjuk megadni, hanem azt is, hogy milyen url-en keresztül lehet majd ezeket elérni. Ahhoz, hogy ez jól működjön azonban dolgoznunk kell. Meg kell ugyanis oldanunk, hogy ezek a fájlok valamilyen módon szinkronizálásra kerüljenek az egyes futó konténerek között.
Ezt tehetjük a Drupalon kívül, a futtatókörnyezetben megoldva. Például létrehozhatunk egy NFS fájlszervert és a futó konténerekbe ezt mint egy volume bind-oljuk. Ekkor nem kell tudnia a Drupalnak, hogy elosztott rendszerben fut, de a futtatókörnyezetnek tisztába kell lenni azzal, hogy ennek az alkalmazásnak (a Drupalnak) mik az igényei.
Lehet azt is, hogy az alkalmazással együtt csomagolunk valamilyen megoldást, egy stack-et amiben az alkalmazás és a hozzá tartozó fájlmegosztó megoldás is benne van, de ezt tartom a legkevésbé rugalmas és kezelhető megoldásnak, főleg egy legacy alkalmazás transzformációjánál.
A harmadik lehetőség, hogy a Drupal oldja meg a fájl szinkronizálást mondjuk az S3FS drupal modul segítségével. Ekkor a fájlokat közvetlenül egy S3 kompatibilis CDN-be tölti fel a Drupal és a kiszolgálás már ezekről a szerverekről történik. Figyeljünk arra, hogy ha régi oldalt migrálunk, akkor nem csak a fájlokat, hanem az azokra mutató hivatkozásokat is módosítanunk kell majd, ami külső hivatkozások esetén nem biztos, hogy kivitelezhető. Ilyenkor jön jól a S3FS File Proxy to S3 drupal modul, ami megoldja a régi fájlok átirányítását az új helyre.
Ez utóbbi megoldásnál szükségünk lesz legalább egy bekapcsolt kiegészítő modulra és annak beállítására, amelyről a blogbejegyzés végén írok pár szót.
A másik két fájlkezelés a nem publikus és ideiglenes fájlok, amikkel majd szintén meg kell majd küzdenünk. Az előbbinél egy nem publikus tárolóra lesz szükségünk, utóbbinál pedig leggyakrabban elég lesz a konténerben található <span class="sy0">/</span>tmp mappa is. Természetesen csak akkor, ha nem egy olyan modulba futunk bele, ami a Drupal batch megoldását használja nagy fájlok feldolgozására. Például, ha három konténer van és mindig csak a harmadát sikerül az adatoknak exportálni, akkor gyanakodjunk arra, hogy az az adott modul nem alkalmas a cloud környezetben való futtatásra. Itt ugyanis csak sok kompromisszummal terhelt megoldásunk lesz majd. Praktikusabb valamilyen háttérben futó workerrel megoldani a feladatot, amit nem találunk készen.
Levelezés
A Drupal alap esetben, még a 8-as sem tud SMTP-n keresztül emailt küldeni. Ha ezt szeretnénk két lehetőségünk van. Az egyik, hogy a Drupal-t futtató PHP konténerbe olyan sendmail alternatívát telepítünk, ami tud SMTP-n keresztül levelet küldeni, vagy a Drupalba telepítjük és beállítjuk az SMTP drupal modult. Ezt talán az alaprendszer egyik legnagyobb hiányossága szerintem. Talán a kilencesben orvosolva lesz ez a probléma is.
Beállítások
Aki nem járatos a Drupal világában az azt hihetné, hogy a konfiguráció az az a dolog ami környezetről környezetre változik. Ez az ami más a dev, test és live környezetekben. Nagy meglepetésben lesz része, hisz a konfiguráció a Drupalban az azok a beállítások, amik megegyeznek minden egyes környezetben. A konfigurációba vezetik ki a Drupalban az adatbáziban található olyan beállítások amik igazából a kódban kéne lenniük. Hogy teljes legyen a kavar igazából nem is nagyon vannak szétválasztva azok a beállítások amik környezetről környezetre változnak és azok amik nem, mivel nem is lehet azokat, hisz ez igazából a felhasználástól függ majd. Hetes Drupal még olyan vicces volt, hogy ezeket az adatokat a variable táblában tárolta, amiket aztán a $conf tömbben lehetett elérni és általában a settings.php-ban rendelt hozzá alapértelmezett értéket az ember. Szóval teljes volt a kavar, ami a nyolcasra sokat tisztult. Jelenleg ezek az adatok a config táblában találhatóak, a \Drupal::config ahol el lehet érni ezeket és a settings.php-ban a $config tömb segítségével tudjuk kódba helyezni, vagyis bedrótozni az értéküket.
Legyen szó hetesről, vagy nyolcasról a kiindulás a settings.php lesz majd számunkra és a $conf vagy $config tömb. Mielőtt továbbmennénk kell azonban egy kis kitérőt tennünk a Drupal multisite megoldása miatt.
Maga a Drupal egy, a maga idejében nagyszerű és egyedülálló megoldással rendelkezett, ha egy kódbázissal szerettünk volna több oldalt kiszolgálni, vagy eltérő konfigurációt szerettünk volna használni a dev, teszt és éles rendszereken. 2006-ban beszéltem erről az első Magyarországi Drupal konferencián, aminek az anyagai sajnos ma már nem elérhetőek. Ez a rendszer azt tudja megoldani, hogy a lekért domain-től függően más és más settings.php-t olvas fel így téve egyszerűvé a fenti megvalósítást. Ez ma már ideje múlt és túlhaladott megoldás. Ma már a nem javasolt kategóriában van nálam is.
A javaslatom az, hogy legyen egy darab settings.php fájlunk, amiben környezetenként módosítható beállításokat környezeti változókból szedjük. Valahogy így:
- $config['system.performance']['css']['preprocess'] = getenv('DRUPAL_SYSTEM_PERFORMANCE_CSS_PREPROCESS') ?: 1;
Ez lehetővé teszi számunkra, hogy a docker environment beállítások segítségével környezetenként tudjuk ezt az értéket állítani. Így kell majd kivezetnünk az S3FS modul és az SMTP modul beállításait, valamint minden olyan beállítást, amit szeretnénk környezetfüggően más és más értékre állítani.
Modulok
Van egy fontos lépés még, hogy minden flottul menjen. A fenti beállítások mit sem érnek majd, ha az S3FS és SMTP modulok nincsenek bekapcsolva. Ezt a Drupalban csak az adatbázisban fogjuk tudni majd állítani, vagy készítenünk kell egy profilt vagy disztribúciót, ami ezeket a modulokat alapesetben bekapcsolja és nem is engedi majd kikapcsolni. Vagy követjük a könnyebb utat és reménykedünk abban, hogy senki nem fogja ezeket kikapcsolni "Mert miért is tenne ilyet valaki?", hogy egy híres utolsó mondatot idézzek.
Kiegészítő modulok
A fenti leírás csak az alaprendszerre vonatkozott, annak is az általam leggyakrabban használt nehézségeivel foglalkozik. Minden egyes modulnál meg kell majd vizsgálnunk azt, hogy a fentiek közül milyen szolgáltatást és hogyan használ, vagy van-e esetleg valami olyan plusz beállítás, aminél problémát jelent majd az egymással párhuzamosan futtatott konténerhalmaz.
Ha arra vagy kíváncsi, hogy hogyan állíts fel könnyedén, gyorsan és fájdalommentesen fejlesztői környezeteket, akkor gyere és hallgasd meg a Konténerizált Fejlesztői Környezet kialakítása workshopomat.
Címkék: Planet Drupal.hudrupalDocker
