DevOps-Workflow mit AWS CodeDeploy, Teil 1 Automatisierte Wordpress-Bereitstellung unter AWS

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Mit AWS CodeDeploy hat die Public Cloud-Sparte von Amazon einen Dienst im Portfolio, mit dessen Hilfe Entwickler das Bereitstellen und Aktualisieren von Anwendungen auf beliebigen Instanzen automatisieren kann. Dieser Workshop demonstriert eine automatisierte Wordpress-Bereitstellung auf virtuellen Servern in Amazon Web Services.

Instanzen dürfen in CodeDeploy virtuelle Maschinen in AWS (Amazon EC2) sein, aber auch lokale Server und solche, die in einer anderen Cloud oder auf einem anderen Hypervisor laufen. AWS CodeDeploy unterstützt eine große Anzahl an Betriebssystemen. Voraussetzung ist je ein von AWS CodeDeploy verfügbarer und installierter Agent.

AWS stellt getestete Agenten für Amazon Linux, Red Hat Enterprise Linux, Ubuntu Server und Microsoft Windows Server zur Verfügung. Für viele weitere Betriebssysteme steht der AWS CodeDeploy-Agent auf GitHub als Open-Source-Software zum Download zur Verfügung. Allgemein unterstützt CodeDeploy sämtliche Instanzen, die über den Agenten verfügen und sich mit öffentlichen Endpunkten von AWS verbinden können.

Entwickler können mit AWS CodeDeploy sehr schnell neue Funktionen freigeben, was Ausfallzeiten im Verlauf der Bereitstellung minimiert; dies gelingt unter anderem, weil das Tool komplexe Aktualisierungen bestehender Anwendungen einfacher und etwaige fehleranfällige manuelle Operationen obsolet macht. Der Service ist komplett von AWS verwaltet und skaliert automatisch mit der Infrastruktur. So ist es problemlos möglich, Code für Tausende von Instanzen genauso einfach bereitstellen zu können wie für eine einzige.

AWS CodeDeploy funktioniert zudem problemlos zusammen mit vielen Konfigurationsmanagement-Systemen, Continuous-Integration- und Continuous-Deployment-Tools und Source-Code-Control-Systemen. So kann CodeDeploy den Quellcode beispielsweise aus Amazon S3-Buckets, Github- oder Bitbucket-Repos beziehen. Aufschluss darüber gibt die AWS-Seite zu Produktintegrationen. Entwickler nutzen CodeDeploy hauptsächlich zur Freigabe neuer App-Versionen, deshalb spielt das Tool eine wichtige Rolle beim Application Lifecycle Management (ALM).

Da sich neue Software-Releases auch mit AWS Elastic Beanstalk oder AWS OpsWorks automatisiert bereitstellen lassen, stellt sich vielen Lesern womöglich die Frage nach dem Unterschied. Diese ist einfach zu beantworten: Während AWS Elastic Beanstalk und AWS OpsWorks End-to-End-Anwendungsverwaltungssysteme sind, funktioniert AWS CodeDeploy nach einer Art Baukasten-Prinzip. Dieses hilft Entwicklern, Software auf beliebigen Instanzen bereitzustellen, einschließlich lokalen Servern. Mit CodeDeploy ist es sogar möglich, serverlose Lambda-Funktionen bereitzustellen.

CodeDeploy erlaubt es außerdem, die Bereitstellung und Revision von Applikationen auf EC2-Instanzen an ein spezifisches virtuelles Netzwerk im Kontext der Amazon Virtual Private Cloud (VPC) zu koppeln. Dies ist ebenso als Sicherheitsplus zu werten wie der Umstand, dass sich Zugangsberechtigung über AWS Identity and Access Management (IAM) festlegen lassen. Dabei ist AWS CodeDeploy vollkommen unabhängig von Architektur oder Programmiersprachen, sodass Entwickler nicht auf ausgewählte Runtimes beschränkt sind, wie etwa bei Elastic Beanstalk.

Workflow mit CodeDeploy

Möchte man eine Code-Bereitstellung oder -Aktualisierung mit CodeDeploy orchestrieren, muss man als Entwickler drei Konzepte von CodeDeploy kennen, bzw. konfigurieren, nämlich „Anwendungs-Revision“ (oder einfach „Revision“), „Bereitstellungsgruppe“ und „Bereitstellungkonfiguration“. Unter einer Revision versteht AWS den konkreten Inhalt, der auf einer Instanz bereitgestellt werden soll. Das können je nach Programmiersprache Quellcode, ausführbare Dateien (in einer Devops-Pipeline könnte z. B. die vorgelagerte Build-Stufe die Build-Artefakte erzeugen und veröffentlichen) oder schlicht eine Webseite sein.

Für eine Revision in CodeDeploy muss der Entwickler eine in JSON oder YAML verfasste AppSpec-Datei integrieren. In dieser gibt man die Quelldateien der Revision an, legt Berechtigungen für entwickelte Daten fest oder spezifiziert Skripte, die im Verlauf der App-Entwicklung auf jeder Instanz laufen sollen. AWS CodeDeploy führt letztlich nur Skripte aus, die in der AppSpec-Datei spezifiziert sind.

Als Entwickler kann und muss man dabei auch Sets von Instanzen bestimmen, die man dann bei der Definition der Bereitstellungsgruppen referenziert und welche der jeweiligen Anwendung fest zugeordnet sind, Im Umkehrschluss umfasst also jede Bereitstellungsgruppe spezifische EC2- oder lokale Instanzen. Das Zuordnen von Instanzen zu Bereitstellungsgruppe erfolgt über den Namen einer zugehörigen Autoscaling-Gruppe und/oder unter Zuhilfenahme von Tags, über die sich Instanzen eindeutig identifizieren lassen.

Im Rahmen der Konfiguration des Bereitstellungsprozesses können Entwickler außerdem die exakten Schritte bestimmen, die dafür sorgen, dass ausgewählte Inhalte stets auf geeigneten Instanzen platziert werden. In diesem Workshop wollen wir exemplarisch eine Wordpress-Bereitstellung aus einem S3-Bucket auf EC2-Servern bereitstellen und die Wordpress-Applikation (PHP) anschließend aktualisieren und „re-deployen“.

CodeDeploy-Agent

Beginnen wir damit zu verifizieren, dass auf einer Entwicklungs-EC2-Instanz mit Amazon-Linux der CodeDeploy-Agent installiert ist. Das ist in diesem Beispiel deshalb wichtig, weil wir die virtuelle Entwickler-Maschine, auf der wir die Quellcode-Dateien vorbereiten, gleichzeitig als Deployment-Ziel verwenden möchten. In der Praxis würde man dies aber trennen.

Dazu verbinden wir uns mittels SSH und Public-Key mit unserem Development-Server und kontrollieren wie folgt den Status des Agenten, der bei Amazon-Linux üblicherweise installiert sein sollte. Seine explizite Installation ist nur auf lokalen Servern oder nicht unmittelbar unterstützen virtuellen Servern erforderlich.

Ferner ist dafür zu sorgen bzw. zu kontrollieren, dass die der Instanz zugeordnete Security-Gruppe http-Access erlaubt. Ist das erledigt, müssen wir den Wordpress-Source-Code auf unsere Instanz herunterladen.

Mit dem Tag „latest“ gelangt man per wget automatisch zur aktuellsten Version und muss das tar.gz-Archiv anschließend nur noch in einem temporären Verzeichnis entpacken:

Dann legen wir das eigentliche Zielverzeichnis an …

… und kopieren den entpackten Content dort hinein:

Anschließend können wir das temporäre Verzeichnis wieder löschen und legen dann im WordPress-Verzeichnis ein Unterverzeichnis „scripts“ an:

Hier legen wir ein kleines Skript „install_dependencies.sh“ an. Mit „vi“ oder unter Amazon Linux mit dem komfortablen Volltext-Editor „nano“ hinterlegten wir dann den folgenden Text:

Dann legen wir ein weiteres Skript z. B. mit dem Namen „start_server.sh“ an, das wir verwenden wollen, um unsere Server-Dienste zu starten. In diesen schreiben wir folgenden Inhalt:

Ferner benötigen wir auch noch ein passendes Stop-Skript z. B. mit dem Namen „stop_server.h“ mit dem folgenden Inhalt.

Nun benötigen wir noch ein Skript zum Erzeugen einer Test-Datenbank in MariaDB. Wir nennen es „create_test_sb.sh“. Es könnte z. B. so aussehen:

Und schließlich erstellen wir noch ein Skript, das die Berechtigungen für das www-Root-Verzeichnis „/var/www/html/WordPress“ passend setzt. Wir nennen es „change_permissions.sh“ und editieren es wie folgt:

Jetzt müssen wir nur noch all unsere eben erzeugten Skripte ausführbar machen:

Die CodeDeploy AppSpec-Datei

Wie beschrieben verwendet AWS CodeDeploy eine in YAML verpackte AppSpec-Datei, die sämtliche Quell-Dateien unserer Applikations-Revision passenden „Zielen“ in der Target-EC2-Instanz zuordnet. Dazu erzeugen wir mit nano eine Datei „/tmp/WordPress/appspec.yml“ mit folgendem Inhalt:

Aufbau und Inhalt der Datei sollten nach den Erläuterungen oben weitgehend selbsterklärend sein. Somit haben wir auf unserer Entwickler-Instanz die benötigten Quell-Dateien und Skripte vorbereitet. Im nächsten Teil dieses Workshop schauen wir uns an, wie man nun ein Wordpress-Bereitstellung auf EC2 (in diesem Beispiel auf der gleichen Instanz) mit CodeDeploy orchestriert und wie einfach es dann ist, Aktualisierungen auszurollen.

(ID:47046596)