Hosting-Anforderungen

Diese Seite definiert den Hosting-Vertrag für eine Produktionsinstallation WebBlocks CMS. Es richtet sich an Agenturen, Serverbetreiber und Hosting-Anbieter, die einen Server vor der Bereitstellung bewerten.

WebBlocks CMS ist ein Composer-Paket, das in einer Laravel-Hostanwendung installiert wird. Die Hostanwendung ist Eigentümer ihrer Umgebung, ihres Webservers, ihrer Datenbank, ihrer E-Mails, ihrer Warteschlangen, ihrer geplanten Aufgaben, ihrer Sicherungen und ihrer Bereitstellung. Die Erfüllung der Paketanforderungen allein macht eine ansonsten unvollständige Laravel-Anwendung nicht bereitstellbar.

Bereich

Mindestanforderung

PHP

PHP 8.3 oder neuer innerhalb des von Composer unterstützten ^8.3-Bereichs, wobei CLI und die Web-Runtime dieselbe kompatible Version verwenden

Rahmen

Laravel Framework 12.55+ oder 13.x

Abhängigkeitsmanager

Composer 2, verfügbar während der Installation und paketnativen Systemaktualisierungen

Vom Paket deklarierte PHP-Erweiterungen

mbstring, sodium und zip

Basislinie der Produktionsdatenbank

MySQL 8.0 mit InnoDB, einer Datenbank und Anmeldeinformationen, die die Anwendung für Tabellen, Indizes, Fremdschlüssel und Transaktionen verwenden kann

Webserver

Nginx, Apache oder ein gleichwertiger Server, der Laravel-Anfragen über public/index.php weiterleiten kann

Dokumentstamm

Das public/-Verzeichnis der Hostanwendung, niemals das Anwendungsstammverzeichnis

TLS

HTTPS für Produktionsverwaltung und öffentlichen Datenverkehr

Composer löst auch die eigenen Plattformanforderungen von Laravel. Der Anbieter muss composer check-platform-reqs für die gesamte Hostanwendung durchlassen; Die obige Tabelle ersetzt diese Prüfung nicht.

Eine für den Produktionsbetrieb zertifizierte allgemeine PHP-Speicheruntergrenze oder Anfragezeitgrenze wurde noch nicht festgelegt. Die bisherige teilweise lokale Qualifizierung ergab folgende vorläufige Planungswerte:

Getestete Arbeitslast

Vorläufiger Planungswert

CMS-Kern, ohne GD-Bildtransformationen

PHP memory_limit von mindestens 128 MiB

Ein PHP-Worker, der Bilder mit GD transformieren kann

Mindestens 512 MiB tatsächliche Prozesskapazität pro gleichzeitigem Worker, qualifiziert für Quellbilder bis zu 6.000 × 4.000 Pixel (24 MP)

Der Wert von 128 MiB ist ein vorläufiger Kandidat für den Kernbetrieb: Die vollständige Feature-Testsuite bestand bei diesem Limit alle fünf Durchläufe und scheiterte bei 96 MiB. Für GD-Bildverarbeitung reicht dieser Wert allein nicht aus. Im 24-MP-WebP-Test meldete PHP nur 32.5 MiB, während der tatsächliche maximale residente Speicher des Workers 312.26 MiB erreichte; GD reserviert beträchtlichen Speicher außerhalb des von PHP erfassten Limits memory_limit. Mit der Sicherheitsmarge des Qualifizierungsprotokolls ergibt sich ein vorläufiges Planungsprofil von 512 MiB realem Speicher für jeden gleichzeitig Bilder transformierenden PHP-Worker.

Bei der Zahl von 512 MiB handelt es sich um die Worker-Kapazität, nicht um den gesamten Server-RAM. Der Server muss zusätzlich das Betriebssystem, den Webserver, die Datenbank, Caches und andere gleichzeitig arbeitende PHP-Worker aufnehmen. Da das CMS derzeit die Größe hochgeladener Dateien, jedoch nicht die Rasterpixelabmessungen begrenzt, kann 512 MiB nicht garantieren, dass beliebige Bilder größer sind als die getestete Arbeitslast von 24 MP. Siehe Hosting-Kapazitätsergebnisse für die Messungen und Qualifikationsgrenze.

SQLite wird von der Pakettestsuite verwendet und von bestimmten Sicherungs-/Wiederherstellungscodepfaden unterstützt, ist jedoch nicht die Basislinie für das Produktionshosting. Es gibt MariaDB-fähige Sicherungs- und Wiederherstellungspfade, aber eine MariaDB-Version ist derzeit nicht Teil der Produktionsabnahmematrix. PostgreSQL darf nicht als vollständig unterstütztes Produktionsziel angeboten werden, bis die vollständigen Installations-, Migrations-, Betriebs-, Sicherungs- und Wiederherstellungsabläufe abgedeckt und dokumentiert sind.

