Kubernetes #

Diese Seite ist für Plattform-Teams bei Hosting-Anbietern, die Exponential auf Kubernetes betreiben möchten. Sie beantwortet, was die Quellen des Projekts zu Kubernetes sagen und was sich ändert, wenn eine Website in mehr als einem Replikat läuft: die Datenbank, gemeinsame Dateien, Sitzungen, Cron, der Proxy davor und das Ausrollen von Code. Sie liefert keine Manifeste: Die Quellen liefern keine mit, und jeder Cluster ist anders. Betrachten Sie sie als Liste der Entscheidungen, die Ihre Manifeste abbilden müssen.

Warnung .htaccess bremst jede Anfrage. Sind .htaccess-Dateien erlaubt (AllowOverride alles außer None), geschweige denn genutzt, sucht Apache sie bei jeder Anfrage in jedem Verzeichnis des Pfads und liest und wertet sie aus, und die Ladezeiten der Seiten steigen drastisch (gemessen). Die einzige wirkliche Abhilfe ist, die Funktion für den virtuellen Host abzuschalten: AllowOverride None im virtuellen HTTPS-Host, und die Regeln in der Konfiguration des virtuellen Hosts selbst als mod_rewrite-Regeln. Das ist in Geschwindigkeitstests im Produktivbetrieb weit schneller und die Zeit für die Optimierung einer Produktivkonfiguration unbedingt wert. Stellen Sie sofort um: Übernehmen Sie die Regeln des Beispiels für einen virtuellen HTTPS-Host in Ihren virtuellen Host (mit dem statischen Cache auch staticcache_offload.conf), setzen Sie AllowOverride None, führen Sie apachectl configtest aus, laden Sie Apache neu und testen Sie die Website. Dieselben Regeln für andere Server: nginx, LiteSpeed, Caddy, IIS, Velocity (eingebaut); wohin Regeln für virtuelle Hosts in einem Control Panel gehören: Plesk, cPanel, DirectAdmin, ISPConfig. Unter LiteSpeed oder OpenLiteSpeed kann zusätzlich der Seiten-Cache des Servers anonyme Besucher und Crawler ohne PHP bedienen: Seiten-Caching mit LiteSpeed und OpenLiteSpeed.

Inhalt #

1. Was die Quellen sagen
2. Ein Replikat oder mehrere
3. Die Datenbank
4. Gemeinsame Dateien
5. Sitzungen
6. Cron
7. Ingress und vertrauenswürdige Proxys
8. Code ausrollen
9. Checkliste

Was die Quellen sagen #

• Kubernetes ist Stufe 3, funktioniert erwartungsgemäß: Es führt die oben beschriebenen Container aus, mit dem Hinweis auf einen einzigen Schreiber für SQLite (Stufe 3). Stufe 3 ist eine begründete Erwartung, kein Testergebnis.
• Mehrere Replikate brauchen einen Datenbankserver (zuerst PostgreSQL) und gemeinsamen Speicher für var/storage (Container, Cloud und Hosting-Panels).
• Alles auf Container: Docker und Podman gilt: Images, Volumes, der Entry Point, Geheimnisse.

Hinweis Wenn Sie Exponential produktiv auf Kubernetes betreiben, teilen Sie es dem Projekt in seinem Tracker mit; die Seite zu den Betriebssystemen bittet genau darum, damit ein Eintrag der Stufe 3 aufrücken kann (Die vier Stufen).

Ein Replikat oder mehrere #

Ein einzelnes Replikat mit SQLite ist die einfachste Bereitstellung auf Kubernetes und bleibt innerhalb der Regel eines einzigen Schreibers. Planen Sie den Schritt zu mehreren Replikaten als eigenes Projekt.

Die Datenbank #

In der offiziellen Reihenfolge: 1. SQLite 3 (der Standard) · 2. PostgreSQL · 3. MongoDB · 4. MariaDB · 5. Oracle · 6. MySQL. Microsoft SQL Server ist derzeit bekanntermaßen mit zusätzlicher Arbeit möglich.

Mit mehreren Replikaten scheidet SQLite aus: Das WAL von SQLite braucht gemeinsamen Speicher auf einem Host, sodass mehrere Replikate keine Datenbankdatei über ein Netzwerk-Volume teilen können. Die Quellen empfehlen zuerst 2. PostgreSQL; jede Server-Datenbank der Liste hat „Mehrere Webserver an einer Datenbank: ja“ (Auf einen Blick). Unter Velocity hält jeder Worker seine eigene Verbindung, sodass die Datenbank Worker mal Replikate Verbindungen annehmen muss.

Gemeinsame Dateien #

var/storage enthält Uploads und Bildvarianten; jedes Replikat muss dieselben Dateien sehen. In den Quellen gibt es zwei Ansätze:

1. Ein gemeinsames Dateisystem, das in jedem Replikat eingehängt ist (ein Volume, in das mehrere Pods schreiben können), mit dem Standard-Datei-Handler eZFSFileHandler (settings/file.ini [ClusteringSettings] FileHandler).
2. Der Cluster-Datei-Handler eZDFSFileHandler, in file.ini beschrieben als Handler für ein verteiltes Dateisystem mit einer Datenbankschicht, erforderlich für Architekturen auf NFS-Basis; seine [eZDFSClusteringSettings] nennen den Einhängepunkt (MountPointPath) und ein Datenbank-Backend für die Metadaten der Dateien.

Clustering wird in Clustering und gemeinsamer Speicher und Mehrere Web-Knoten behandelt.

