• Apr. 12, 2018
  • --

Bereitstellung von Magnolia CMS in einer Cloud-Infrastruktur

In diesem Blog von Abhay Kumar von Priocept werden einige Herausforderungen bei der Bereitstellung von Anwendungen auf automatisch skalierenden Cloud-Infrastrukturen wie Amazon Web Services (AWS) oder Google Cloud Platform (GCP) vorgestellt.

Einer der wichtigsten technischen Vorteile des Cloud-Hostings gegenüber der herkömmlichen Infrastruktur vor Ort ist die Möglichkeit, die Anzahl der Server automatisch nach oben und unten zu skalieren, um der Verkehrslast gerecht zu werden. Diese Flexibilität bietet eine kosteneffiziente Möglichkeit zur Bewältigung von Spitzenbelastungen der Website.

Das transaktionale Publikationsmodell von Magnolia ermöglicht die physische Trennung von Webinhalten zwischen der "Autoren"- und der "öffentlichen" Infrastruktur, wobei die Inhalte gemäß den definierten Publikations-Workflows von den Autorenservern auf die öffentlichen Server übertragen werden. Das transaktionale Aktivierungsmodul stellt sicher, dass eine beliebige Anzahl öffentlicher Instanzen mit den endgültigen, veröffentlichten Inhalten, wie von den Autorenservern definiert, synchron gehalten werden.

Dieses Modell bietet eine saubere und effiziente Lösung, birgt jedoch einige Herausforderungen bei der Bereitstellung von Anwendungen in einer automatisch skalierenden Cloud-Infrastruktur wie Amazon Web Services (AWS) oder Google Cloud Platform (GCP). Dieser Blog untersucht die Probleme und beschreibt den High-Level-Prozess, den Priocept implementiert hat, um diese Herausforderungen zu meistern. Eine ausführlichere Erklärung finden Sie in unserem jüngsten Webinar zu diesem Thema.

Abonnenten, die kein Abonnement abgeschlossen haben

Server, die Inhalte bereitstellen (öffentliche Instanzen), werden in der Magnolia-Terminologie als "Abonnenten" bezeichnet, da sie dazu bestimmt sind, Inhalte vom Autorenserver zu empfangen. Das Abonnement wird jedoch auf dem Autorenserver eingerichtet, und die Abonnenten selbst haben keine Kenntnis von der Existenz ihrer eigenen Abonnements.

Wenn ein Veröffentlichungsereignis (auch als "Aktivierung" bezeichnet) vom Autorenserver ausgelöst wird, wird ein Inhaltsobjekt erstellt und physisch über HTTP an jeden abonnierenden Server gesendet, der dann den neuen Inhalt in seine öffentliche (Live-)Datenbank importiert.

Abbildung 1: Publikationsmodell für Magnolia-Abonnenten

Magnolia-Veröffentlichungsmodell

Dieser Prozess funktioniert gut in einer vordefinierten Infrastrukturkonfiguration, in der der Autor alle abonnierten Instanzen kennt und neue Instanzen entweder nie hinzugefügt oder entfernt werden oder manuell hinzugefügt und entfernt werden - zum Beispiel über einen IT-Änderungsantragsprozess, möglicherweise mit einer Durchlaufzeit von mehreren Tagen.

Bei Verwendung einer Infrastructure-as-a-Service-Cloud-Plattform bedeutet die ephemere Natur von Cloud-Servern, dass neue öffentliche Instanzen jederzeit vollautomatisch als Teil von Auto-Scaling-Ereignissen, Bereitstellungen oder Patching-Prozessen, die vom Cloud-Infrastruktur-Framework verwaltet werden, erstellt und entsorgt werden können.

In diesem Szenario erfordert der Einsatz einer Standard-Magnolia-Lösung in einer Cloud-Infrastruktur zusätzliche Entwicklungsarbeit, um Magnolia in das Cloud-Framework zu integrieren, das die Erstellung und Beendigung neuer öffentlicher Instanzen orchestriert. Andernfalls verlieren die Magnolia-Autorenserver den Überblick darüber, welche öffentlichen Server existieren.

