© Galyna Andrushko, 123RF

Lahmt die Performance des Webauftritts oder kommt es zu wiederholten Ausfällen, kann der Umzug in eine Public Cloud eine Lösung sein. Der behebt nicht nur die meisten dieser Probleme, sondern lässt sich oft auch recht schnell umsetzen. Vidya Mane beschreibt eine Drupal-Migration in Amazons Cloud.

Wer seine Website in die AWS-Cloud [1] schiebt, hat in der Regel Gründe dafür. In unserem Fall lahmte einerseits die in einem Rechenzentrum gehostete Drupal-Installation über Gebühr. Andererseits sollte der Schritt dafür sorgen, dass die Site automatisch skaliert, hochverfügbar ist und sich einfach verwalten lässt. In AWS klickt sich der Admin eine solche Umgebung mit recht wenig Aufwand zusammen – wenn er den Vendor-Lock-in nicht scheut.

Abbildung 1 zeigt den üblichen Status quo: Die Site läuft auf einem Server im Rechenzentrum, nutzt eine Datenbank und ist gewöhnlich über ein Internetgateway mit fester IP-Adresse zu erreichen. Entweder betreibt der Anbieter die Seite dabei selbst oder er greift auf einen Hosted Service zurück.

Abbildung 1: In traditionellen Website-Setups stecken in der Regel gleich mehrere Single Points of Failure.

In beiden Fällen gilt: Schwächelt eine der Komponenten, ist der Webauftritt nicht mehr zu erreichen. Zugleich sind Änderungen an so einer Umgebung aufwändig. Die Site im Einklang mit dem Development Stack zu halten, macht Arbeit. Auch skaliert das Szenario nicht automatisch: Fällt oder steigt die Serverload, muss der Admin manuell Änderungen an der Hardware vornehmen.

Nicht zuletzt können unerwartete (mitunter sogar erwartete) Traffic-Spikes zu Server-Überlastungen und -Ausfällen führen. Mit der Wahl einer passenden Architektur in Amazons Cloud lassen sich solche Szenarien vermeiden – allerdings nicht mit jedem Setup.

Lift & Shift

Mindestens zwei Wege führen vom eigenen Server in die Cloud. Der erste heißt Lift und Shift. Dabei tritt AWS als ein gewöhnlicher Hoster auf. Es reicht dann, den Webserver zusammen mit seinen Abhängigkeiten in eine einzelne Instanz von Amazons Elastic Compute Cloud (EC2) zu verschieben und mit dem Relational Database Service (RDS) zu verbinden, um dort die Daten zu lagern. Anschließend lässt sich die Website über das Internet erreichen.

Viel gewonnen ist mit dieser Hauruck-Migration allerdings nicht: Die Site ist nach wie vor weder hochverfügbar noch skaliert sie automatisch.

Verteilte AWS-Anwendung

Der Artikel konzentriert sich auf einen zweiten Ansatz, der auch die oben erwähnten Probleme aus der Welt schafft. Er migriert nicht nur die Anwendung und ihre Abhängigkeiten in die Cloud, sondern setzt zudem auf Load Balancer und das Konzept der AWS-Regionen und Availability Zones (AZ).

Abbildung 2: Sieht kompliziert aus, ist aber recht einfach einzurichten: Die Architektur für eine hochverfügbare und skalierbare Site in AWS.

AWS-Regionen bestehen aus mehreren AZs, unabhängigen Rechenzentren. Die kommunizieren miteinander, als würden sie sich im selben Netzwerk befinden. Fällt ein Server oder gar eine ganze AZ aus, leitet der Load Balancer den Traffic an eine andere AZ um, wo bereits eine Kopie der Drupal-Installation darauf wartet, den Job zu übernehmen. In diesem Szenario installiert der Admin Server in mehreren AZs und weist den Load Balancer auf deren IP-Adressen hin.

Betreutes administrieren

