Automatisierte Anwendungsbereitstellung unter AWS, Teil 2 PHP-Applikation bei AWS Elastic Beanstalk launchen

Mit AWS Elastic Beanstalk können Entwickler ihre Anwendung einfach in der Cloud bereitstellen. Der Service verwaltet automatisch Kapazitätsbereitstellung, Lastverteilung, automatische Skalierung und Statusüberwachung. Wie das z. B. mit einer PHP-Anwendung funktioniert, zeigt dieses Beispiel.

Anbieter zum Thema

Windhoff Group

Amazon Web Services Germany GmbH

Der Einsatz von Elastic Beanstalk ist einfach, setzt sich aus drei Schritten zusammen und lässt sich komplett über die AWS Management Console steuern. Im ersten Schritt wählt der Nutzer seine bevorzugte Ziel-Plattform aus, danach lädt er seine Anwendung hoch und führt sie schließlich aus.

Im EC2-Dashboard beginnt der erste Schritt. Hier wählt man „Elastic Beanstalk“ und dann im Menü „Actions“ den Eintrag „Create Environment“. Der Nutzer hat hier die Wahl zwischen „Create web server“ oder „Create worker“. Hat man sich dann z. B. für eine „Web server“-Environment entschieden, sucht man sich die gewünschte Plattform aus den Bereichen „Preconfigured“, „Preconfigured - Docker“ oder „Generic“ aus. Im gleichen Dialog bei „Environment type“ muss sich der Entwickler dann noch zwischen „Load balancing, autoscaling“ oder „single instance“ entscheiden.

Der zweite Schritt des Beanstalk-Assistenten stellt dann die entscheidende Frage nach der „Application Version“. Hier hat der Entwickler drei Möglichkeiten, seine Applikation in Elastic Beanstalk bereitzustellen. Er kann z. B. mit „Existing application version“ eine bereits vorhandene Applikation angeben. Darüber hinaus kann er seinen eigenen Applikations-Code entweder als Datei hochladen („Upload your own“) oder ein S3-Bucket angeben, in dem der gewünschte Code gehostet ist.

Das Erstellen eines solchen Applikations-Bundles unterliegt nur wenigen Einschränkungen. Der Code muss dazu in Form einer ZIP- oder WAR-Datei bereit stehen und darf die Größe von 512 MB nicht überschreiten. Wenn der Nutzer seine Anwendung mit Hilfe des Elastic Beanstalk Command Line Interface (EB CLI) zusammen dem AWS Toolkit für Eclipse oder dem AWS Toolkit für Visual Studio einsetzt, wird die ZIP- oder WAR-Datei übrigens automatisch korrekt strukturiert. Auch aus einem Git-Repository heraus lässt sich ein passendes ZIP wie folgt leicht erzeugen:

Als Beispiel für ein einfaches PHP-Deployment soll nun der PHP-Code von WordPress bereitgestellt werden. Vor dem Hochladen jedoch muss/kann sich der Entwickler eine passende Konfiguration für ein WordPress/PHP-Setup von AWSLabs herunterladen. Die darin enthaltenen Konfigurationsdateien entpackt er im gleichen Verzeichnis auf dem lokalen Rechner, in dem er auch das Wordpress-Zip entpackt hat und passt die Konfigurationsdateien im Unterverzeichnis“.ebextensions“ an die PHP-Umgebung in EB an, was z. B. die ID der verwendeten VPCs und Subnetze sowie die verwendeten Public-IPs betrifft.

Hat man die entsprechenden Anpassungen vorgenommen, verspackt man das ZIP erneut und lädt es im Punkt 2 des Elastik-Beanstalk-Assistenten hoch. In der Beanstalk-Dokumentation findet sich unter u. a. auch ein Tutorial, wie man ein hochverfügbares Multi-AZ-Wordpress-Deployment mit Beanstalk erstellt und an eine vorhandene externe RDS-Instanz anschließt.

Hat der Entwickler dann im vierten Schritt einen Environment-Namen nebst Environment-URL vergeben, widmet sich der Elastic-Beanstalk-Assistent in Schritt fünf „Additional Ressources“ dem Einbinden zusätzlicher Ressourcen, etwa weiteren Datenbank-Instanzen. Außerdem kann der Entwickler an dieser Stelle durch Setzen der entsprechenden Option dafür sorgen, das Deployment „in“ ein vorhandenes VPC zu platzieren, was dann mit den Einstellungen in der oben beschriebenen Wordpress-Environment-Config übereinstimmen sollte.

Anwendungsbereitstellung unter AWS automatisieren, Teil 1

Grundlagen und Zweck von AWS Elastic Beanstalk

Weiter geht es in den „Configuration Details“ mit dem konkret zu verwendenden Instanz-Typ. Außerdem kann man hier den zu verwendenden EC2-Key-Pair bestimmen, den Level für das Health-Reporting einstellen (Basic, Enhanced) und den Typ des root-Volumes auswählen. Dieser ist bei Elastic Beanstalk per Default ein Container, kann aber auch eine SSD (ggf. mit „provisioned IOPS) oder eine magnetische Disk sein. Außerdem gibt man hier die Größe des root-Volumes an, falls dies über die Voreinstellung hinausgehen soll.

Im nächsten Schritt vergibt der Entwickler bei Bedarf die gewünschten Environment-Tags und widmet sich danach der RDS-Konfiguration. Wie bei der EC2-Konfiguration unterscheidet sich auch dieser Schritt nicht vom manuellen Vorgehen bei RDS.

Der letzten Konfigurationsschritt dreht sich um die gewünschten Berechtigungen, wobei der Nutzer bei Bedarf eine IAM-Rolle für das „Instance profile“ festlegen sowie ggf. das Anlegen einer „Service role“ für das Monitoring erzwingen kann.

Nach der obligatorischen Anzeige der Zusammenfassung ist das neue Deployment nach einem Klick auf „Launch“ nach wenigen Minuten im EB-Dashboard verfügbar. Ausgehend vom Elastic Beanstalk-Dashboard lässt sich das Deployment dann in den Menüs „Configuration“, „Logs“, „Health“, „Monitoring“, „Alarms“, „Managed Updates“, „Events“ und „Tags“ verwalten, anpassen oder aktualisieren.

Dieses und weitere interessante Deployment-Beispiele – nicht nur für PHP – demonstrieren wir im dritten Teil dieses Beanstalk-Workshops. Übrigens stellt auch AWS selbst zahlreiche Elastic-Beanstalk-Tutorials online zur Verfügung.

(ID:44964396)