Composer helyes használata Dockerrel

A Composer a PHP függőségkezelője, ami szintén PHP nyelven lett megírva, és jellemzően egy composer.phar nevű fájl telepítésével használjuk a projekt gyökeréből vagy rendszermappából. Éles környezetben nem szükséges a webszerveren lennie, csak a függőségek letöltéséhez szükséges. De akkor miért is kérdés egyáltalán a Dockerrel használata? Ha tovább olvasod a cikket, hamarosan megtudod.

• Környezet, mint függőség
• Futtatás a PHP alkalmazáséval egyenértékű konténerben
  • A hivatalos Composer image használatával
  • Az alkalmazás fejlesztői image-ből indított konténerében
    
  • A fejlesztői image-ből indított külön konténerben
  • A fejlesztői image-en alapuló konténerben
• Összefoglalás

Környezet, mint függőség

[Tartalom]

Egy PHP alkalmazásnak lehetnek függőségei más PHP alkalmazások, mint osztálykönyvtárak, vagy akár program modulok, de ezen kívül nyilván az egész magától a PHP értelmezőtől is függ. Annak verziójától, illetve telepített kiterjesztéseitől. A Composer programot tehát a lehető leghasonlóbb környezetben kell futtatni, amilyenben majd a PHP alkalmazás élesben is működni fog, mert a Composer így tudja figyelembe venni az alkalmazás igényeit, és figyelmeztetni, ha valami hiányzik. Ha egy modulnak függősége egy újabb PHP verzió, akkor azt a csomagot nem fogod tudni letölteni, ami úgysem működne adott verzióval. Ha viszont eltérő PHP-val dolgozol a Composer használatakor, mint ami az alkalmazásod konténerében lenne, akkor végül a weboldal nem fog működni, vagy olyan hibákat produkál majd, amit nem értesz.

Olyan is előfordulhat, hogy valamit a Composerhez használt PHP-val nem tudsz telepíteni, mert ott hiányoznak kiterjesztések, vagy nem megfelelő a verzió. Igaz, hogy lehetne használni az "‑‑ignore‑platform‑reqs" opciót, ezt viszont nem javaslom, mert ilyenkor pont azt fogja figyelmen kívül hagyni, ami befolyásolja, hogy milyen csomagok lesznek telepítve.

Futtatás a PHP alkalmazáséval egyenértékű konténerben

[Tartalom]

Abban tehát már megegyezhetünk, hogy konténerben kell futtatni a Composert, hiszen a PHP program is konténerben fog működni, de még ekkor is több lehetőség közül lehetne választani. Ismét hangsúlyozom, hogy a cél a PHP alkalmazás konténeréhez leghasonlóbb konténert tenni a Composer alá. Ez nem jelenti azt, hogy teljesen megegyezőnek kell lenniük, tehát nem muszáj ugyanabban a konténerben sem futtatni, de akár azt is lehet. Most pedig nézzük a lehetőségeket.

A hivatalos Composer image használatával

[Tartalom]

Nagyon jó dolog, hogy a Docker Hub-on több eszköz már hivatalos image-ből is elérhető, de a hivatalos forrás ebben az esetben nem jó választás. Még ha meg is tudnád választani a PHP verziót a Composer alatt, amit jelenleg nem tudsz, akkor is külön bele kellene telepíteni minden PHP kiterjesztést, ami a programodnak szükséges.

Ez vagy dupla konfigurációt, illetve telepítést jelentene, vagy pedig egy telepítő szkript letöltését mindkét image elkészítésénél. Ám ne felejtsük el, hogy a image-ekben levő Linux disztribúció sem feltétlenül lesz azonos. Az egyik lehet Alpine Linux, a másik pedig Debian alapú, tehát a közös telepítő nem működik.

Egyik előnye azonban ennek az image-nek, hogy a Composer futtatásához megteremti a szükséges feltételeket, és tulajdonképpen ez a Docker célja.

A hivatalos image tehát már tartalmazza azokat a programokat, amiket a Composerrel általában használni szoktunk. Ilyenek például a verziókezelő kliensek, valamint az SSH kliens. Ezzel tehát nem kellene bajlódni már, ugyanakkor az sem biztos, hogy a programhoz szükséged van Mercurial vagy Subversion kliensekre, de akár az SSH is opcionális lehet, bár javasolt.