Die Architektur in Abbildung 2 sieht vielleicht etwas kompliziert aus, ist aber relativ einfach zu erzeugen. Der Elastic-Beanstalk-Service (EB) hilft dabei, sie umzusetzen. Alternativ besteht die Möglichkeit, die Komponenten als AWS-Cloudformation [2] zu beschreiben – diesen eher für größere Setups praktischen Weg deckt der Artikel aber nicht ab. Welche anderen Dienste an dem Szenario beteiligt sind, zeigt Tabelle 1.

RDS-Datenbank

Zunächst gilt es, eine RDS-Datenbank aufzusetzen. Dabei legt der Admin eine externe Datenbank an und verbindet sie später mit der in Elastic Beanstalk erzeugten Anwendung. Beanstalk selbst unterstützt ebenfalls einige Datenbanken, darunter MySQL, PostgreSQL, Oracle und SQL-Server. Ob der Admin sich für eine davon oder eine externe Datenbank entscheidet, steht ihm frei. Wichtig: Externe Datenbanken verschwinden nicht einfach, wenn der Admin später die Beanstalk-Anwendung entfernt, er muss sie separat löschen.

Um die RDS-Instanz zu erzeugen, wechselt der Admin in die AWS-Konsole, fahndet in der Servicesuche nach RDS. Ein Klick darauf bringt ihn zunächst zu einer »Get Started«-Seite. Hier klickt er auf den Button »Create Database« und wählt die passende Engine für die Drupal-Installation – in meinem Fall MySQL.

Dann sucht der Admin einen Use Case für die Datenbank aus. Für Tests genügt die Option »Dev/Test«. Wer eine Drupal-Installation umziehen möchte (oder ein anderes CMS mit Datenbank), muss darauf achten, die zur Drupal-Version passende Datenbank-Version auszusuchen – andernfalls drohen Fehler.

Wer die Datenbank zu groß wählt, erhält am Monatsende womöglich eine deftige Rechnung. Details wie den Namen der Datenbank-Instanz, den Benutzernamen und das Passwort für den Datenbank-Zugriff muss der Admin notieren. Sie landen später in Elastic Beanstalk, um dort die Integration von Anwendung und Datenbank anzustoßen.

Dann ruft er die erzeugte Datenbank auf, klickt auf »Security Group«, dann »Edit« und »Add Inbound Rule«. Als »Type« pickt er die zuvor bestimmte Datenbank-Engine heraus. Den in der »Security Group« versammelten Ressourcen erlaubt er, Traffic von anderen Ressourcen auf dem Datenbank-Port zu empfangen.

Auf die Bohnenranke

Zunächst erzeugt der Admin die Infrastruktur für die Drupal-Anwendung. Unter Elastic Beanstalk gilt es dabei, mehreren Schritten zu folgen und keinen zu vergessen. Beim ersten sucht er in der AWS-Konsole nach »Elastic Beanstalk« und klickt dann auf »Create New Application«. Er gibt einen Namen und eine Beschreibung für die Anwendung an und kümmert sich im Anschluss um die passende Umgebung für sie. Dafür stellt Beanstalk mehrere Optionen bereit, der Admin entscheidet sich für die Variante »Webserver-Environment«.

Elastic Beanstalk erzeugt dann Cnames (Canonical Name Records, [3]) für die Anwendung, um die zugehörige Webseite auch über das Internet zu erreichen. Das übliche Format für einen Cname-Eintrag folgt dabei dem Schema ».Name der Region.elasticbeanstalk.com«. Der Domainname lässt sich später über Amazons Route-53-Dienst verändern.

Dann sucht der Admin die zu seiner Drupal-Installation passende PHP-Version aus. Keine Panik, falls die Auswahl es nicht erlaubt, eine bestimmte Version zu wählen – das klappt über den Bereich »Configure More Options«.

An dieser Stelle lässt sich auch ein Load Balancer einrichten. Dazu wählt der Admin die High-Availability-Option, die automatisch einen Load Balancer für die gewählte Umgebung einrichtet. Abschließend folgt noch ein Klick auf »Create Environment Option«.

Elastic Beanstalk erzeugt nun alle Ressourcen, die die Anwendung benötigt. Das dauert ein paar Minuten. Läuft die Anwendung, färbt sich das zugehörige Symbol grün (Abbildung 3), läuft sie nicht, sieht es grau aus. Ein rotes Symbol zeigt an, dass die Anwendung Probleme hat, etwa beim Datenbankzugang.

