PHP mit einem Apache oder einem nginx zu nutzen ist inzwischen kein Hexenwerk mehr. \u00dcberall im Netz findet man haufenweise Konfigurationsbeispiele, die mehr oder minder formal beschreiben, warum man diesen oder jenen Voodoo treiben muss. Was aber scheinbar niemand wirklich erkl\u00e4rt, ist ein kleines, aber essentielles Detail, was einem einiges an Resourcen spart, wenn man \u00fcber mehrere Container hinweg seine Services isolieren m\u00f6chte.<\/p>\n
Das \u00fcbliche Setup sieht in dieser Umgebung so aus, dass man einen zentralen Server – aus Performance-Gr\u00fcnden meist etwas Performantes wie nginx – auf einem Container installiert, und von diesem via Reverse Proxy die Anfragen zu seinem eigentlichen Service weiterleitet. Der Webservice hat in diesem Setup wiederum einen Webserver laufen, der die Anfragen verarbeitet und an PHP durchreicht.<\/p>\n
Einfach. Langweilig. Und Bloated!<\/p>\n
Denn warum eigentlich den zweiten Webserver? nginx kann doch schon direkt FastCGI sprechen; da brauch man doch keinen eigenen Server, dessen einzige Aufgabe es ist – neben Taktzyklen verbrennen -, die Anfragen von A nach B durchzureichen.<\/p>\n
Gesagt, getan und auf einer meiner Service-Maschinen lediglich den PHP-FPM f\u00fcr die Verarbeitung der Anfragen aufgesetzt. Diesen im Pool auf’s LAN-Interface der Bridge geklemmt (mit Firewalling gegen das b\u00f6se Internet gesch\u00fctzt) und als erlaubten Client den Proxy eingetragen. Einmal Service neustarten und der PHP-FPM l\u00e4uft.<\/p>\n
Was jetzt noch fehlt, ist der grandios undokumentierte Teil der Aufgabe: Wie bekommt der PHP-FPM seine Requests vom nginx? Und vor allem: Woher wei\u00df er, welches Skript auszuf\u00fchren ist?<\/p>\n
Nunja, anhand der Konfiguration des nginx nat\u00fcrlich! In dieser gibt es \u00fcblicherweise eine Reihe Konfigurationszeilen mit fastcgi_param zum verdrehen diverse Einstellungen und zur \u00dcbergabe so manch sinnvoller Information wie der verwendeten Server-Software \ud83d\ude09 Unter anderem bietet der nginx hierbei auch einen Wert mit dem unscheinbaren Namen „SCRIPT_FILENAME“ (nicht verwechseln mit dem „SCRIPT_NAME“!!!), welcher 1:1 vom PHP-FPM hinter dem konfigurierten TCP-Socket ausgef\u00fchrt wird. Der hier angegebene Dateiname bezieht sich auf das von PHP-FPM gesehene Dateisystem; inkluse ggf. vorhandener chroot-Umgebungen.<\/p>\n
Soweit so einfach, ABER: Da der nginx in diesem Setup keine Dateien der Webanwendung kennt, m\u00fcssen ALLE Anfragen \u00fcber den PHP-FPM laufen (ja, selbst das Ausliefern von Bildern muss via PHP gemacht werden). Da in diesem Setup auch die G\u00fcltigkeitspr\u00fcfung der Dateinamen erst vom angeh\u00e4ngten Webservice erfolgen kann, ist dieser f\u00fcr die korrekte Beantwortung verantwortlich.<\/p>\n
Im besten Falle hat man also eine Anwendung, die sowieso Single Entry Point l\u00e4uft und daher alles direkt erledigen kann. Dann vereinfacht sich die Server-Konfiguration auf folgende wenige Zeilen:<\/p>\n
\r\nlocation \/ {\r\n # regex to split $uri to $fastcgi_script_name and $fastcgi_path\r\n fastcgi_split_path_info ^(.+\\.php)(\/.+)$;\r\n\r\n fastcgi_index index.php;\r\n fastcgi_pass 12.34.56.78:9000;\r\n include fastcgi_params;\r\n fastcgi_param SCRIPT_FILENAME \/srv\/webapp\/index.php;\r\n fastcgi_param SCRIPT_NAME $fastcgi_script_name;\r\n}\r\n<\/pre>\nDanach auch dem nginx einen kurzen Tritt geben, damit er die Konfig neu liest und der schlank aufgesetzte Webservice ist verf\u00fcgbar. Die \u00fcblichen Ma\u00dfnahmen zur Absicherung von PHP-Installationen gelten nat\u00fcrlich uneingeschr\u00e4nkt.<\/p>\n
![\"Flattr](\"http:\/\/blog.benny-baumann.de\/wp-content\/plugins\/flattr\/img\/flattr-badge-large.png\"){kind=icon}
<\/a><\/p>","protected":false},"excerpt":{"rendered":"