Das folgende Diagramm veranschaulicht das Problem. Es zeigt, dass der Public Web Server 3 vor kurzem im Rahmen eines automatischen Skalierungsprozesses erstellt wurde. Dies könnte durch einen plötzlichen Anstieg des Datenverkehrs auf der Website, die diese Magnolia-Instanz hostet, verursacht worden sein.

Ein Load Balancer sitzt vor den öffentlichen Webservern. Wenn er die neue Instanz in die Last einbringt, wird die neue öffentliche Instanz nicht den neuesten Inhalt oder überhaupt keinen Inhalt enthalten und daher eine leere Website für 1/3 der Website-Nutzer bereitstellen.

Figure 2: Auto-scale event

Lösung

Das folgende Diagramm beschreibt die erforderliche Orchestrierung zwischen Magnolia und Amazon Web Services, um eine vollständig elastische Lösung zu erreichen. Das Ziel ist es, die neuen öffentlichen Webserver nur dann für die Bereitstellung der Website verfügbar zu machen, wenn die neuesten Inhalte auf ihnen veröffentlicht wurden.

Figure 3: Auto-scaling Magnolia Public instances

Das obige Diagramm zeigt einen "Lifecycle Hook", der für die EC2 Auto-Scale Group in AWS konfiguriert wurde. Dieser löst Ereignisse aus, wenn neue Magnolia EC2-Instanzen erstellt oder beendet werden, indem eine Lambda-Funktion über SNS (Simple Notification Service) aufgerufen wird.

Die Aufgabe der Lambda-Funktion ist es, Magnolia aufzurufen, um mitzuteilen, dass eine neue Instanz hinzugefügt oder entfernt wurde. Wurde eine neue Instanz hinzugefügt, wird der Inhalt mithilfe des Magnolia-Synchronisierungsmoduls auf dem neu erstellten Magnolia Public Server veröffentlicht.

Eine Healthcheck-Konfiguration der Auto-Scaling Group wird verwendet, um den Status des öffentlichen Servers zu überprüfen. Dazu wird ein REST-Endpunkt auf dem neuen Magnolia Public Server aufgerufen, der den Status des Servers zurückgibt (200, wenn er die neuesten Inhalte enthält).

Dieser Prozess erfordert die Entwicklung maßgeschneiderter Dienste sowohl in der Cloud-Infrastruktur als auch in Magnolia, automatisiert jedoch den Prozess der automatischen Skalierung vollständig und bietet eine Content-Management-Infrastruktur, die sowohl hochgradig belastbar als auch in der Lage ist, horizontal zu skalieren, um große Datenmengen zu liefern.

Zusammenfassung

Magnolia ist eine von Natur aus Cloud-freundliche Plattform, die häufig bei Amazon Web Services eingesetzt wird. Um die Vorteile dieser Plattformen voll auszuschöpfen, empfiehlt Priocept, den oben beschriebenen Ansatz in Betracht zu ziehen.

Priocept unterstützt seine Unternehmenskunden aus den Bereichen Reise, Medien und Unterhaltung, Einzelhandel und Finanzdienstleistungen bei der Entwicklung ihrer Magnolia-Lösungen auf AWS. Wenn Sie Beratung zum Hosting von Magnolia auf einer Cloud-Infrastruktur oder allgemeine Beratung zu Cloud-Diensten benötigen, nehmen Sie bitte Kontakt auf.

Priocept ist offizieller Beratungspartner für Magnolia, Amazon Web Services und Google Cloud Platform.

Über den autor

Abhay Kumar

Head of Project Delivery, Priocept

Abhay is Head of Project Delivery at Priocept and has over 18 years’ experience of enterprise web application delivery. He is responsible for ensuring the effective delivery of all Priocept projects, including Magnolia implementations. He draws on his technical background to design and develop effective Magnolia solutions.