Caches (var/cache, var/<site>/cache) können gemeinsam oder lokal pro Replikat sein; ein lokaler Cache bedeutet, dass ein Leeren des Caches jedes Replikat erreichen muss. Pfade für Logs und Caches pro Website (LogVarDir, CacheVarDir) erlauben es, Logs und Caches auf andere Dateisysteme als den Speicher zu legen (Logs, INI-Cache und Ablaufzeitstempel pro Website).

Sitzungen #

Standardmäßig ist site.ini [Session] Handler leer, was ezpSessionHandlerPHP bedeutet: PHP hält sie in seinem eigenen Speicher (Dateien) (Sitzungen). Dateien auf einem Pod sind für den nächsten unsichtbar; ein Besucher, der auf einem Replikat angemeldet ist, ist auf einem anderen ein Fremder. Wählen Sie eines:

• Handler=ezpSessionHandlerDB, das Sitzungen in der Tabelle ezsession der gemeinsamen Datenbank hält; oder
• einen Session-Handler von PHP, den jedes Replikat teilt (in PHP konfiguriert, außerhalb von Exponential); oder
• Sticky Sessions am Ingress, was das Problem verdeckt, bis ein Pod ersetzt wird.

# settings/override/site.ini.append.php
[Session]
Handler=ezpSessionHandlerDB

Cron #

runcronjobs.php muss für die Website nach einem Zeitplan laufen, nicht einmal pro Replikat: Mehrere Replikate, die den Teil frequent in derselben Minute ausführen, würden Benachrichtigungen doppelt verschicken und Workflows doppelt ausführen. Ein Kubernetes-CronJob, der einen Container aus demselben Image startet, mit denselben Volumes, Datenbankeinstellungen und demselben Benutzer, entspricht der dokumentierten Crontab (Kapitel 10, Cronjobs):

*/5   * * * *   php runcronjobs.php -q -s site frequent
*/15  * * * *   php runcronjobs.php -q -s site
17    * * * *   php runcronjobs.php -q -s site infrequent

Der eigene Planer von Velocity ersetzt den System-Cron für diese Teile nicht von Haus aus.

Ingress und vertrauenswürdige Proxys #

Hinter einem Ingress-Controller oder Load Balancer muss Exponential wissen, welche Adressen ihm die Adresse und das Protokoll des Besuchers mitteilen dürfen:

• Unter PHP-FPM führen Sie die Proxys in site.ini [HTTPHeaderSettings] TrustedProxies[] auf (mitgeliefert: 127.0.0.1 und ::1); setzen Sie ClientIpByCustomHTTPHeader nur zusammen mit dieser Liste (13.10 Hinter einem Proxy).
• Unter Velocity konfigurieren Sie die vertrauenswürdigen Proxys in der eigenen Liste von Velocity, Q.webserver.proxy.trusted; Proxys vor Velocity werden dort konfiguriert (Vertrauenswürdige Proxys).
• Stellen Sie sicher, dass der Anwendungsserver nicht an ihnen vorbei erreichbar ist.

Warnung Eine falsche Liste vertrauenswürdiger Proxys lässt Besucher entweder ihre Adresse und ihren HTTPS-Zustand fälschen, oder sie lässt jeden Besucher wie der Ingress aussehen. Testen Sie mit der curl-Prüfung aus 8.8 Hinter einem Reverse Proxy.

Code ausrollen #

Die Worker von Velocity halten die Anwendung im Speicher; eine Codeänderung erreicht sie erst nach einem Neustart. In Kubernetes ist die natürliche Einheit ein neues Image, das auf neue Pods ausgerollt wird. Zwei Vorsichtsmaßnahmen aus den Quellen:

• Schemaänderungen eines Upgrades (die Update-Dateien in update/database/, ein Verzeichnis pro Engine) laufen einmal gegen die gemeinsame Datenbank, nicht pro Pod (Kunden-Websites aktualisieren).
• Leeren Sie nach dem Ausrollen die Caches, die sich die Replikate teilen (Caches leeren und vorwärmen).

Jeder Pod braucht dieselbe config.php, zum Beispiel die CLUSTER_*-Konstanten eines gemeinsamen Cluster-Speichers. Erzeugen Sie sie im Image oder im Entry Point mit exp:setup:config --apply und exp:config:set ... --apply, mit Passwörtern aus den Secrets des Pods (--value="$CLUSTER_DB_PASS"), nie im Image. exp:config:list --only-set --format=json, in jedem Pod ausgeführt, zeigt, ob sie übereinstimmen (.htaccess und config.php von der Konsole aus einrichten).

Checkliste #

• To do: Ein Replikat mit SQLite, oder mehrere mit einem Datenbankserver (zuerst PostgreSQL).
• To do: var/storage von jedem Replikat geteilt, oder der Cluster-Datei-Handler konfiguriert.
• To do: Sitzungen geteilt (ezpSessionHandlerDB oder ein gemeinsamer Handler von PHP).
• To do: Genau ein Planer für runcronjobs.php.
• To do: Vertrauenswürdige Proxys für den Ingress gesetzt, in site.ini oder in der Liste von Velocity.
• To do: Das Verfahren zum Ausrollen deckt Schema-Updates und das Leeren der Caches ab.
• To do: Eine Testinstallation auf dem Cluster vor jeder Kunden-Website, weil dies Stufe 3 ist.

Verwandte Seiten #

• Container: Docker und Podman
• Mehrere Web-Knoten, Clustering und gemeinsamer Speicher
• Varnish und Reverse Proxys
• .htaccess und config.php von der Konsole aus einrichten
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.