Abbildung 3: Die Testanwendung läuft, zu sehen an der grünen Farbe.

Stehen die Zeichen auf Grün, kann der Admin die Konfiguration ändern. Dazu reicht er die vorhin notierten Zugangsdaten der RDS-Datenbank an die Elastic-Beanstalk-Anwendung weiter. Hier genügt ein Klick auf die Anwendung, dann rechts auf die »Configuration«-Option. Er wechselt zum Software-Tab, trägt die Eigenschaften aus Tabelle 2 ein (Abbildung 4) und klickt auf »Apply«.

Drupal zieht um

Ist die Datenbank erfolgreich konfiguriert, lässt sich Drupal selbst installieren. Um ein Drupal-Projekt in Elastic Beanstalk anzulegen, muss der Admin zunächst den Quellcode von Drupal herunterladen und ihn mit den Konfigurationsdateien von Elastic Beanstalk kombinieren. Da es sich um eine existierende Drupal-Installation handelt, sichert er diese zunächst über ein Backup-Tool [4].

Abbildung 4: Um die Datenbank in Amazon RDS zu reproduzieren, sind die Zugangsdaten nötig.

Dann schiebt er die daraus resultierenden Dateien, darunter ein Dump der Datenbank, auf den lokalen Rechner und entpackt sie etwa in einen Ordner »mein_drupal_backup«. Danach holt er die von Amazon für Elastic Beanstalk angebotenen Konfigurationsdateien für »php-drupal« von Github:

wget https://github.com/aws-samples/eb-php-drupal/releases/download/v1.1/eb-php-drupal-v1.zip

Mit diesen überschreibt er die zuvor entpackten Dateien im Ordner »mein_drupal_backup«. Dadurch landet unter anderem die Datei »beanstalk-settings.php« in dem Ordner. Sie enthält Einträge für die in Tabelle 2 definierten Datenbank-Zugangsdaten.

Daneben landet ein versteckter Ordner ».ebextensions« im Drupal-Backup-Ordner. In ihm stecken Konfigurationsdateien, die weitere Ressourcen für die Elastic-Beanstalk-Umgebung bereitstellen. Von denen passt der Admin nun zwei an. Bei ».ebextenstion/dev.config« beschränkt er den Zugriff auf die IP-Adresse während der Drupal-Installation. Dazu ersetzt er den Eintrag »MyIP« mit der IP-Adresse der in Elastic Beanstalk erzeugten EC2-Instanz.

Die Konfigurationsdatei unter ».ebextension/efs-create.config« erzeugt ein EFS-Dateisystem und Einhängepunkte in jeder AZ und jedem Subnetz in der Virtual Private Cloud (VPC, [5]). Die verwendeten VPCs und Subnetz-IDs schaut der Admin in Amazons VPC-Konsole nach.

Abbildung 5: Die fertig gebündelten Komponenten verpackt der Admin in einer Zip-Datei und lädt sie in Amazons Cloud.

Hat er die Dateien geändert, bündelt er das zugehörige Verzeichnis »mein_drupal_backup« als Zip-Datei, lädt diese in Beanstalk hoch und bereitet sie auf das Deployment vor (Abbildung 5).

Neuer Anschluss

Nach dem erfolgreichen Upload ruft er die Environment-URL auf, um die Seite im Browser zu betrachten. Zunächst erscheint aber Drupals Installations-Assistent, weil die Seite noch nicht konfiguriert ist. Der Admin trägt den Datenbank-Namen aus der RDS-Konsole sowie den selbst erzeugten Username und das Passwort ein (Tabelle 2). Unter »Advanced Options | Host« gehört der »Endpoint« der DB-Instanz, den ebenfalls die RDS-Konsole zeigt. Die Installation inklusive der Module dauert ein paar Minuten.

Nun gilt es, die zuvor exportierten Daten in die AWS-Datenbank zu holen:

mysql -h RDS_HOSTNAME -u RDS_USERNAME -p RDS_PASSWORD

Der Befehl stellt eine Verbindung zur RDS-Datenbank her. Anschließend holt der Admin die Daten aus der alten Datenbank über das SQL-Dumpfile in die neue. Dieser Import funktioniert über den »source«-Befehl.

Am Ende geht es daran, die Auto Scaling Group für die Hochverfügbarkeit der aufgesetzten Umgebung einzurichten. Als Minimum sollten zwei Instanzen die ganze Zeit über laufen, um einen Single Point of Failure zu vermeiden. Auch bei Updates muss die Seite dann nicht vorübergehend vom Netz.

Dazu ruft der Admin zunächst die Beanstalk-Konsole auf, wechselt zur Konfigurationsseite des eigenen Setups und dort zum Reiter »Capacity Configuration«. Ein Klick auf »Modify« führt zur »Auto Scaling Group«-Sektion, wo er das Minimum an Instanzen auf »2« setzt und »Apply« klickt. Der Load Balancer leitet den Verkehr fortan Traffic-bedingt an eine der beiden Instanzen.

Damit der Content-Upload über mehrere Instanzen hinweg funktioniert, kommt das bereits erwähnte Elastic Filesystem (EFS) zum Einsatz. Es erlaubt nicht nur parallele und geteilte Zugriffe auf mehrere Instanzen, sondern wächst und schrumpft auch dynamisch, abhängig von der Menge an Daten.

Mit TLS abgesicherte HTTPS-Verbindungen lassen sich zum Load Balancer aufbauen, aber auch zu den einzelnen Instanzen. Im Beispiel endet der HTTPS-Support beim Load Balancer. Wer ein eigenes Zertifikat verwenden will, muss es zunächst über den AWS-Zertifikatmanager (ACM) importieren. Es taucht später im Load-Balancer-Menü auf.

Letzteres erreicht der Admin, indem er in der AWS-Konsole die Beanstalk-Seite für die Anwendung aufsucht. Auf der Konfigurationsseite fahndet er nach dem Reiter für die Load-Balancer-Einstellungen und klickt auf »Modify«. Nun lassen sich über »Add Listener« Instanzen eintragen. Er wählt für den Load Balancer »Port 443« und »HTTPS« als Protokoll, für die Instanz hingegen »Port 80« und »HTTP«. Aus dem Drop-down-Menü fügt er das zuvor hochgeladene Zertifikat hinzu.

Schließlich ist es an der Zeit, die DNS-Einstellungen für die EB-Anwendung einzurichten. Das soll den Traffic an die neuen Domainnamen weiterleiten. Der Cname-Eintrag muss dabei dem entsprechen, den auch das SSL-Zertifikat verwendet, andernfalls droht ein Common-Name-Mismatch-Fehler.

Um Traffic umzuleiten, lässt sich Route 53 verwenden, der DNS-Dienst von Amazons Cloudservice. Der Admin muss den Alias Record Set für den DNS setzen und als Alias Target den Load-Balancer-DNS einfügen. Nach dem Speichern der Änderungen gibt er den DNS-Namen im Browser ein und sollte nun die Seite sehen.

Grün und Blau

AWS EB nimmt ein In-place-Update vor: Aktualisiert der Dienst die Anwendungsversion, ist die Anwendung für User zeitweise nicht erreichbar. Ein Blau-Grün-Setup vermeidet das. Liefert der Admin für die Webseite ein neues Feature aus, tut er das in einer komplett neuen Umgebung. Dann tauscht er einfach die Cname-Einträge für beide Umgebungen aus, um den Traffic auf die aktualisierte Version umzuleiten.

Für die Drupal-Installation klont er die Anwendung in EB und lädt die aktualisierte Anwendung in die geklonte Umgebung. Er testet sie und wählt dann im Dashboard »Aktionen | Swap Environments URLs« (Abbildung 6).

Abbildung 6: In einem Blau-Grün-Setup lassen sich Updates ohne Ausfallzeiten realisieren. Es genügt, nach einer Aktualisierung die Umgebungs-URLs umzuschalten.