Container: Docker und Podman #

Diese Seite ist für Hosting-Anbieter und Plattform-Teams, die Exponential-Websites in Linux-Containern mit Docker oder Podman betreiben. Sie beantwortet, was die Quellen des Projekts zu Containern sagen, was auf einem persistenten Volume liegen muss, wie viele Container in eine SQLite-Datenbank schreiben dürfen, wie ein Entry Point eine Website einmal installiert und den Server laufen lässt und wie Sie Geheimnisse aus Images heraushalten.

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. Images
3. Volumes: was erhalten bleiben muss
4. Die Datenbank und die Regel eines einzigen Schreibers
5. Ein Entry Point, der einmal installiert
6. Geheimnisse
7. Betrieb in Containern
8. Checkliste

Was die Quellen sagen #

• Docker und Podman (Linux-Container) sind Stufe 2, funktionieren bekanntermaßen: Velocity veröffentlicht Images unter ghcr.io/se7enxweb/exponential-velocity für amd64 und arm64, je eines pro PHP-Version und Variante (Stufe 2).
• Jedes Image mit PHP 8 und den erforderlichen Erweiterungen kann Exponential ausführen. Halten Sie var/ (Speicher, Logs, die SQLite-Datenbank) und settings/override auf einem persistenten Volume. Mit SQLite betreiben Sie einen Container, der schreibt (Container, Cloud und Hosting-Panels).
• exp:install ist die Methode für CI-Pipelines, Container-Images und automatische Testumgebungen: Optionen oder Umgebungsvariablen, Exit-Status (4.6 Unbeaufsichtigte Installationen).

Images #

Zwei Wege:

Die Images von Velocity sind nach Release, PHP-Version und Variante getaggt (Velocity-Pakete, Docker-Images und Binärdateien):

ghcr.io/se7enxweb/exponential-velocity:<release>-php<version>-<variant>   fixed
ghcr.io/se7enxweb/exponential-velocity:php<version>-<variant>             moves with each release
ghcr.io/se7enxweb/exponential-velocity:latest                             newest PHP, standard variant

<version> ist 8.2, 8.3, 8.4 oder 8.5; <variant> ist mini, lite, standard oder full. Schreiben Sie in der Produktion einen festen Tag fest. Die Variante standard ist der Standard, von dem die Dokumentation ausgeht.

Tipp Welche Basis auch immer: Führen Sie php bin/php/console exp:velocity ext check im gebauten Image als Teil Ihrer Image-Pipeline aus. Es listet jede Erweiterung auf, die die Installation will, markiert, was fehlt, und gibt den Installationsbefehl aus (Herausfinden, was fehlt).

Volumes: was erhalten bleiben muss #

Der Backup-Satz ist derselbe wie überall: die Datenbank und var/storage, settings/override und settings/siteaccess (Backup und Wiederherstellung).

Warnung Dateien auf dem Volume müssen dem Benutzer gehören, als der das PHP des Containers läuft. Dateien, die root anlegt, sind für den Webserver später vielleicht nicht beschreibbar (4.6). Legen Sie die Benutzer-ID einmal für Image und Volume fest, und behalten Sie sie bei.

Die Datenbank und die Regel eines einzigen Schreibers #

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.

• 1. SQLite 3 funktioniert in einem Container, wenn ein Container in die Datenbank schreibt: Das WAL von SQLite braucht gemeinsamen Speicher auf einem Host, sodass mehrere Replikate keine Datenbankdatei über ein Netzwerk-Volume teilen können.
• Mehrere Container, die eine Website ausliefern, brauchen einen Datenbankserver (zuerst PostgreSQL) und gemeinsamen Speicher für var/storage (Container, Cloud und Hosting-Panels). Sie brauchen außerdem Sitzungen, die jeder Container lesen kann; siehe Kubernetes.
• Der Datenbankserver läuft meist in einem eigenen Container oder als verwalteter Dienst Ihrer Plattform, mit eigenem Volume und eigenen Backups (Datenbank-Backups je Engine).

Ein Entry Point, der einmal installiert #

Kapitel 4 nennt einen minimalen Entry Point für Container, der einmal installiert, dann Velocity startet und im Vordergrund bleibt, solange er läuft:

#!/usr/bin/env bash
set -euo pipefail
cd /srv/exponential
if ! grep -q '^\[DatabaseSettings\]' settings/override/site.ini.append.php 2>/dev/null; then
    php bin/php/console exp:install --apply \
        --db=mysql --db-host="${DB_HOST}" --db-name="${DB_NAME}" --db-user="${DB_USER}" \
        --url="${SITE_URL}" --email="${ADMIN_EMAIL}" --password="${ADMIN_PASSWORD}"