Die erforderlichen Erweiterungen müssen sowohl in der CLI PHP-FPM/Apache PHP als auch in der CLI PHP aktiviert sein. Ein Hosting-Panel, das unterschiedliche Konfigurationen für Web und CLI PHP bereitstellt, muss diese aufeinander abstimmen.

Die folgenden Fähigkeiten sind bedingt:

• gd, einschließlich der Codecs für die verwendeten Medienformate, ermöglicht die Erstellung von Miniaturansichten und responsiven Bildern. Ohne sie greifen berechtigte Transformationen auf die ursprünglichen Medien-URLs zurück.
• Der Datenbank-PDO-Treiber muss mit der ausgewählten Datenbank übereinstimmen; Das Produktions-MySQL-Profil benötigt daher pdo_mysql.
• Standardmäßige Laravel- und Composer-Plattformanforderungen, üblicherweise einschließlich OpenSSL- und Dateiinformationsunterstützung, müssen entsprechend den Anforderungen der aufgelösten Hostanwendung aktiviert bleiben.
• Für den paketnativen Systemaktualisierungsworkflow sind proc_open und die Berechtigung zum Ausführen der Prozesse PHP und Composer erforderlich. Wenn der Anbieter die Prozessausführung deaktiviert, müssen Bereitstellungen und Aktualisierungen vom Betreiber außerhalb des CMS verwaltet werden.

Leiten Sie keine Erweiterungsanforderung aus einem nur für die Entwicklung vorgesehenen Doctor-Befehl ab. Die maßgebliche Installationsprüfung ist die Plattformauflösung Composer für die gesamte Hostanwendung, gefolgt von den CMS-Bereitschaftsprüfungen.

Der bereitgestellte Code muss für die PHP-Laufzeitumgebung lesbar sein. Der Laufzeitbenutzer PHP oder eine gemeinsam genutzte Bereitstellungsgruppe benötigt Lese-/Schreibzugriff auf:

• storage/, einschließlich storage/framework, storage/logs, öffentliche Medien, temporäre Arbeitsbereiche und die konfigurierte Sicherungsfestplatte;
• bootstrap/cache;
• public/site, wo Website- und Seitenüberschreibungs-Assets erstellt werden können;
• das Anwendungsstammverzeichnis und der konfigurierte Update-Arbeitsbereich nur, wenn paketnative Systemupdates das installierte Paket ändern; Und
• jede andere vom Host für CMS-Medien oder Backups konfigurierte Laravel-Festplatte.

Verwenden Sie den Besitz oder eine eng begrenzte Bereitstellungsgruppe. Verwenden Sie keine weltweit beschreibbaren 777-Berechtigungen. Der Server sollte die symbolische Verknüpfung public/storage von Laravel zulassen, wenn öffentliche Medien die Standardfestplatte storage/app/public verwenden. Wenn symbolische Links nicht verfügbar sind, muss der Host eine gleichwertige Bereitstellungsvereinbarung für die öffentliche Festplatte bereitstellen.

Das Anwendungsstammverzeichnis .env, vendor/, storage/, .git/ und die Quelldateien dürfen nicht direkt über das Internet zugänglich sein. Anfragen wie /.env und /.git/config müssen 404 zurückgeben.

Der Server muss:

• Bestehende Dateien unten bereitstellenpublic/direkt und senden Sie andere Anfragen an Laravelpublic/index.php;
• Bewahren Sie HTTPS- und Hostinformationen über jeden Reverse-Proxy, damit Laravel korrekte sichere URLs generiert.
• Erlauben Sie dem CMS-Administrator unten/webadminund statische Paketressourcen unten/cmskoexistieren;
• Vermeiden Sie das Hinzufügen von apublic/cms/index.phpFront-Controller oder Behandlung/cmsals Admin-Route; Und
• Unterstützt die vom Betreiber für die Medienrichtlinie der Website ausgewählten Upload-Body-Größen und Anforderungs-Timeouts.

