Docker Nginx en PHP-FPM: tesamen in 1 container?

[egonolieux]

Ik heb een Symfony 4 app die ik naar Docker aan het migreren ben (Symfony 2 of 3 is evengoed van toepassing voor dit topic). Volgens de filosofie van containers is het wenselijk 1 proces per container te draaien; Nginx en PHP-FPM elk in zijn eigen container dus. Dit klinkt allemaal goed in theorie, maar in de praktijk lijkt dit niet zo eenvoudig.

In de context van dit topic spreek ik over een production environment waarin de complete source van het project in de PHP-FPM image ingebakken zit. Binnen deze PHP-FPM image bevat de document root (de `/public` directory) meerdere bestanden zoals `index.php`, `robots.txt`, en `manifest.json`. Daarnaast worden een aantal assets automatisch gegenereerd door Symfony zelf in `/public/bundles`. Ook genereer ik zelf een aantal bestanden in de `/public` directory, zoals o.a. XML sitemaps.

Deze bestanden binnen de document root (behalve `index.php`) horen eigenlijk uitsluitend door de Nginx container als statische bestanden aangeboden te worden. Het probleem is dat vele van deze bestanden afhankelijk zijn van de PHP-FPM container om gegenereerd te worden. Een mogelijke oplossing zou het gebruiken van een gedeeld volume zijn tussen de Nginx en PHP-FPM containers, maar ook hier zijn een aantal problemen aan verbonden:

Als Docker het volume voor het eerst aanmaakt, zullen de bestanden uit `/public` gebruikt/gekopieerd worden. Maar wat als `manifest.json` of dergelijke bestanden in broncode van de PHP-FPM image gewijzigd worden? Omdat het volume bovenop de `/public` directory gemount is en reeds bestanden bevat, zal steeds de oude `manifest.json` uit het Docker volume gebruikt worden. Bestaat er misschien een mogelijkheid dit volume tijdelijk te maken zodat het altijd verwijderd wordt na het stoppen van de container om rond dit probleem te werken?

De volgende bedenking dit ik heb, is wat als er meerdere PHP-FPM containers draaien achter een enkele loadbalanced Nginx container? De PHP-FPM containers die willekeurig het gedeelde volume overschrijven bij het genereren van sitemaps of de Symfony bundles lijken me ook niet een ideaal scenario.

Ik kan niet anders dan tot de conclusie komen dat Nginx en PHP-FPM tesamen in één container draaien met supervisord al deze problemen direct oplost. Het enige niet onmiddellijke probleem lijkt me dan wel het horizontaal schalen met meerdere aparte PHP-FPM containers.

Misschien een wat ongerelateerde vraag i.v.m. het horizontaal schalen van PHP:
Waarom zou je meerdere PHP-FPM containers achter Nginx draaien i.p.v. gewoonweg het aantal PHP-FPM workers te verhogen, als de containers allemaal op dezelfde host draaien?

[MBicknese]

Schaalbaarheid en rolling updates in acht genomen denk ik dat je best oplossing multistage builds zijn. In stage1 kan je een PHP image pakken en de build stappen die je moet doen om je code productie klaar te kriijgen. Vervolgens kan je een stage draaien om een NGINX image te bouwen, deze hoeft alleen de statische bestanden over te hevelen. Tot slot stage3 gaat of verder met de stage1 PHP image of met een schone PHP image waar je de php bestanden aan toe voegt en de configuratie goed zet om PHP-FPM te draaien.

Zo kan je naar hartelust PHP en NGINX containers bijschalen. En wanneer je wilt updaten kan je veilig containers omzetten zonder downtime.


Betreft het horizontaal schalen. Ik zie twee voordelen. De eerste is dat mocht een van de workers onverhoopt je container om zeep helpen, dan gaan de andere containers gewoon door. De andere, waarschijnlijk meer toepasselijke reden, als je PHP-FPM (in config) veel resources toe kent. Dan kan je je resource management naar Docker verplaatsen. Waardoor je in runtime RAM en CPU kan optimalizeren, wat waarschijnlijk ook fijner gaat zijn tussen je OTAP omgevingen.

[egonolieux]

Schaalbaarheid en rolling updates in acht genomen denk ik dat je best oplossing multistage builds zijn. In stage1 kan je een PHP image pakken en de build stappen die je moet doen om je code productie klaar te kriijgen. Vervolgens kan je een stage draaien om een NGINX image te bouwen, deze hoeft alleen de statische bestanden over te hevelen. Tot slot stage3 gaat of verder met de stage1 PHP image of met een schone PHP image waar je de php bestanden aan toe voegt en de configuratie goed zet om PHP-FPM te draaien.

Dat zou inderdaad het ideale scenario zijn, maar het probleem is dat de bestanden die gegenereerd moeten worden met PHP afhankelijk zijn van runtime environment variables. Momenteel draai ik de PHP scripts in een startup shellscript. Misschien dat ik met de dotenv component van Symfony wel wat kan forceren door simpelweg ".env.dist" naar ".env" te kopieren tijdens de build, maar dat is afhankelijk van de mate waarin Symfony effectief deze environment variables gebruikt. Voordat je de Symfony console kan gebruiken, moeten alle environment variables beschikbaar zijn, maar ik denk dat hooguit "APP_ENV" gebruikt wordt (development of production) en dat de rest gewoon genegeerd wordt.

Hoe dan ook blijft de vraag wat er met de sitemaps moet gebeuren. Deze worden elke dag opnieuw gegenereerd door PHP en moeten binnen de Nginx container zien te belanden. Als ik de sitemap moet overzetten, kan ik evengoed de andere bestanden ook overzetten i.p.v. bovenstaand scenario uit te proberen. De vraag blijft wat hier de meest geschikte manier voor is. Zoals ik eerder al heb vermeld, is een volume bovenop de document root (/public) mounten problematisch.

Zelf kan ik 2 mogelijke oplossingen bedenken: De gegenereerde bestanden (en elke dag de sitemap) overzetten naar de Nginx container met Rsync, of het volume in de PHP-FPM container "naast" de document root mounten (/public2 bijvoorbeeld), en de bestanden uit /public telkens kopieren naar /public2. Hoe zou ik dit het best aanpakken?