Drush (composer) támogatás?

[Endyl]

Úgy látom, hogy a hivatalos docker drupal alapján készült a docker setup, ami csak letölt egy adott verziójú drupal kiadást.

Ezzel csak annyi a probléma, hogy mivel 8.5.5 verzióval indulunk, így kizárjuk magunkat a Drupal parancssoros felületének a használatából (és sok automatizálási lehetőségből), mert a Drupal 8.4+ verzióját már csak a 9-es Drush támogatja, aminek a telepítéséhez viszont -ahogy az oldal elején írják- a Drupalt is composerrel kell telepíteni.

Találtam egy írást, ami szintén a fenti docker drupal repót veszi alapul, de végül composerrel telepíti a Drupalt a Drush oldalán is javasolt composeres setup segítségével.

Szerintem mi is csinálhatnánk hasonló módon, de ha már úgysem közvetlenül használjuk a docker repót, akkor például ki lehetne gyomlálni belőle a felesleges drupal kiadás letöltést, illetve beszervezni a composeres telepítést a Dockerfile-ba (ha nem robbantja fel a layer cache-t).

Mit gondoltok?

[hunsly]

Én is észrevettem, hogy nincs Drush, ezért profile-al kezdtem megoldani. 4a76637

[Pepita73]

Elsőre én nem is találtam composeres telepítőt hozzá, úgyhogy mindenképp hasznosak a linkek. Kérdés az, hogy mennyi fejlesztési időt ér meg nekünk, amit nyerünk vele. Ismét hétvégén tudok pár órát rászánni. Jelenlegi konténerben szerintem composer sincs (ha csak a forrás php:7.2-apache nem tartalmazza alapból), és biztosan nem 5 perc, viszont ha fontos feature így kimarad, akkor jobb lenne az elején rendezni.

[Endyl]

Ilyen struktúrát generál a composeres megoldás. Van erre valakinek valamilyen értelmes COPY/volume layer ötlete?

A composer install-hoz szükség van ugyebár a composer.json és a composer.lock fájlokra, illetve a src/scripts tartalmára. Utána legenerálja gist-ben lévő install-generated-files.txt szerinti struktúrát.

Egyelőre eddig jutottam.

[Endyl]

Körbejárva a dolgot arra jutottam, mint a fenti cikk. Nincs értelme a Dockerfile-ban futtatni a composer install-t (úgy, hogy külön layer legyen belőle) és az egész src-t kéne mountolni.

Már csak azt nem tudom, hogy az entrypointot megcsináljuk-e úgy, hogy container indulásnál lefusson a composer install, vagy fapadosan, manuálisan kelljen megcsinálni egyelőre?

[Pepita73]

az entrypointot megcsináljuk-e úgy

composer install szerintem csak container create - nél kell, tehát egy RUN sor a Dockerfile-ban.

Emellett jó lenne egy composer update minden indulásnál (composer.json és / vagy composer.lock változott). Erre egyelőre nincs konkrét ötletem, de hétvégén végigmegyek ezen a linkeden én is. Így első olvasatra nem vagyok meggyőződve arról, hogy "Nincs értelme a Dockerfile-ban futtatni a composer install-t". De ki is kell próbáljam. Úgy tűnik, ő a Drupal forrását is verzióköveti, ami nekem nem tetszik. Viszont lehet benne pár jó ötlet.

@Endyl , lesz ebből PR-ed, vagy használjam fel a hasznos infóid és én csináljam? Szerintem jobb vonal a composer, ezért ez egy issue. :)

[Endyl]

Csináltam egy composeres setupot a forkomban a fork/i_1_composer branchben.

Egyszer szükség van erre:

docker exec -it drupal-apache sh -c "composer install"

miután elindultak a containerek (meg előtte a hálózatot még ugye be kell állítani, vagy megnézni a db IP-címét, mert az még #2-re vár).

Aztán mehet a telepítés :)

Ha ez bemerge-ölődik, az megoldja #5-öt is, aztán kitalálhatunk esetleg valami jobb megoldást is a volume-okra, meg rendezhetjük a settings fájlokat, stb. :)

Edit 1: A Drupal és a contrib modulok forrása amúgy nincs gitben; van benne egy .gitignore, ami kiszed mindent, amit a composer tud telepíteni/létrehozni.

[Pepita73]

docker exec -it drupal-apache sh -c "composer install"

Ezt nem lehet a Dockerfile végére betenni? Mert ott már van oprendszer, php, apache. Mivel csak egyszer kell, ott lenne a helye, mert csak container create-kor fut.

update: még eszembe jutott, hogy ha nem lehet a containerben, akkor esetleg meg lehet állapodni, hogy git bash-t használunk, ehhez lehet írni egy install scriptet, ami elindítja a docker cuccost is és utána a composer-t. Így is használtuk már, csak sajnos arra már nem látok rá. A lényeg az lenne, hogy 1, max 2 egyszerű paranccsal felálljon a dev környezet.

[Pepita73]

Egyébként ránézésre nekem tökre tetszik. :) Jó lenne mielőbb merge, holnap vagy vasárnap akkor elvinném #2 és a volume gondot, ha még fennáll a "jogi vita" (= írási jog).

[Endyl]

Mecsináltam a PR-t; jelenleg a környezet feláll két paranccsal (amiből az egyikre csak clone, vagy a composer fájljainak a módosítása után van szükség).

Az a probléma a composeres telepítésnek a docker image-be mozgatásával, hogy akkor a composerrel kapcsolatos műveletek (frissítés, új modul kipróbálása, stb) az image újraépítését tehetik szükségessé. Illetve nem tudom, hogy a volume-ok ebben a felállásban hogyan működnének.

Persze idővel lehet írni utility szkripteket, ha bonyolódnának a dolgok. Ekkor tényleg hasznos lenne, ha csak bash szkripteket kéne fenntartani és nem kéne PowerShell szkripteket is szinkronban tartani velük.

[Pepita73]

@Endyl , részemről tetszik, kipróbálnátok @inf3rno val merge-ölést? (Szeretném, ha nélkülem is megoldott lenne.) Most van egy kis dolgom, utána ebből kiindulva intézem a volume / db links dolgot. Közben agyalok a composer install / update dolgon is, hogy lehetne a legkényelmesebb. Szerintem az első (install) bemehet a konténer gyártásba, ez nem zárja ki a különálló (pl PowerShell) futtatását.