Nem utolsósorban a PHP memória limit is ki van kapcsolva ebben az image-ben, ami lényeges, mert a Composer ma már akár másfél giga memóriát is igényelhet. Szomorú, de ez van, el kell fogadni és élvezni az előnyöket.

Az alkalmazás fejlesztői image-ből indított konténerében

[Tartalom]

A legbiztosabb módja annak, hogy a Composer és a PHP alkalmazás ugyanolyan konténerben fussanak, ha ugyanabban a konténerben futnak. Ez igaz, viszont a Composer-nek és a PHP alkalmazásnak eltérőek lesznek az igényei. Egy részt bele kellene telepítened az alkalmazás mellé például a Git-et és SSH-t, amire nem biztos, hogy szüksége van, bár a dev és a production verziók ennyiben eltérhetnek egymástól. Más részt nem feltétlenül adnál másfél gigánál több memóriát neki, végtelent pedig semmiképp. Ha mégis emellett döntesz, akkor van néhány módszer, amit érdemes követni.

Ahogy azt írtam, nem muszáj teljesen megegyezni a prod és dev image-nek. A különbséget nyilván minimumon kell tartani, de production-szerű környezetben is tesztelni kell a programot, tehát, ha valami valószínűtlen hiba miatt fejlesztői módban jobban működne a program, mint élesben, az legkésőbb akkor kiderül. Viszont felesleges programokkal teleszórni egy Docker image-et megint csak nem tanácsos. Ezt a kis különbséget pedig a development és production image között két módon lehetne leírni:

• Örökléssel: A fejlesztői image leírható egy új Dockerfile-ban, amiben a FROM kulcsszó után az élesnek szánt image áll, tehát mindent tartalmaz, amit az élesnek kell, de beletelepíthetsz további programokat. Így például a Composert, Git-et, SSH-t és XDebug-ot is. Ezzel az a probléma, hogy fejlesztés közben az eredetileg élesnek szánt verzió is változhat, és nem örököltethetsz egy korábbi verzióból, illetve az sem igazán kényelmes, ha menet közben újabb és újabb dev image-eket hozol létre és töltesz fel egy regsitry-be. Ha előnyt kellene mondanom, az talán az, hogy ha egyszer működött az image, akkor másnak, másnap vagy máshol is működni fog. Igen, mert van, amikor ez nem garantált.

• Paraméterezett build-del: A Dockerfile tartalmazhat "ARG" kulcsszavakat is. Ezek hasonlók az "ENV"-hez, amik a futó konténerben hoznak létre környezeti változót, viszont build időben fognak létezni, tehát eltérő image-et is lehet készíteni ugyanazzal a Dockerfile-lal. Ezt a build parancsnak a "‑‑build‑arg" opcióval lehet átadni. Így nem kell duplikálni a fájl tartalmát, vagy kitenni shell szkriptbe, ami a rétegek kezelését nehezítené meg. Közben pedig egy vagy több eltérés is megoldható például egy BUILD_ENV nevű argumentummal. Az értékek akár lehetnek dev, composer és prod, ahol a composer megegyezhet a dev-vel leszámítva, hogy van benne Composer is. De akár külön argumentum is jelezheti, hogy szükség van-e rá vagy sem. Ha ezt a megoldást választod, a fejlesztői image akár csak lokálisan is létezhet, nem muszáj feltölteni egy központi tárolóba. Megeshet, hogy egy új gépen is le kell futtatni a fejlesztői build-et. Ha van olyan nélkülözhetetlen fejlesztői eszköz, aminek fennáll az esélye, hogy egy újabb build-nél hibásan fut le valamilyen külső függés miatt, és ennek javítása a még elfogadhatónál több időt vehet igénybe, akkor azért érdemes mégis tartani ebből is egy távoli image-et. Viszont, mivel nem készíthetsz új build-et, változtatni sem tudsz rajta, ami azért felvethet némi problémát a fejlesztésnél. Ilyenkor maximum a konténerben telepíthetsz és elmentheted a "docker commit" utasítással.

