October 28, 2015 / by Torben Greulich / Software engineer / @mr_tege

"Canary deployment" mit Ansible

Ein Release einer neuen Version ist immer mit einem Risiko verbunden. Kein Test kann die komplette Live-Umgebung simulieren und daher kann es zu unvorhergesehenen Fehlern im Betrieb kommen. Um dieses Risiko zu minimieren, sollte man mit canary deployments arbeiten. Wie man dieses mit Hilfe von Ansible realisieren kann, zeigt dieser Post.

Canary Deployment

Der Name canary deployment ist eine Anlehnung an die Technik der Bergarbeiter, die immer einen Kanarienvogel mit in die Mine nahmen, um so schnell über giftige Gase in der Mine informiert zu werden.

Ähnliches wird beim canary deployment getan. Statt eine Version auf das gesamte System auszurollen, wird es nur auf eine Teilmenge (canary) deployed. Dieser canary wird nun in der Live-Umgebung mit echten Daten getestet. Sollte es zu Fehlern kommen, kann der canary einfach und schnell abgeschaltet werden, ohne einen Komplettausfall zu produzieren.

Im Optimalfall kommt es zu keinem Fehler und die neue Version wird auf das gesamte System ausgerollt.

Beispiel mit Ansible

Wie so ein canary deployment mit Ansible aussehen kann zeigen wir anhand einer Java Anwendung, die in einem Tomcat auf 3 Servern läuft. Wie Ansible funktioniert und wie ein ansible-playbook aufgebaut ist, wird als bekannt vorausgesetzt.

Anforderungen

• Die neue und alte Version können parallel laufen
• Die neue Version ist in Produktion erreichbar
• Die neue Version wird (zufällig) auf einem Teil des Systems deployed.
• Wenn es zu Fehlern kommt kann der canary kurzfristig abgeschaltet und zurückgerollt werden
• Es kommt zu keiner Downtime aufgrund des Deployments

Deployment Prozess

Das Erstellen der neuen Version wird hier nicht behandelt. Es wird davon ausgegangen, dass die neue Version bereit steht und deployed werden kann. In unserem Fall also eine *.war Datei, die auf den Tomcat gespielt wird.

1. Es wird zufällig ein Server ausgewählt
2. Der Server wird heruntergefahren
3. Es wird ein Backup der bestehenden Version erstellt
4. Die neue Version ersetzt die alte auf dem Server
5. Der Server wird gestartet

Der Server kann produktiv getestet werden.

Ansible

1. Es wird zufällig ein Server ausgewählt

Die einfachste Variante ist, immer den ersten Host im System zu nehmen. Das ist nicht zufällig, ermöglicht aber ein sicheres rollback. Zudem ist die Zufälligkeit nicht erforderlich, um ein canary deployment zu machen. Man setzt im Ansible playbook, dass nur der erste Host benutzt werden soll.

  hosts: system[0]         # limits tasks to first host

Es ist auch möglich, einen anderen als den ersten zu nutzen. Zur Fehlervermeidung wird aber der erste genommen, da mindestens ein Server immer vorhanden sein sollte.

3. Es wird ein Backup der bestehenden Version erstellt

Auch hier wird ein einfacher Ansatz gewählt. Man kopiert die vorhandene *.war Datei in einen beliebigen backup Ordner und stellt sicher, dass nur diese Version dort vorhanden ist. Diese kann beim Rollback in den Tomcat zurück geschoben werden.

Rollback

Sollte es zu Fehlern kommen und ein rollback der neuen Version ist erforderlich:

1. Der Server wird heruntergefahren
2. Die neue Version wird entfernt
3. Das Backup wird geladen
4. Der Server wird gestartet

Optimierungspotential

• Beim Deployment wird das Backup immer überschrieben. Das sollte aber nur passieren, wenn eine neuere Version deployed wird.
• Man könnte zudem mehrere Versionen, statt immer nur die aktuelle im backup speichern. So könnte man auch ein Rollback einer älteren Version machen.

Sources

Hier ist das komplette Script für Ansible: