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?
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?