Install and Configure Nginx #4

Closed
opened 2025-03-21 15:08:32 +01:00 by mrouissi · 4 comments
Owner

Install Nginx and configure it to serve the Symfony (?) application.

Install Nginx and configure it to serve the Symfony (?) application.
Author
Owner

Icha habe die Situation anlysiert, und der Wechsel von Apache zu Nginx auf diesem Server ist aus mehreren Gründen viel zu kompliziert:

  • Erstens ist die aktuelle Apache-Konfiguration stark angepasst mit mehreren virtuellen Hosts (000-default.conf, wf10501-live.conf usw.), WordPress-spezifischen Konfigurationen (wordpress-rewrites.conf) und einer Reihe von Modulen wie mod_php7.4, mod_rewrite und mpm_itk, die nicht direkt auf Nginx übertragbar sind. Das Umstellen dieser Konfigurationen in die Nginx-Syntax – Umwandlung von Rewrites in try_files, Austausch von mod_php gegen PHP-FPM und Neugestaltung der Benutzerisolierung – erfordert quasi manuellen Aufwand für jede Seite und Funktion...
  • Zweitens unterstützt Nginx keine .htaccess-Dateien, sodass WordPress-Permalinks und benutzerdefinierte Regeln fest in die Konfiguration eingebaut werden müssen, was zusätzliche Schritte bedeutet.
  • Drittens erfordert das Testen und Migrieren die Validierung jeder Seite, was den Arbeitsaufwand vervielfacht.

Wir sprechen von mindestens 20-30 Stunden Arbeit. Das sind 5-10 Stunden zum Umschreiben der Konfigurationen, 5-10 Stunden zum Einrichten und Optimieren von PHP-FPM (plus ein Upgrade von der veralteten PHP 7.4), und über 10 Stunden für Tests und Bereitstellung. Wenn etwas schiefgeht – wie bei einer benutzerdefinierten PHP-App oder einem SSL-Problem – könnten es leicht 40+ Stunden werden. Ohne eine klare Leistungskrise oder ein zwingendes Nginx-Feature ist das ein enormer Aufwand für fraglichen Nutzen.


@rkoerner - Wenn du andere Ideen oder Workarounds hast, lass es mich bitte wissen.

Icha habe die Situation anlysiert, und der Wechsel von Apache zu Nginx auf diesem Server ist aus mehreren Gründen viel zu kompliziert: - Erstens ist die aktuelle Apache-Konfiguration stark angepasst mit mehreren virtuellen Hosts (000-default.conf, wf10501-live.conf usw.), WordPress-spezifischen Konfigurationen (wordpress-rewrites.conf) und einer Reihe von Modulen wie mod_php7.4, mod_rewrite und mpm_itk, die nicht direkt auf Nginx übertragbar sind. Das Umstellen dieser Konfigurationen in die Nginx-Syntax – Umwandlung von Rewrites in try_files, Austausch von mod_php gegen PHP-FPM und Neugestaltung der Benutzerisolierung – erfordert quasi manuellen Aufwand für jede Seite und Funktion... - Zweitens unterstützt Nginx keine .htaccess-Dateien, sodass WordPress-Permalinks und benutzerdefinierte Regeln fest in die Konfiguration eingebaut werden müssen, was zusätzliche Schritte bedeutet. - Drittens erfordert das Testen und Migrieren die Validierung jeder Seite, was den Arbeitsaufwand vervielfacht. Wir sprechen von mindestens 20-30 Stunden Arbeit. Das sind 5-10 Stunden zum Umschreiben der Konfigurationen, 5-10 Stunden zum Einrichten und Optimieren von PHP-FPM (plus ein Upgrade von der veralteten PHP 7.4), und über 10 Stunden für Tests und Bereitstellung. Wenn etwas schiefgeht – wie bei einer benutzerdefinierten PHP-App oder einem SSL-Problem – könnten es leicht 40+ Stunden werden. Ohne eine klare Leistungskrise oder ein zwingendes Nginx-Feature ist das ein enormer Aufwand für fraglichen Nutzen. --- @rkoerner - Wenn du andere Ideen oder Workarounds hast, lass es mich bitte wissen.
Owner

Du siehst Probleme, wo es keine gibt. Und nein, es ist nicht kompliziert.
Du versuchst in den kleinsten Details eine alte Umgebung zu rekonstruieren, um sie danach mühevoll zu aktualisieren - das ist kompliziert und unnötig. Denke zielorientiert und hole dir aus dem alten nur das, was unbedingt benötigt wird.

