Deliver Faster by Design
How your tools make (or break) a culture of shipping.
Hosten Sie Ihre eigenen Magnolia-Instanzen vor Ort oder in der Cloud für maximale Flexibilität.
Magnolia gibt es als Softwarepaket certified für Linux, Windows und MacOS. Dadurch kann es überall installiert werden – auf Ihrem Computer, in Ihrem Rechenzentrum oder auf Ihrer bevorzugten Cloud-Plattform.
Möchten Sie Magnolia in Ihrer Umgebung lieber als Docker-Container bereitstellen? Die Best Practices in unserem Whitepaper helfen Ihnen, die richtigen Komponenten für Ihren Magnolia Container auszuwählen, Ihren Container für den automatischen Start zu konfigurieren, Content zu containerisieren und Content in allen Instanzen zu synchronisieren.
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:
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:
Am besten verwenden Sie einen Technologie-Stack, mit dem Ihre Ingenieure vertraut sind. Unsere Empfehlungen sind:
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.