DevOps-Workflow mit AWS CodeDeploy, Teil 2 Wordpress in der AWS Elastic Computing Cloud

Der Deployment-Prozess von AWS CodeDeploy besteht darin, den App-Content samt aller involvierten Dateien und Skripte auf EC2-Instanzen bereitzustellen. Wie wir Wordpress in der Elastic-Computing-Cloud lauffähig machen, beleuchtet dieser zweite Teil unseres Workshops.

Als Umgebung dient zunächst weiterhin der Development-EC2-Server aus dem ersten Teil dieser Serie. Hier erstellen wir, via SSH verbunden, wie folgt eine CodeDeploy-Application:

Das Kommando gibt die „Application-ID“ zurück. Nun müssen wir ein S3-Bucket erzeugen, das die in Teil 1 bereitgestellten Source-Dateien aufnehmen soll:

Dann wechseln wir – sofern noch nicht geschehen – ins Quellcode-Verzeichnis /tmp/WordPress und pushen den gesamten Inhalt einschließlich der appspec.yml-Datei auf den S3-Bucket.

Ist das geschehen, können wir unsere Bereitstellungsgruppe „WordPress_DG“ wir folgt erzeugen:

Das kann man selbstverständlich auch grafisch in der AWS Management-Console tun. Der Deployment-Typ kann übrigens „In-place“ oder „Blue/green“ sein. Ferner brauchen wir eine Service-Rolle in IAM und eine „Envrionment configuration“. Hier stehen wie in Teil 1 beschrieben „Autoscaling Gruppen“, „EC2-Instanzen“ oder „On Premise Instanzen“ zur Verfügung.

Spätestens jetzt müssen die gewünschten Ziel-EC2-Instanzen selbstverständlich auch verfügbar sein, denn CodeDeploy erzeugt selbst keine Infrastruktur. Allerdings verwenden wir in diesem Beispiel wie in Teil 1 erwähnt unsere Entwicklungs-Instanz auch als Bereitstellungziel.

Wie man sieht, spezifiziert die Deployment Gruppe ein Set individueller Ziel-Instanzen für das Deployment, die über Tags oder den Namen der Autoscaling Gruppe (sofern vorhanden) spezifiziert werden.

Neben dem „Deployment type“ gibt es noch die „Deployment configuration“. Hier kann der Entwickler zwischen „AllAtOnce“, „HalfAtATime“ und „OneAtATime“ oder einer Custom-Configuration (Create deployment configuration) wählen. Eine Bereitstellungskonfiguration definiert Regeln, die bestimmen, wie schnell eine Anwendung bereitgestellt wird und welche Erfolgs- oder Fehlerbedingungen für eine Bereitstellung gelten.

Nun können wir das eigentliche Deployment erzeugen, was letztendlich Wordpress auf dem angegebenen Zielsystem ausrollt.

Auch das kann man natürlich alternativ in der Console tun.

Updates Management

Um zu verifizieren, dass das Deployment funktioniert hat, verbinden wir uns zunächst mit der öffentlichen IP-Adresse der Ziel-Instanz und stellen im Browser die Wordpress-Installation/Konfiguration fertig.

Um die Update-Funktion zu testen, verbinden wir uns wieder mit dem Entwicklungsrechner und nehmen eine geringfügige Änderung an den Quelldateien vor. Mit dem Linux-Befehl „sed“ können wir auf einfache Weise einige Seitenfarben in den CSS-Dateien unter /wp-conent/themes/twentyfifteen/style.css anpassen.

Die Änderungen pushen wir dann wir dann wieder mit:

Nun müssen wir uns nur noch mit der CodeDeploy-Console verbinden, wechseln zu unserer WordPress-App, dort zum Tab „Revisions“ und klicken auf „Deploy application“. Das Ergebnis können wir nach wenigen Minuten wieder visuell auf der Ziel-Instanz überprüfen.

(ID:47063017)