Eine EinfĂĽhrung in Continuous Delivery, Teil 4: Bereitstellen der Infrastruktur

Seite 3: Provisionierung

Inhaltsverzeichnis

Der nächste Schritt auf dem Weg zu einer realistischen Testumgebung für die Beispielanwendung aus den vorigen Artikeln dieser Serie ist die Provisionierung von Java und Tomcat. Dazu sind zusätzlich zu dem apt Cookbook die von der Community gepflegten Cookbooks für Java und Tomcat nötig. Ein vorbereitetes Set-up für eine solche Testumgebung befindet sich im Ordner cddemo-chef2. Mit dem üblichen

cd ../cddemo-chef2
vagrant up

lässt sich jetzt eine neue VM mit Java und Tomcat provisionieren.

Damit fehlen allerdings immer noch einige Schritte, bis ein Deployment der Beispielanwendung auf der Umgebung möglich ist:

  • Aus Jenkins heraus muss ein Log-in per ssh auf der Testumgebung möglich sein. (.ssh/authorized_keys)
  • Das Skript zum Download des Bundles aus dem Repository muss auf der Umgebung installiert sein. (/usr/local/bin/download-bundle.sh)
  • Der User tomcat7 muss Tomcat per sudo stoppen und wieder starten können. (/etc/sudoers.d/tomcat7)

Eine Provisionierung, die auch die obigen Aufgaben löst, befindet sich im Ordner cddemo-chef3. Die eigentliche Provisionierung steckt dabei wieder im Default Recipe in der Datei cddemo-chef3/cookbooks/cddemo-chef3/recipes/default.rb. Die Anweisungen dort sollten einigermaßen selbsterklärend sein.

Leider ginge eine detaillierte Beschreibung, welche Optionen Chef zur Lösung solcher Aufgaben bietet, über den Rahmen dieses Artikel hinaus. Interessierte finden jedoch umfangreiche Webinars auf der Webseite des Tools.

Eine fertige Testumgebung lässt sich mit dem erwähnten Cookbook wie folgt provisionieren:

cd ../cddemo-chef3
vagrant up

Auf der so eingerichteten virtuellen Maschine lässt sich wie im vorangegangenen Artikel beschrieben die Beispielanwendung deployen. Um sie jetzt in die Continuous Delivery Pipeline einzubinden, müssen die beiden virtuellen Maschinen über das Netzwerk miteinander kommunizieren können. Dazu sollte man die aktualisierte Pipeline-VM herunterladen. Bevor man sie startet, fügt man Virtualbox ein sogenanntes Nat Network hinzu, über das die beiden virtuellen Maschinen miteinander kommunizieren können (Nat Networks funktionieren nur mit Virtualbox ab Version 4.3).

VBoxManage natnetwork add --netname 'cddemo' --network '10.0.4.0/24'

In der Pipeline-VM CD_Demo lässt sich die Konfiguration des 2-acceptance-test-Jobs so ändern, dass die neue mit Chef provisionierte Testumgebung statt des LXC-Containers aus dem letzten Artikel zum Einsatz kommt. Dazu ist lediglich im Pre-Build-Step sowie in der Konfiguration des Maven-Aufrufs der Hostname von testenv1 auf testenv2 zu ändern.

Einbindung der Testumgebung in die Pipeline (Abb. 3)


Mit dem oben beschriebenen Set-up besteht die Möglichkeit, die Testumgebung für unsere Beispielanwendung automatisiert bereitzustellen. Für reale Testumgebungen mag der Aufbau etwas komplizierter sein, aber schon im simplen Beispiel werden die prinzipiellen Vorteile des Vorgehens deutlich:

  • Jede der so erzeugten Umgebungen ist identisch. Die bei manueller AusfĂĽhrung ĂĽblichen FlĂĽchtigkeitsfehler werden vermieden.
  • Die kompletten Beschreibungen der Infrastruktur befinden sich unter Versionskontrolle. So lassen sich auch Umgebungen auf dem Stand von vor einem halben Jahr noch zuverlässig erzeugen.
  • Das Bereitstellen der Testumgebungen ist vollständig automatisiert. Manuelle Ăśbergaben entfallen und die nötige Zeit fĂĽr den Vorgang sinkt erheblich.

Soll fĂĽr eine reale Continuous Delivery Pipeline Infrastruktur aus mehreren virtuellen Maschinen bereitgestellt werden, geht daher an einem solchen Infrastructure-as-Code-Ansatz kein Weg vorbei.