WebBlocks CMS veröffentlicht noch kein produktionszertifiziertes Minimum für PHP-Speicher oder Anforderungszeitlimit. Die jetzigeKapazitätsergebnisseRichten Sie einen provisorischen Kern PHP einmemory_limitKandidat mit 128 MiB und einem getesteten 512 MiB-Prozesskapazitätsprofil für einen 24 MP GD-Transformationsarbeiter. Letzteres ist nicht universell, da die Rasterpixelabmessungen derzeit unbegrenzt sind. Die aktuelle Obergrenze für die CMS-Medienvalidierung liegt bei 50 MiB pro Upload, und das paketnative System Update hat eine absolute Preflight-Untergrenze von 500 MiB für den freien Speicherplatz; Keiner der Werte allein stellt eine allgemeine Speicher-, Anforderungs- oder Speicherkapazitätsgarantie dar. Ein Anbietervorschlag muss seine tatsächlichen Grenzen angeben. VerwendenValidierung der Hosting-Kapazitätum arbeitslastgestützte Mindestanforderungen zu qualifizieren und zu veröffentlichen.

Fähigkeit

Hosting-Abhängigkeit

Bildvarianten

PHP GD mit dem erforderlichen JPEG-, PNG- oder WebP-Codec

Kontaktbenachrichtigungen und E-Mail zum Zurücksetzen des Passworts

Ein funktionierender Laravel-Mail-Transport und Provider-Anmeldeinformationen

Geplante Benachrichtigungen

Laravel schedule:run jede Minute; erforderlich für gebündelte/tägliche Kontakt- oder Live-Chat-Benachrichtigungen und tägliche Zusammenfassungen ausstehender Nachrichten. Erfordert außerdem funktionierende ausgehende E-Mails und einen gemeinsamen Cache mit Atomsperren, wenn mehrere Worker ausgeführt werden.

Geplanter Reinigungsservice

Derselbe Laravel-Scheduler; Nur optional, wenn keine aktivierte Funktion eine geplante Verarbeitung erfordert und eine manuelle Bereinigung ausreichend ist

Warteschlangen

Eigentum der Host-Anwendung; Für die synchrone CMS-Bildgenerierung oder öffentliche Suchindizierung nicht erforderlich

Paketnative Systemaktualisierungen

Ausgehendes HTTPS, ZIP und Natrium, Composer 2, proc_open, ausführbare Datei PHP/Composer, beschreibbare Anwendungs-/Updatepfade und ausreichend freier Speicherplatz für Download, Extraktion, Sicherung und Rollback

Native MySQL-Sicherung/Wiederherstellung

mysqldump oder mariadb-dump für den Export und mysql oder mariadb für den Import, verfügbar für den Prozess PHP

Remote-Medienimport

Ausgehendes HTTP/HTTPS unterliegt den CMS-Netzwerksicherheitsprüfungen und etwaigen Hosting-Firewall-Richtlinien

Ein Server darf das CMS nur dann ohne optionale Funktionen ausführen, wenn die entsprechende Funktion deaktiviert oder an anderer Stelle betriebsbereit ist. Die Einschränkung muss bei der Übergabe aufgezeichnet werden.

Die Hostanwendung muss über ein starkes APP_KEY, APP_DEBUG=false, ein korrektes öffentliches APP_URL, sichere Sitzungscookies über HTTPS, funktionierende Datenbankanmeldeinformationen und produktionsgerechte Sitzungs-/Cache-/Mail-Einstellungen verfügen. Geheimnisse gehören in die Umgebung und dürfen nicht über das Dokumentstammverzeichnis festgeschrieben oder offengelegt werden.

Die Hosting-Vereinbarung muss außerdem Folgendes festlegen:

• wie Datenbank und hochgeladene Dateien außerhalb der Anwendung gesichert werden;
• wie Releases bereitgestellt werden, wenn In-App-Updates nicht verfügbar sind;
• wie PHP-FPM oder der entsprechende Dienst neu geladen wird, wenn OPcache keine Zeitstempel validiert;
• wo Protokolle aufbewahrt werden und wie die Erschöpfung der Festplatte überwacht wird; Und
• Wer ist für die TLS-Erneuerung, die Datenbankwartung, die Wiederherstellungstests und die Reaktion auf Vorfälle verantwortlich?

Backups auf Anwendungsebene ersetzen keine Anbieter- oder Infrastruktur-Backups.

Bevor Sie einen Host genehmigen, überprüfen Sie die aktuellen Hosting-Kapazitätsergebnisse, wählen oder qualifizieren Sie ein getestetes Profil mithilfe der Hosting-Kapazitätsvalidierung und schließen Sie dann die Hosting-Bereitschaft ab Checkliste. Führen Sie nach der Bereitstellung Folgendes aus:

Dann überprüfen Sie die öffentliche Website, /webadmin/login, die statischen /cms-Assets, den Medien-Upload und alle aktivierten funktionsabhängigen Dienste. System Update verfügt über einen eigenen Pass/Fail-Preflight und darf nicht verfügbar bleiben, wenn eine seiner Anforderungen fehlschlägt.

Siehe auch Installation, Sicherheit, Operationen und Medienbild Varianten.