Platform as a Service #

Diese Seite ist für Hosting-Anbieter, die eine Platform as a Service (PaaS) betreiben oder weiterverkaufen und Exponential darauf anbieten möchten. Eine PaaS legt die Laufzeitumgebung fest: Der Kunde schiebt Code hoch, die Plattform baut und betreibt ihn, und das Dateisystem, das die Anwendung sieht, ist vielleicht schreibgeschützt oder geht bei jedem Neustart verloren. Die Seite beantwortet, was die Quellen des Projekts über solche Plattformen sagen, welche Verzeichnisse Exponential schreibt und wie sie verlegt werden können, und welche Fragen Sie einer Plattform stellen, bevor Sie Exponential darauf anbieten.

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. Was Exponential zur Laufzeit schreibt
3. Schreibgeschützte oder flüchtige Dateisysteme
4. Die Datenbank
5. Prozesse: Web, Cron und lang laufende Server
6. Bauen und veröffentlichen
7. Fragen an eine Plattform

Was die Quellen sagen #

Angebote als Platform as a Service, die PHP 8 mit einer beschreibbaren persistenten Festplatte ausführen, funktionieren erwartungsgemäß (Stufe 3). Angebote mit einem schreibgeschützten oder flüchtigen Dateisystem brauchen var/ auf persistentem Speicher und einen Datenbankserver (Container, Cloud und Hosting-Panels).

Stufe 3 bedeutet eine begründete Erwartung, kein Testergebnis (Die vier Stufen): Die Quellen nennen und testen kein bestimmtes PaaS-Produkt. Führen Sie eine vollständige Testinstallation auf der Plattform aus, bevor Sie sie anbieten.

Was Exponential zur Laufzeit schreibt #

Der Test directory_permissions des Setup-Assistenten listet die Verzeichnisse auf, die beschreibbar sein müssen: design, extension, settings, settings/override, settings/siteaccess, settings/siteaccess/admin, var, var/cache und seine Unterverzeichnisse, var/log, var/storage und seine Unterverzeichnisse, var/autoload (2.4 Die Systemprüfung des Setup-Assistenten).

Nach der Installation können Sie den Schreibzugriff auf design/ und extension/ wieder entziehen, wenn nichts Pakete aus der Administration installiert; settings/ bleibt beschreibbar, wenn Administratoren Einstellungen im Browser ändern (8.7.1).

Tipp Auf einer PaaS gehören Einstellungen in das Code-Repository. Der Schalter [ConfigurationSettings] ManagedByDeployment=enabled sorgt dafür, dass die Konfiguration dieses Siteaccess nur aus dem Ausrollen (der Versionsverwaltung) kommt: Die Administration schreibt keine *.ini.append.php- oder .tpl-Dateien mehr auf den Server (Konfiguration über das Ausrollen verwaltet).

Schreibgeschützte oder flüchtige Dateisysteme #

Das Verzeichnis var wird durch site.ini [FileSettings] VarDir festgelegt (mitgeliefert var). Der Kommentar in settings/site.ini ist eindeutig: Nur Verzeichnisse relativ zum Wurzelverzeichnis von Exponential werden unterstützt; absolute Verzeichnisse werden NICHT UNTERSTÜTZT. Hängen Sie den persistenten Speicher daher unter var/ innerhalb der Installation ein, statt VarDir anderswohin zeigen zu lassen.

Innerhalb von var/ bieten die Quellen feinere Steuerung (site.ini [FileSettings], Logs, INI-Cache und Ablaufzeitstempel pro Website):

Warnung Wenn das Cache-Verzeichnis auf einem Speicher liegt, der bei einem Neustart geleert wird, setzen Sie ExpiryDir auf ein Verzeichnis auf dem persistenten Volume. Sonst gehen die Ablaufzeitstempel mit dem Cache verloren.

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 einem schreibgeschützten oder flüchtigen Dateisystem verlangen die Quellen einen Datenbankserver. Auch mit einer persistenten Festplatte kann eine Plattform, die vielleicht mehr als eine Instanz der Anwendung betreibt, keine SQLite-Datei zwischen ihnen teilen. Nutzen Sie die verwaltete Datenbank der Plattform, zuerst 2. PostgreSQL, wenn sie mehrere anbietet (Datenbankunterstützung).

Prozesse: Web, Cron und lang laufende Server #

• Web. Wenn die Plattform PHP hinter ihrem eigenen Webserver ausführt (nach Art von PHP-FPM), müssen die Rewrite-Regeln aus .htaccess_root für diesen Server übersetzt werden: Nur eine feste Liste von Asset-Pfaden wird als Dateien ausgeliefert; alles andere geht an index.php (13.2). Eine allgemeine Konfiguration „Datei ausliefern, wenn sie existiert“ würde settings/*.ini ausliefern.
• Velocity braucht einen lang laufenden Prozess und PHP 8.0 oder später mit sockets. Eine Plattform, die einen Prozess pro Container ausführt und HTTP an einen Port leitet, kann es betreiben; eine, die PHP nur pro Anfrage ausführt, nicht.
• Cron. runcronjobs.php muss nach Zeitplan laufen, einmal pro Website, mit demselben Code und denselben Einstellungen (Cronjobs). Fragen Sie, ob die Plattform einen Planer hat.
• Sitzungen. Mit mehr als einer Instanz müssen Sitzungen geteilt werden; siehe Kubernetes, Sitzungen.

Bauen und veröffentlichen #

• Bauen: composer install (das über das Skript legacy-scripts auch bin/php/ezpgenerateautoloads.php ausführt) (2.7 Composer).
• Einmal installieren, gegen die verwaltete Datenbank, mit exp:install und Geheimnissen aus der Umgebung (EXP_INSTALL_DB_PASSWORD) (4.6).
• Jedes spätere Release: neuer Code, dasselbe persistente var/ und dieselbe Datenbank, die Schema-Update-Dateien, wenn ein Upgrade sie verlangt, dann ein Leeren des Caches (Änderungen ausrollen).
• .htaccess und config.php im Build oder beim Start, unbeaufsichtigt: ./console exp:setup:htaccess --apply, ./console exp:setup:config --apply, dann ./console exp:config:set <NAME> <Wert> --apply mit Werten aus den Umgebungsvariablen der Plattform (--value="$CLUSTER_DB_PASS" für ein Geheimnis). Jeder Befehl fragt nichts, endet mit PASS: oder FAIL:, beendet sich mit 0, 1 oder 2 und ändert bei einem zweiten Lauf nichts. Ein Build-Schritt, der als root läuft, braucht --allow-root-user und, damit die Dateien nicht root gehören, --owner=www-data:www-data (.htaccess und config.php von der Konsole einrichten).

Fragen an eine Plattform #

Verwandte Seiten #

• Ein Hosting-Modell wählen, Container: Docker und Podman
• Beschreibbare Verzeichnisse und Berechtigungen
• Aufbau des Speichers
• .htaccess und config.php von der Konsole einrichten
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.