Vom Webserver ist das lediglich die wf10501-stage.conf - das ist die alte Dev-Umgebung. Darin sind auch nur 5 Zeilen von besonderem Interesse: AssignUserId und 4x php_admin_value. Das sind alles EInstellungen, die beim nginx kaum relevant sind, da sie in den FPM-User-Pool wandern.

  1. es gibt kein Wordpress
  2. es gibt keine .htaccess im gesamten DocRoot und für alles gibt es auch eine entsprechende nginx-Lösung. .htaccess-Dateien werden übrigens auf keinem unserer Server beachtet, sie sind aus Performancegründen grundsätzlich deaktiviert (AllowOverride none).
  3. du brauchst dich im Prinzip um die alte Config überhaupt nicht zu kümmern. Setze einfach einen vHost für PHP(7.4) auf, mehr brauchst du in dem Fall nicht zu beachten. Die Redirects aus der wf10501-live.conf sind für den technischen Teil der Programmierung nicht relevant, das sind nur Umleitungen alter URLs.
  4. für die Rewrites/Redirects gibt es auch Converter im Netz, z.B. https://timmehosting.de/htaccess-converter (5min Copy&Paste)

Meine Dokumentation ist zwar dürftig, aber 95% sind für den Fall in 4 Anleitungen in der Nextcloud zu finden unter
bnet/Dokumentation/Software/nginx
01-php-fpm_base.txt
02-nginx_base.txt
03-php_fpm_userpool.txt
04-php_vhost.txt

Die restlichen 5% sind nicht relevant, um dein Ziel zu erreichen. Du darfst auch gern fragen, wenn etwas unklar ist.

Die Anleitungen hatte ich dir auch schon in der Mail zur Dev-VM letzte Woche genannt. Du sollst das ja nicht alles neu erfinden. Lesen, verstehen, ausführen, fertig. Bei Interesse kannst du dir noch das Ergebnis der einzelnen Befehle anschauen und ggf. zum Vergleich auch die Vorlagen. Verbessern und automatisieren ist im Moment nicht die Aufgabe.

Den Aufwand für alles zusammen sehe ich <2h. In der Zeit hab ich dir die 4 Anleitungen auch noch erklärt.
Das können wir morgen im Meeting gleich live gemeinsam erledigen.

  1. das Upgrade PHP7.4 auf 8.x ist noch gar nicht relevant und auch nur eine zusätzliche FPM-Instanz, d.h. die Anleitung 01 und 03 für die zusätzliche Version wiederholen und den vHost an einer Stelle ändern, damit er auf den anderen FPM zugreift.

Welche PHP- und SSL-Probleme willst du hier herbeireden, die du im Apache nicht hättest?
Das ist eine Dev-VM, die ist genau dazu da, die Probleme ohne Auswirkungen auf das Live-System zu beheben.

Das benötigte Feature (mehrere PHP-Versionen parallel auf einer VM) ist jetzt nicht nginx-spezifisch, aber durch den FPM und die Trennung von Webserver und PHP hat der Apache keinen Vorteil mehr, eher Nachteile.