Példát a paraméterekre mutatok, mert az öröklést talán nem kell magyarázni, az utasítások pedig a feltételt leszámítva ugyanazok. Az alábbi részlettel a Dockerfile-ból igyekszem a lényeget mutatni.

Látható, hogy

• Két argumentumot is felvettem.

  • A BUILD_ENV értéke alapból "prod", de ha "dev"-re állítom, települhetnek a fejlesztéshez szükséges eszközök.

  • A COMPOSER_VERSION tartalmazza a telepítendő Composer verzióját. Fontos, hogy fix verzió legyen telepítve, mert szeretnénk, ha minél kevesebb meglepetés érne minket, igaz?

• A GitHub-ról egy egészen konkrét Composer telepítő szkript töltődik le a commit hash-re hivatkozva, hogy még a telepítő különbsége se okozzon problémát az újabb buildeknél.

• Vannak változók definiálva az XDebug konfigurációjához. Az xdebug.ini-be nem a változók értéke kerül, hanem maga a változó. Ezért a backslash a dollár előtt. Tehát a konténer indításakor változtathatók a paraméterek. Észre kell venni, hogy ezzel a módszerrel az éles image-ben is benne lesznek az XDebug változók, de nem lesz semmilyen hatásuk. Ha a felesleges változók zavarnak, akkor muszáj külön fájlban leírni a fejlesztői módot, vagy argumentumként is felveheted a változókat, és más módon kell gondoskodnod róla, hogy a PHP számára elérhetők legyenek alapértékeikkel. Például egy egyedi indító szkript létrehozásával, amiben definiálva vannak a változók.

• Feltűnhetett, hogy memórialimitet nem állítottam be globálisan, de van egy COMPOSER_MEMORY_LIMIT változó, ami a Composer 1.6.0 óta használható a memória limit növelésére, és értelemszerűen nincs hatással a teljes alkalmazás korlátaira. Persze, ha a weblapnak van szüksége fejlesztői módban több memóriára, akkor azt is módosítani kell.

Muszáj megemlítenem, hogy pecl programmal 7.0-nál régebbi PHP-hez nem lehet telepíteni az XDebug-ot. Az elv akkor is ugyanez, csak más a módszer.

Ezt kellene tehát az előző részben már elkészített projektbe implementálni. Először is másold a teljes projekt mappát egy új "composer" nevű mappába. Az eredetit is lehet módosítani. Így viszont utólag látod a különbségeket.

Az új php.Dockerfile tehát a következő lesz:

A docker-compose.yml pedig annyiban változik, hogy be kell állítani a build argumentumokat. Legalábbis a BUILD_ENV-et. Ezen kívül viszont a használt httpd image verzióját is megváltoztatom, mert időközben elkészült a 2.0. Nem kompatibilis teljesen a régivel, de ebben a példában nyugodtan át lehet írni az 1.1-es verziót 2.0-ra. Nincs különbség. Vagyis a következő lesz az eredmény:

Ezt máris el lehet indítani

Majd pedig a composer is futtatható

Ha a konténer felhasználóját az alapértelmezett root-on hagytad, ezen a ponton akkor is megadhatod, hogy a composer kinek a nevében fusson:

Arra viszont figyelj, hogy ha véletlenül sikerült a root nevében indítani korábban a composer parancsot, létrehozta a tmp könyvtárban a cache mappát, amit a már helyes userrel nem fogsz tudni írni, ezért azt előtte törölni kell. Ez már alakul. Ha pedig mégis változtatni kell a memórialimiten, akkor azt is megteheted a változó felülírásával:

A fejlesztői image-ből indított külön konténerben

[Tartalom]

Ebben az esetben nincs szükség fejlesztés közben külön Composer image-re. A fejlesztői image már tartalmazni fogja a Composer függőségeit, viszont a Composerből gyakorlatilag tetszőleges verziót lehet használni. Minden verzió külön volume-ra töltődhet le, ha még nincs, ahol a volume-ot a verziószámmal és a felhasználói, valamint csoportazonosítóval különböztetjük meg, így a jogosultsággal sem lesz gond és bármilyen projektben újrahasznosítható. Van lehetőség arra, hogy a gazda rendszer hálózatában futtasd, így a gazdán működő SSH tunnel + hosts fájl módosítása is működik például otthoni munka esetén a munkahelyi hálózatban levő GIT és/vagy Composer szerver elérésével. Ezt egy jó kompromisszumnak gondolom a teljesen külön image és az alkalmazás konténerében futtatás között. Ehhez az alábbi fájlokat kell hozzáadni a projekthez:

