☰

Nginx-Reverse-Proxy zu PHP-FPM

tag-icon • tag-icon php nginx docker reverse-proxy
Nginx-Reverse-Proxy zu PHP-FPM

Ich habe konzeptionell einige Probleme mit einer Nginx-Konfiguration. nginxIch beginne mit einem Reverse-Proxy mit SSL-Terminator und verwende ein docker-compose.ymlSetup mit einigen Containern, von denen jeder einen virtuellen Dienst bereitstellt. Diese Dienste werden als Unterverzeichnisse unter einem einzigen Hostnamen bereitgestellt:

net --443--> nginx
             | | `--- ContainerA "https://example.com/serviceA/"
             | `----- ContainerB "https://example.com/serviceB/"
             `------- ContainerC "https://example.com/serviceC/"

Ausschnitte aus Prozesslisten:

nginx:~$ ps fax
127285 ?        Ss     0:00  nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf -g daemon off;
127419 ?        S      0:00   \_ nginx: worker process
127420 ?        S      0:00   \_ nginx: worker process
127421 ?        S      0:00   \_ nginx: worker process

ContainerA:~$ ps fax
127132 ?        Ss     0:09  php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
234053 ?        S      8:27   \_ php-fpm: pool www
236952 ?        S      8:12   \_ php-fpm: pool www
259123 ?        S      6:42   \_ php-fpm: pool www

Ich dachte, die Effizienz würde gesteigert, wenn man eine einzelne Instanz von ausführt nginxund php-fpmin jedem der Container verwendet.

ICHdenkendass die Prämisse php-fpmso ist, dass die Container keine eigenen nginxProzesse benötigen; die nginxProzesse kommunizieren mit jedem Container über Port 9000 (der Netzwerkteil funktioniert). In der Praxis habe ich jedoch Probleme, daher muss ich überprüfen, ob meine Prämisse stichhaltig ist:

Ist diese Grund- nginxund php-fpmArchitekturannahme richtig?Oder ist eine geeignete Infrastruktur für die direkte Nutzung (gleicher Host und gleiches Dateisystem) vorgesehen, nginxoder php-fpmist php-fpmMulti-Hosting/Multi-Dateisystem sinnvoll und effizient?

(Ich habe vor Kurzem versucht, Hilfe zu vertraglich zu vereinbaren, und die erste Antwort war: „Sie müssen es nginxin jedem Container ausführen“, was meines Erachtens keinen Sinn ergab php-fpm.)

(Hier gibt es viele Fragen, die spezifische nginx.confFragen stellen, die sich nicht auf diese zugegebenermaßen höherstufige Architektur beziehen.)

Antwort1

Das ist eine schwache Antwort, aber ich glaube:

Ja, das ist im Allgemeinen die richtige Philosophie, allerdings mit einigen Einschränkungen. php-fpmist für die Verarbeitung von Dateien da .php, aber ich glaube nicht für die Bereitstellung aller (nicht PHP-)Dateien. Dafür nginxmuss der Front-End-Prozess alle Dateien sehen können, auch wenn er die eigentliche PHP-Verarbeitung nicht durchführt.

Damit dies mithilfe von Docker intelligent abläuft, php-fpmmüssen die Dateien im Container explizit mit dem Container geteilt werden nginx. Die bevorzugte Methode hierfür in Docker besteht darin, ein benanntes Volume bereitzustellen und es für beide Container zu verwenden. Beispielsweise eine docker-compose.ymlDatei:

version: '2'
services:
  serviceA:
    image: ... # something served with php-fpm
    volumes:
    - tmpvolA:/path/to/serviceA
  serviceB:
    image: ... # something served with php-fpm
    volumes:
    - tmpvolB:/path/to/serviceB
  nginx:
    image: ...
    volumes:
    - tmpvolA:/var/www/serviceA
    - tmpvolB:/var/www/serviceB
volumes:
  tmpvolA:
  tmpvolB:

(Viele, viele Felder sind nicht enthalten ...) Die beiden am Ende aufgelisteten Volumes sind die „benannten Volumes“, von denen Docker spricht, und sie sind aus einem Grund leer: Sie sollen leer sein, wenn Sie das Skript starten, und werden von einem der Container gefüllt. (Tatsächlich kann es von beiden oder keinem gefüllt werden, abhängig von verschiedenen Faktoren.)

Ein Nebeneffekt davon ist, dass die Voluminafortdauern.

  • „Dies ist gut“ für die Effizienz, da es nicht unnötig neu erstellt wird.
  • „Das ist schlecht“, denn ein Vorteil virtualisierter Dienste ist, dass Sie sie neu starten können und garantiert eine saubere Weste haben. Mit persistenten benannten Volumes erhalten Sie nicht (automatisch) eine saubere Weste, da die in der vorherigen Instanz verwendeten Dateien anstelle der strengen Version in einer niedrigeren FS-Schicht verwendet werden.

Um dieses „Problem“ zu umgehen, müssen Sie die Volumes manuell leeren. Dies kann entweder beim Herunterfahren mit erfolgen docker-compose down -v, was der Hilfe zufolge so geht:

    -v, --volumes       Remove named volumes declared in the `volumes` section
                        of the Compose file and anonymous volumes
                        attached to containers.

docker volume rm <volume-id>Dies kann auch manuell mit oder erfolgen docker volume prune(wodurch alle derzeit nicht verwendeten Datenträger entfernt werden, egal ob temporär oder benannt oder was auch immer).

verwandte Informationen