Server und Deployment: Apache und PHP-FPM, Velocity, FrankenPHP #

Diese Seite richtet sich an Entwickler, die Framework-Anwendungen auf PHP-FPM, auf einem Anwendungsserver (Laravel Octane, RoadRunner, Worker-Modus von FrankenPHP) oder auf Gunicorn, Puma oder einem Servlet-Container bereitstellen. Exponential läuft unter drei Servern, die alle über ./console exp:velocity und settings/velocity.ini gesteuert werden, und bringt einen einzigen Befehl mit, der jeden Schritt ausführt, den eine Codeänderung erfordert (Server: Velocity, PHP-FPM und FrankenPHP).

Inhalt #

1. Drei Arten der Auslieferung
2. Regeln für persistente Worker
3. Eine Änderung bereitstellen
4. Was wie übertragen wird
5. Ein Release, Schritt für Schritt
6. Im Vergleich mit anderen Stacks

Drei Arten der Auslieferung #

Seit 6.0.15 ist Velocity Teil von Exponential: composer.json verlangt se7enxweb/exponential-velocity, daher ist es in jeder Installation vorhanden. velocity.ini [ServerSettings] Engine wird mit php ausgeliefert (dem eingebauten Server von PHP, für die Entwicklung); jede echte Site setzt qbix (Velocity-Engines, Die Site ausliefern, Deployment-Leitfaden).

Regeln für persistente Worker #

• Kein Zustand pro Request in statischen Eigenschaften oder globalen Variablen ohne Zurücksetzen.
• Kein exit zur Ablaufsteuerung außer eZExecution::cleanExit(), und dessen Exception niemals abfangen.
• Eingaben über eZHTTPTool lesen, das der Kernel pro Request vorbereitet, nicht direkt über $_POST.
• Registrierungen von Event-Listenern müssen idempotent sein.
• Eine geänderte Klasse oder Einstellung erreicht die Worker erst nach einem Neustart; eine neue Kernel-Klasse braucht --kernel.

Das sind dieselben Regeln, die Octane oder RoadRunner vorgeben; Code, der sie einhält, verhält sich unter PHP-FPM genauso (Velocity: der Server mit persistenten Workern).

Eine Änderung bereitstellen #

./console exp:velocity deploy --dry-run --allow-root-user   # what it would do
./console exp:velocity deploy --allow-root-user             # the usual case
./console exp:velocity deploy --kernel --allow-root-user    # a kernel class was added or renamed

Der Reihe nach: Autoloads der Erweiterungen (--kernel: auch des Kernels), INI- und Template-Caches, das Engine-Archiv, wenn sich Kernel-Dateien geändert haben (jede Datei wird zuerst geparst, sodass eine fehlerhafte Datei das Deployment stoppt, bevor ein Server angefasst wird), ein Reload von PHP-FPM bei Bedarf, der Neustart von Velocity, dann Inhalts-, HTTP- und Template-Block-Caches und zuletzt der Response-Cache von Velocity, sodass eine von altem Code gerenderte Seite nie erneut zwischengespeichert wird. Der Befehl gibt für jeden Schritt PASS, FAIL oder SKIP aus und bricht beim ersten Fehler ab (Deployment mit Velocity). --packer leert zusätzlich gepackte Stylesheets und Skripte.

Was wie übertragen wird #

Aus Eine Deployment-Pipeline:

Ein Release, Schritt für Schritt #

1. Die Tests laufen in der CI durch.
2. Auf Staging bereitstellen, die Upgrade-Schritte ausführen, testen.
3. Die Produktion sichern.
4. Wartungsmodus, wenn das Release Daten ändert (php bin/php/maintenance.php on --allow-admin).
5. Den Code aktualisieren (Git oder composer update <package>), die Upgrade-Schritte ausführen.
6. ./console exp:velocity deploy (--kernel, wenn sich Kernel-Klassen geändert haben).
7. Wartungsmodus aus; prüfen mit exp:velocity status, exp:cache status, den Seiten und dem Fehlerprotokoll.

Ein Rollback ist der vorherige Tag plus eine Wiederherstellung der Sicherung, wenn Upgrade-Schritte Daten verändert haben.

Im Vergleich mit anderen Stacks #

Verwandte Seiten #

• Velocity ist Teil von Exponential 6.0.15
• FrankenPHP als Web-Engine von Exponential
• Anwendungen skalieren
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.