Docker Bereitstellung Update freigegebenes Volumen

Question

Art von neuen mit Docker in der Produktion habe ich eine Design-Frage. Was ist der beste Ansatz, um mit Docker eine PHP-App zu implementieren, die Daten und Informationen enthält, die von anderen Containern im Hauptanwendungsverzeichnis verwendet werden, die über die Builds aktualisiert werden müssen?

Beispiel (Symfony Art von App vereinfachen):

- application 
    - app 
    - src 
    - vendor 
    - conf 
    - conf/vhost.conf 
    - web/assets/* 

Und lassen Sie uns mit nur zwei Dienste vereinfachen

- php-fpm 
- nginx 

1/Der erste Versuch war 2 Bilder

• zu bauen php-fpm: mit

HINZUFÜGEN./Var/www/html/Projekt/

VOLUME/var/www/html/Projekt/

Anbieter (Komponist) in der Dockerfile

auf diese Weise installiert ich erreichen konnte/var/www/html/Projekt/auf nginx

volumes_from php-fpm

=> und dann ist die Konfiguration und die Anlagen usw.

Aber wenn ich nicht falsch bin, ist das nicht der gute Weg, es zu tun, weil mein Bild im nächsten Build das VOLUME/var/www/html/project/nicht aktualisiert (weil es a Volumen) => dann wird mein Code nie aktualisiert werden.

2/Dann landete ich, dass da oben:

- providing the last code base in the image: COPY . /data/image/app 
- creating a named volume: docroot 
- mount docroot on php-fpm 
- adding a rsync on the entrypoint to sync /data/image/app to docroot:/var/www/html/project (with the good excludes that I needed) 
- doing the vendors(composer) install in the entrypoint 

=> noch mit volumes_from: php-fpm auf nginx.

was wichtig ist, weil ich will:

- the conf/vhost.conf 
- the assets 
- maybe other stuff 

Ich brauche kann eine Solr hinzufügen, dass einige Konfigurationsdateien verwenden und/oder Ressourcen usw.

3/Ich nehme ein anderer Ansatz besteht, dass würde bestehen, ADD spezifisch hinzuzufügen, was ich auf jedem Bild brauche.

Ich denke, es fügt Komplexität zum Build-Prozess hinzu, aber es macht auch eine Menge Sinn.

Also, was denkst du, habe ich etwas verpasst? Ansatz 2/oder 3 /, 4?

Vielen Dank!

Answer 1

Ihre Frage ist wirklich über statische Datei-Assets. Einige Frameworks und Projekte behandeln diese sehr ähnlich wie ihre eigene Komponente. In der PHP-Welt behandelt der php-fpm-Anwendungsserver normalerweise keine statischen Dateien. Das überlässt man einer Webserver-Komponente wie nginx. Dies ist für sich genommen kein Problem.In der Tat ist es eine gute Übung.

Der einzige Grund dafür ist, dass Sie eine Isolationsschicht zwischen php-fpm und nginx einführen.

Wenn wir eine andere, non-docker Situation betrachten, in der eine Isolation zwischen php-fpm und nginx eingeführt wird, bekommen wir das gleiche Problem. In diesem Beispiel wird mein nginx-Server in der DMZ meines Datencenters ausgeführt und php-fpm wird als Anwendungsserver hinter der Firewall in meinem Datencenter fungieren. Wie wird dieses Nginx die statischen Dateien des PHP-Projekts bereitstellen?

Ich erwähnte, dass statische Vermögenswerte fast als ihre eigene Komponente betrachtet werden können. In diesem Beispiel mit zwei Knoten kann ein separater Schritt während der Bereitstellung verwendet werden, um die statischen Dateien auf dem Nginx-Server in der DMZ aufzufüllen. Dies ist nicht unähnlich Ihrer Lösung # 2, wo Sie eine rsync ausführen, um ein Volume zu füllen, auf das sowohl die php-fpm- als auch die nginx-Container Zugriff haben.

Eine andere Lösung wäre, php-fpm handle zu machen, diese statischen Werte zu bedienen. Dies wird natürlich nicht als Best Practice angesehen, da php-fpm nicht dafür ausgelegt ist, statische Dateien zu liefern. Es kann gemacht werden, aber es ist schlecht optimiert. Dieser Performance-Hit kann durch die Verwendung von Nginx-Datei-Caching gemildert werden.

Ihre # 3-Lösung ist auch durchaus praktikabel. Sie könnten auch Ihr Projekt erstellen zwei Bilder anstelle von einem. Der erste wäre Ihr normales PHP-Bild, das Ihren ganzen php-Code HINZUGEFÜGT hat. Die zweite basiert auf dem nginx-Basisimage und ADD nur die statischen Dateien, die das Projekt benötigt.

Obwohl dies nicht als Best Practice gilt, kann es bei einigen Projekten sinnvoll sein, sowohl nginx als auch php-fpm im selben Container auszuführen. Wenn Ihre Nginx-Konfiguration buchstäblich nur statische Dateien und Reverse-Proxying für php-fpm bereitstellt, können Sie diese beiden Prozesse als einen logischen Service behandeln. Sie müssten Supervisord, Runit oder einen ähnlichen Prozessmanager ausführen.