Mobile-Menu

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

Von Dipl. -Ing. Thomas Drilling 6 min Lesedauer

Anbieter zum Thema

netfiles GmbH
Hyland Software 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.

Fluss eines typischen Vor-Ort-Deployments mit AWS CodeDeploy.(Bild: AWS)
Fluss eines typischen Vor-Ort-Deployments mit AWS CodeDeploy.
(Bild: AWS)

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

CodeDeploy bezieht Code aus einem Quellverwaltungssystem und installiert ihn z. B. auf Amazon EC2.(Bild: Drilling / AWS)
CodeDeploy bezieht Code aus einem Quellverwaltungssystem und installiert ihn z. B. auf Amazon EC2.
(Bild: Drilling / AWS)

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.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Cloud Computing

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

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.

sudo service codedeploy-agent status

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.

mkdir /tmp/WordPress_Temp
cd /tmp/WordPress_Temp
wget https://wordpress.org/latest.tar.gz

Wir laden den Wordpress-Quellcode herunter und entpacken ihn.(Bild: Drilling / AWS)
Wir laden den Wordpress-Quellcode herunter und entpacken ihn.
(Bild: Drilling / AWS)

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:

tar -xzvf ./latest.tar.gz

Dann legen wir das eigentliche Zielverzeichnis an …

mkdir -p /tmp/WordPress

… und kopieren den entpackten Content dort hinein:

cp -paf /tmp/WordPress_Temp/wordpress/* /tmp/WordPress

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

mkdir -p /tmp/WordPress/scripts

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:

#!/bin/bash
yum install -y httpd php mariadb-server php-mysqlnd

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:

#!/bin/bash
service httpd start
service mariadb start

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

#!/bin/bashisExistApp='pgrep httpd'if [[ -n $isExistApp ]]; then
   service httpd stop
fiisExistApp='pgrep sql'if [[ -n $isExistApp ]]; then
   service mariadb stop
fi

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:

#!/bin/bashmysql -uroot <<CREATE_TEST_DB
CREATE DATABASE IF NOT EXISTS test;
CREATE_TEST_DB

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:

#!/bin/bashchmod -R 777 /var/www/html/WordPress

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

sudo chmod +x /tmp/WordPress/scripts/*

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:

version: 0.0
os: linuxfiles:
   - source: /
     destination: /var/www/html/WordPress hooks:  BeforeInstall:
   - location: scripts/install_dependencies.sh
     timeout: 300
     runas: root  AfterInstall:
   - location: scripts/change_permissions.sh
     timeout: 300
     runas: root  ApplicationStart:
   - location: scripts/start_server.sh
   - location: scripts/create_test_db.sh
     timeout: 300
     runas: root   ApplicationStop:
   - location: scripts/stop_server.sh
     timeout: 300
     runas: root

Die AppSpec-Datei steuert über „hooks“ den gesamten Bereitstellungsprozess.(Bild: Drilling / AWS)
Die AppSpec-Datei steuert über „hooks“ den gesamten Bereitstellungsprozess.
(Bild: Drilling / AWS)

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)

Weiterführende Inhalte