Self-Hosted Deployment

Hardware-Empfehlungen sind abhängig von der Art und Weise, wie die Anwendung gehostet wird, da der zugrunde liegende Stack (d.h. Hypervisor / OS / Containerization Stack) berücksichtigt werden muss.

Die empfohlenen Spezifikationen für die Anwendung selbst (im Produktionsmodus) sind:

• CPU: 4vCPU
• Speicher: 12GB für die Autoreninstanz, 8GB/Instanz für Publics
• Speicherplatz: Mindestens 30GB. Diese Größe hängt von der Menge der Inhalte (Seiten/Assets) ab, die gespeichert werden sollen, und kann von Projekt zu Projekt variieren. Darüber hinaus kann externer Speicher (z.B. S3 oder Azure Blobs) für die Speicherung von Assets verwendet werden.

Die Magnolia-Anwendung ist OS-agnostisch. Weitere Einzelheiten entnehmen Sie bitte dem zertifizierten Stack für weitere Details.

Die Abhängigkeiten finden Sie in unserer Dokumentation auf der zertifizierten Stack Seite. Kurz gesagt, werden folgende Komponenten benötigt:

• Eine Datenbank (die unterstützten Optionen sind in der Dokumentation zu finden)
• Eine Java-Laufzeitumgebung (Java 11 oder Java 17)
• Ein Anwendungsserver (vorzugsweise Tomcat oder JBoss EAP)
• Außerdem empfehlen wir dringend, die Anwendung hinter einer Firewall (WAF) und einem LoadBalancer / Reverse Proxy zu hosten.

Am besten verwenden Sie einen Technologie-Stack, mit dem Ihre Ingenieure vertraut sind. Unsere Empfehlungen sind:

• Tomcat als Anwendungsserver
• Nginx als möglicher Reverse-Proxy-Server (falls die Zielarchitektur diese Komponente erfordert).

Das hängt von der verwendeten Technologie ab. Im Allgemeinen kann dies mehr Rechenressourcen (v)CPU, Speicher und Storage bedeuten, um mehr Magnolia Public Instances zu berücksichtigen.

Dies hängt von den Entscheidungen über die On-Premise-Architektur ab.

Dies hängt von dem Stack ab, der zum Hosten der Anwendung verwendet wird. Der Betrieb bleibt in der Verantwortung des Kunden.

Wir empfehlen regelmäßige Backups (oder Snapshots) der Festplatten für den Anwendungsserver und mögliche Speicherbereiche (externe / Netzlaufwerke) sowie Backups auf Anwendungsebene für die Datenbankschicht.

Wir empfehlen die regelmäßige Sicherung des Betriebssystems und des Anwendungsstapels in Übereinstimmung mit den internen IT-Richtlinien des jeweiligen Unternehmens.

Die Datenbank sollte regelmäßig gesichert werden (typischerweise einmal pro Tag oder einmal pro Woche), je nach den erforderlichen RTO / RPOs.

 Bei der Verwendung von PSQL als Backing-RDBMS werden beispielsweise “Basebackups” in der Regel einmal pro Woche durchgeführt, mit regelmäßiger WAL-Archivierung (Timeout definierbar je nach den erforderlichen RPOs). Dieselbe Richtlinie sollte auf jedes externe (entfernte) Dateisystem (z. B. S3-Speicher / Azure Blob) angewandt werden, falls zutreffend.

Magnolia unterscheidet sich nicht von anderen Webanwendungen und sollte entsprechend gehostet werden. Bitte lesen Sie den Abschnitt Magnolia PaaS in dieser Frage für weitere Details.

Wir empfehlen dringend die Verwendung von “Security hardened” (d.h. OWASP) Reverse Proxies, Load Balancern, Webservern. Darüber hinaus wird der Einsatz einer WAF dringend empfohlen.

Nicht anwendbar, da das Hosting und der Betrieb der Anwendung in der Verantwortung des Kunden liegen.

Bei den zertifizierten Stacks finden Sie die verfügbaren Optionen. Kurz gesagt, sind MySQL, MariaDB, Oracle, H2 und PostgreSQL die am häufigsten verwendeten Produkte. PostgreSQL ist das bevorzugte RDBMS.

Es gibt keine spezifischen Anforderungen für die Integration eines CDN. Die Caching-Richtlinien müssen auf Magnolia-Ebene festgelegt werden.

Nicht anwendbar, da das Hosting und der Betrieb der Anwendung in der Verantwortung des Kunden liegen.

Jedes VCS kann verwendet werden. Üblicherweise werden TFS, AzureDevOPS und Git verwendet.

Es gibt keine spezifischen Anforderungen, da Magnolia in Bezug auf Integrationen sehr flexibel ist. Die Integration erfolgt meist über REST-APIs, aber je nach Drittsystem können auch andere Technologien verwendet werden.

Die Replikation von Inhalten ist auf JCR-Arbeitsbereichsebene möglich, indem ausgewählte Elemente oder ganze Arbeitsbereiche in XML oder YAML exportiert werden.

Magnolia ist sehr flexibel, was die Authentifizierung und Autorisierung von Benutzern angeht. Die Autorisierung bleibt typischerweise innerhalb von Magnolia (auch wenn sie extern verwaltet wird) und kann entweder “lokal” in Magnolia bleiben oder “extern” über die Verwendung des SSO-Moduls.

Das SSO-Modul unterstützt nativ Open ID Connect kompatible Identitätsprovider (Azure AD oder gleichwertig) und kann durch Verwendung eines Identitätsbrokers wie Keycloak auf andere Protokolle (z.B. LDAP / SAML) erweitert werden.