Du siehst Probleme, wo es keine gibt. Und nein, es ist nicht kompliziert. Du versuchst in den kleinsten Details eine alte Umgebung zu rekonstruieren, um sie danach mühevoll zu aktualisieren - das ist kompliziert und unnötig. Denke zielorientiert und hole dir aus dem alten nur das, was unbedingt benötigt wird. Vom Webserver ist das lediglich die wf10501-stage.conf - das ist die alte Dev-Umgebung. Darin sind auch nur 5 Zeilen von besonderem Interesse: AssignUserId und 4x php_admin_value. Das sind alles EInstellungen, die beim nginx kaum relevant sind, da sie in den FPM-User-Pool wandern. 1. es gibt kein Wordpress 2. es gibt keine .htaccess im gesamten DocRoot und für alles gibt es auch eine entsprechende nginx-Lösung. .htaccess-Dateien werden übrigens auf keinem unserer Server beachtet, sie sind aus Performancegründen grundsätzlich deaktiviert (AllowOverride none). 3. du brauchst dich im Prinzip um die alte Config überhaupt nicht zu kümmern. Setze einfach einen vHost für PHP(7.4) auf, mehr brauchst du in dem Fall nicht zu beachten. Die Redirects aus der wf10501-live.conf sind für den technischen Teil der Programmierung nicht relevant, das sind nur Umleitungen alter URLs. 4. für die Rewrites/Redirects gibt es auch Converter im Netz, z.B. https://timmehosting.de/htaccess-converter (5min Copy&Paste) Meine Dokumentation ist zwar dürftig, aber 95% sind für den Fall in 4 Anleitungen in der Nextcloud zu finden unter bnet/Dokumentation/Software/nginx 01-php-fpm_base.txt 02-nginx_base.txt 03-php_fpm_userpool.txt 04-php_vhost.txt Die restlichen 5% sind nicht relevant, um dein Ziel zu erreichen. Du darfst auch gern fragen, wenn etwas unklar ist. Die Anleitungen hatte ich dir auch schon in der Mail zur Dev-VM letzte Woche genannt. Du sollst das ja nicht alles neu erfinden. Lesen, verstehen, ausführen, fertig. Bei Interesse kannst du dir noch das Ergebnis der einzelnen Befehle anschauen und ggf. zum Vergleich auch die Vorlagen. Verbessern und automatisieren ist im Moment nicht die Aufgabe. Den Aufwand für alles zusammen sehe ich <2h. In der Zeit hab ich dir die 4 Anleitungen auch noch erklärt. Das können wir morgen im Meeting gleich live gemeinsam erledigen. 5. das Upgrade PHP7.4 auf 8.x ist noch gar nicht relevant und auch nur eine zusätzliche FPM-Instanz, d.h. die Anleitung 01 und 03 für die zusätzliche Version wiederholen und den vHost an einer Stelle ändern, damit er auf den anderen FPM zugreift. Welche PHP- und SSL-Probleme willst du hier herbeireden, die du im Apache nicht hättest? Das ist eine Dev-VM, die ist genau dazu da, die Probleme ohne Auswirkungen auf das Live-System zu beheben. Das benötigte Feature (mehrere PHP-Versionen parallel auf einer VM) ist jetzt nicht nginx-spezifisch, aber durch den FPM und die Trennung von Webserver und PHP hat der Apache keinen Vorteil mehr, eher Nachteile.
Author
Owner

Du siehst Probleme, wo es keine gibt. Und nein, es ist nicht kompliziert.
Du versuchst in den kleinsten Details eine alte Umgebung zu rekonstruieren, um sie danach mühevoll zu aktualisieren - das ist kompliziert und unnötig. Denke zielorientiert und hole dir aus dem alten nur das, was unbedingt benötigt wird.

Ich möchte gerne, dass wir uns strikt auf die berufliche Aufgabe konzentrieren und nicht auf etwas Persönliches abweichen. Das Ticket dient dazu, Ideen auszutauschen, nicht um Meinungen über den einen oder anderen zu äußern. Danke.

Den Rest besprechen wir morgen.

> Du siehst Probleme, wo es keine gibt. Und nein, es ist nicht kompliziert. > Du versuchst in den kleinsten Details eine alte Umgebung zu rekonstruieren, um sie danach mühevoll zu aktualisieren - das ist kompliziert und unnötig. Denke zielorientiert und hole dir aus dem alten nur das, was unbedingt benötigt wird. Ich möchte gerne, dass wir uns strikt auf die berufliche Aufgabe konzentrieren und nicht auf etwas Persönliches abweichen. Das Ticket dient dazu, Ideen auszutauschen, nicht um Meinungen über den einen oder anderen zu äußern. Danke. Den Rest besprechen wir morgen.
Owner
  1. nginx eingerichtet (nach 02-nginx_base.txt)
    generische Statusseiten bereitgestellt (PHP-Version & Userpool sind variabel):
  2. PHP-vHost für dev.adressermittlung.de angelegt (nach 04-php-vhost.txt)
    -> https://dev.adressermittlung.de/ (ist erreichbar)
1. nginx eingerichtet (nach 02-nginx_base.txt) generische Statusseiten bereitgestellt (PHP-Version & Userpool sind variabel): - https://bnet005.b-net.cloud/_php/7.4/wf10501/info.php - https://bnet005.b-net.cloud/_php/7.4/wf10501/opcache.php - https://bnet005.b-net.cloud/_apc/7.4/wf10501/apc.php - https://bnet005.b-net.cloud/_phpmemcachedadmin/ 2. PHP-vHost für **dev.adressermittlung.de** angelegt (nach 04-php-vhost.txt) -> https://dev.adressermittlung.de/ (ist erreichbar)
Sign in to join this conversation.
No milestone
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Clients/neveling#4
No description provided.