• docker-compose.composer.yml: A composer konténer extra paramétereit tartalmazza, mint a host network használatát.

• composer.sh: Shell script, ami letölti a választott composer verzióját volume-ra, majd futtatja is.

docker-compose.composer.yml

composer.sh

Futtatási jogot kell adni a composer.sh-nak, majd szinte ugyanúgy használható, mint egy hagyományos verzió.

./composer.sh --version

A shell szkriptben a "run" függvényben lehet a COMPOSER_VERSION változót módosítani, amit a konténernek is át fog adni. Arról is gondoskodik, hogy minden felhasználónak minden Composer verzió külön volume-ra legyen mentve. Ha valamelyik verzió letöltése közben hiba történik, akkor szükség lehet a volume manuális törlésére, majd a szkript újra futtatására, de egyébként bármikor, bármelyik verzió újra felcsatolható bármelyik projektbe. Hiba például lehet olyan, hogy nem létezik a megadott Composer verzió, vagy csak hálózati hiba miatt nem érhető el. Hibaüzenet viszont a telepítésről nem fog megjelenni, mert a kimenet a /dev/null-ba van irányítva. A composer viszont nem lesz a keresett helyén, ezért annak a hiányára utaló hibaüzenetből sejthető, hogy a letöltés nem sikerült. Ilyenkor ideiglenesen lehet próbálkozni a kimenet átirányítás megszüntetésével. A törlendő volume neve pedig az alábbiak szerint áll össze:

Ahol a VOLUME_PREFIX alapértelmezetten "composer_version". Tehát az összes composer verzió listázható az alábbi módon:

A "kalap" jel (^) nem fontos. Így viszont csak azokat mutatja meg, amik ténylegesen a "composer_version"-nel kezdődnek, nem csak tartalmazzák. A kimenet valami ilyesmi lesz:

Látható, hogy én is próbálkoztam két, jelenleg nem létező Composer verzióval. A composer.sh-t is elmentheted a verziókezelőbe, így továbbra is látszik, ha valamiért a Composer verzióján változtatni kellett.

A fejlesztői image-en alapuló konténerben

[Tartalom]

Abban az esetben, ha a fejlesztői image-be nem szeretnél kizárólag a Composer számára szükséges függőségeket telepíteni, készíthetsz egyedi image-et, aminek ugyanaz a módja, mint a development és production image közötti különbségek definiálásának. Örököltethetsz tehát a fejlesztői image-ből kiegészítve a Composerrel, vagy az "ARG" kulcsszó segítségével egy külön verziót készítesz. Én viszont elkerülném a túl sokféle image készítését, ha nincs különösebb igény rá.

Ráadásul, ha a Composernek saját image-e van, akkor a Docker Compose-zal készített image nevére is figyelni kell, hogy ne egyezzen meg a PHP service image-ének nevével, de mégis egyedi legyen projektenként. Ezt persze akár egy docker-compose override.yml -ben is meg lehet adni, vagy a szkript is kiokosítható szükség esetén.

Összefoglalás

[Tartalom]

A Composer használatának tehát több módja, ami nem is feltétlenül limitált azokra, amiket én a cikkben említettem. Összességében az mégis elmondható, hogy törekszünk arra, hogy ne nagyon különbözzön az alkalmazás környezete attól, ahol a fejlesztés közben a Composert futtatjuk. Ez később akár a CI/CD-re, azaz az automatizálásra is kiterjeszthető. Ennek az egyszerű igénynek a következménye minden egyéb. Az új verziókat már egyszerűbb futtatni konténerben is. Ez egy újabb ösztönző erő lehet ara, hogy próbálj frissíteni és újabb eszközöket használni, amennyiben lehetséges.

Ha hibát találtál a cikkben, kérlek oszd meg velem, vagy akár mindenkivel kommentben. Ha van jobb ötleted, javaslatod a Composer használatára, vagy éppen nem fedtem le egy problémát, arról is szívesen olvasnék.