fi
php bin/php/console exp:velocity start
# exp:velocity start runs the server in the background and returns; status exits 0 while it runs
while php bin/php/console exp:velocity status >/dev/null 2>&1; do sleep 30; done
echo "Velocity stopped" >&2
exit 1

Was das Kapitel dazu erklärt:

• Das grep ist derselbe Test, mit dem exp:install selbst entscheidet, dass ein Verzeichnis bereits eine Installation enthält.
• exp:velocity start löst den Server ab und kehrt zurück, sobald er antwortet; die Schleife hält daher den Hauptprozess des Containers am Leben und beendet ihn, wenn der Server anhält, sodass die Container-Laufzeitumgebung ihn neu starten kann.
• Wenn der Entry Point als root läuft, fügen Sie den beiden Befehlen exp:velocity --allow-root-user hinzu.
• Das Beispiel nutzt --db=mysql; die anderen Werte sind sqlite (der Standard), pgsql, mongodb, mariadb und oracle (Datenbankunterstützung, Auf einen Blick).

Warnung exp:install nutzt standardmäßig die Datenbankaktion remove. Das ist, was ein frischer Container will, und genau das, was nie auf eine Datenbank zeigen darf, die Daten enthält, die Sie brauchen (4.6). Lassen Sie den Test „bereits installiert“ davor stehen.

Geheimnisse #

• Übergeben Sie das Datenbankpasswort in EXP_INSTALL_DB_PASSWORD; exp:install liest es, wenn --db-password nicht angegeben ist, und hält es so aus der Prozessliste und der Shell-Historie heraus.
• Ohne --password erzeugt exp:install ein Administratorpasswort mit 24 Zeichen und schreibt es nach var/log/initial-admin-password (Modus 0600); lesen Sie es dort und ändern Sie es, oder übergeben Sie eines aus Ihrem Geheimnisspeicher (Erste Anmeldung und Standardpasswörter).
• Backen Sie settings/override nie in ein Image ein: Es enthält die Zugangsdaten zur Datenbank (13.3 Geheimnisse in settings/override).
• config.php kann im Image entstehen (exp:setup:config --apply --allow-root-user --owner=www-data:www-data im Build-Schritt), aber ein Passwort darin, etwa CLUSTER_STORAGE_PASS, wird beim Start aus der Umgebung gesetzt: php bin/php/console exp:config:set CLUSTER_STORAGE_PASS --value="$CLUSTER_DB_PASS" --apply --allow-root-user. Die Ausgabe zeigt es als ********. In der CI zeigt exp:config:list --only-set --format=json, was ein Image oder ein laufender Container setzt (.htaccess und config.php von der Konsole aus einrichten).

Betrieb in Containern #

• Cron. runcronjobs.php muss weiterhin nach Zeitplan laufen: aus einem Planer-Container, der die Volumes und die Datenbank teilt, oder aus dem Planer Ihrer Plattform, als derselbe Benutzer wie der Webprozess (Cronjobs).
• Logs. Exponential schreibt seine Logs unter var/log (und pro Website unter var/<site>/log); halten Sie sie auf dem Volume oder sammeln Sie sie dort ein (Anfrage-Logs).
• Codeänderungen erreichen die Worker von Velocity erst nach einem Neustart; exp:velocity deploy führt die Schritte in Reihenfolge aus (8.3.14). In Containern ist das übliche Gegenstück ein neues Image und ein neuer Container.

Checkliste #

• To do: Image mit PHP 8.0+ und jeder erforderlichen Erweiterung; exp:velocity ext check besteht in der Pipeline.
• To do: Feste Image-Tags in der Produktion.
• To do: var/, settings/override, settings/siteaccess auf persistenten Volumes, im Eigentum des PHP-Benutzers des Containers.
• To do: Ein schreibender Container für SQLite, oder ein Datenbankserver für mehr.
• To do: Entry Point mit dem Test „bereits installiert“; Geheimnisse aus der Umgebung, nicht aus dem Image.
• To do: Cron, Logs und Backups festgelegt.

Eine öffentliche Demo in einem Container. Geben Sie dem Demo-Dienst EXP_DEMO_MODE=1 (-e, --env-file oder env_file:; docker-demo.env), nie einem Basis-Image, das andere Websites nutzen. Mit PHP-FPM im Container behalten Sie clear_env = no oder setzen env[EXP_DEMO_MODE] = 1 im Pool. Demomodus für Hoster.

Verwandte Seiten #

• Kubernetes, Platform as a Service
• exp:install, Bereitstellung automatisieren
• Mit einem Befehl installieren
• .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.