Atlassian Testumgebung automatisieren
Einleitung und Problemstellung
Es gibt viele Situationen, in denen wir schnell eine Testinstanz von Jira oder Confluence benötigen: Demonstrationen für Verkaufsgespräche, Testsysteme für Konfigurationen, Proof of Concepts, Schulungssysteme, Entwicklungssysteme für Apps und so weiter. Natürlich haben wir inzwischen Übung, die Produkte schnell von Hand zu installieren, aber es ergeben sich trotzdem einige Probleme dabei:
Die Installationsprozeduren von Atlassian-Produkten sind aufwändig und benötigen recht viel Zeit.
Es gibt viele Schritte auszuführen, die man falsch machen kann.
Die Umgebungen sind nicht reproduzierbar.
Wenn man sich beim Prototypen verfahren hat, kann man nicht einfach so in den installierten Ursprungszustand zurück. In dem Fall wird eine Neuinstallation fällig.
Die Instanzen müssen manuell aufgeräumt werden. Es besteht das Risiko, andere Instanzen zu tangieren oder Spuren zurückzulassen.
Wir haben uns überlegt, wie wir die Bereitstellung von Atlassian-Produkten automatisieren, und dabei noch etwas Neues lernen können. Daraus ist ein System entstanden, mit dem wir eine oder mehrere Instanzen von Jira, Confluence, Bitbucket und Bamboo innerhalb von ca. 10 Minuten bereitstellen können. Der folgende Blogpost beschreibt die Architektur der aktuellen Lösung. Dabei bleibt es bei einer High-Level Übersicht, technische Details werden in späteren Artikeln vertieft.
Anforderungen
Bei den Überlegungen, wie wir die Problemstellung angehen wollen, haben sich folgende Anforderungen herauskristallisiert:
Die erforderlichen Produkte sind Jira, Confluence, Bitbucket und Bamboo.
Eine Instanz muss in unter 30 Minuten zur Verfügung stehen.
Die Version des Produktes sollte einfach bestimmbar sein.
Es muss ein Setup mit externer Datenbank möglich sein.
Die Geschwindigkeit sollte mit out-of-the-box Produktivinstanzen vergleichbar sein.
Die Instanzen sollten vollständig eliminierbar sein, ohne Spuren zu hinterlassen.
Die Instanzen sollen einfach gesichert werden können und wieder herstellbar sein.
Ein einigermaßen versierter Techniker sollte eine Instanz erstellen können, ohne das System näher zu kennen.
Die Plattform sollte ohne manuelle Eingriffe erstellt und gemanaged werden können.
Zur Installation eines Atlassian Produktes sind grob folgende Schritte nötig, die automatisiert werden müssen:
Aufsetzen des Basissystems
Aufsetzen der Datenbank und einrichten eines Schemas
Herunterladen des Produktes, ins Home-Verzeichnis entpacken und Rechte anpassen
Konfigurationsdateien anpassen
Proxy konfigurieren
Produkt starten
Eingesetzte Tools
Bei der Evaluierung hat sich gezeigt, dass eine Plattform aus folgenden Tools eine gute Lösung für unsere Problemstellung bietet:
Hetzner Cloud: Cloud IaaS Provider, unschlagbarer Preis, gute Stabilität und Geschwindigkeit. Es gibt ein sehr gutes Terraform-Plugin.
Hashicorp Terraform: Infrastructure-as-Code Tool. Verwenden wir, um die Cloud VMs zu betreiben. Die Infrastruktur wird dabei deklarativ in einer Datei beschrieben, Terraform sorgt für die Umsetzung. Verschiedene Funktionseinheiten wie Frontend-Node und Worker-Node können in Module ausgelagert werden.
Hashicorp Packer: Provisionierungstool zum Erstellen der Base Images bei Hetzner und Erstellung der Docker Images der Atlassian Tools.
Hashicorp Consul: Dient als Service Registry. Registriert die Produkte mit zugehörigen Hostnamen und Ports, und stellt diese Informationen dem Proxy zur Verfügung.
Docker: Betreibt die eigentlichen Produkte. Neue Instanzen können in wenigen Minuten gestartet, gestoppt und spurlos eliminiert werden. Auch Backup und Restore sind sehr simpel.
Registrator: Überwacht den Docker Daemon und registriert Hostnamen und Ports neuer Container in Consul.
Traefik: Setzen wir als Proxy für die Applikationen ein, damit ordentliche URLs und HTTPS-Terminierung funktionieren.
Bash Scripts: Bei der Provisionierung von Hosts und Docker Images müssen sehr viele Aufgaben erledigt werden wie Package-Installationen, Anpassungen an Konfigurationsdateien, Herunterladen und Auspacken von Dateiarchiven und so weiter.
Da wir die Atlassian-Applikationen sowieso in Docker-Images packen wäre natürlich auch eine ausgewachsene Cluster-Plattform wie Kubernetes oder OpenShift möglich. Die Komplexität und die betrieblichen Implikationen dieser Plattformen sind aber einiges höher als bei der gewählten Lösung. Auch auf ausgewachsenen Provisionierungs-tools wie Ansible haben wir trotz guter Erfahrungen verzichtet, um die Komplexität nicht weiter zu erhöhen. Außerdem können wir auf viele Features ohne Probleme verzichten. Details zur Evaluation werde ich in folgenden Posts noch erläutern.
Architektur
Systemebene
Das Setup ist eingeteilt in einen Frontend-Node und beliebig viele Backend-Nodes. Die Systeme werden mit einem Terraform-Projekt verwaltet, dass die Systeme erzeugt und die Server mit einer Handvoll Shell Scripts provisioniert. Da wir unterschiedlichen Bedarf haben, z.B. viele Instanzen für Schulungen oder grosse Projekte, kann die Anzahl Worker-Nodes sehr einfach gesteuert werden. Man kann einen neuen Node erzeugen, indem man einen Block im Terraform File hinzufügt. Um die Bereitstellung zu beschleunigen, haben wir mit Packer ein Basisimage erstellt, dass die nötigen Hashicorp-Tools und Docker bereits beinhaltet. Auch kann das Image so sehr schnell aktualisiert, angepasst und erweitert werden. Der PAcker-Script konnte so auch mit minimalem Zusatzaufwand ein VM-Image für lokale Tests erzeugen.
Auf dem Worker Node werden die Applikationen gestartet. Sie sind in Docker-Container gepackt, und können somit einfach gestartet und sauber wieder entfernt werden. Ein Service registriert die Hostnamen und Ports der Atlassian Applikationen im Consul Agent. Auf dem Frontend Node läuft der Proxyserver der aus der Consul-Information dynamisch eine Konfiguration erzeugt, und ein Let’s Encrypt Zertifikat bereitstellt. Somit wird aus einer unschönen internen Adresse wie http://10.2.2.4:32556 eine brauchbare wie https://jira01.zuara.io.
Applikationsebene
Die Applikationen werden als Docker Container betrieben. Je nach Szenario können das mehrere Jiras, mehrere Confluences, weitere Atlassian-Applikationen sowie ein Datenbank-Server sein. Da wir mehrere solche Bündel pro Node betreiben, wird der Port der Applikation von Docker frei vergeben, die Applikation merkt davon nichts. Damit sich die Applikationen und die Datenbank mit Hostnamen und Standardport erreichen können, wird zusätzlich ein privates Netzwerk angelegt, auf das alle Container eines Bündels verbunden werden. Ein weiterer Service (Registrator) überwacht den Docker Daemon, und registriert den Hostnamen und dynamischen Port eines Applikations-Containers beim Consul Agent.
Die Daten des Containers werden auf den Frontend-Node synchronisiert. Meistens werden Atlassian-Applikationen hinter einem Proxy Server betrieben, sehr häufig Apache oder im Fall von Windows Internet Information Service. Die Konfiguration müsste dann mit einem Template-Tool, einem Script oder von Hand generiert werden. In diesem Setup wird Traefik verwendet, der extra dafür gemacht ist, dynamisch Konfigurationen aus Quellen wie Consul zu generieren. Das heißt, wenn auf einem Worker-Node ein Jira gestartet wird, entsteht auf dem Frontend-Node automatisiert eine Proxy-Konfiguration dafür, komplett ohne manuellen Eingriff.
Das Starten eines solchen Bündels benötigt einige Schritte. Um diese langweilige Arbeit zu automatisieren, wurde ein Bash-Script erstellt. Es kann folgende Aufgaben erledigen:
Starten der Datenbank-Instanz
Erstellen der Datenbank-Schemas
Starten der Atlassian-Instanz(en)
Verknüpfen der Instanzen auf das interne Netzwerk
Stoppen und entfernen der Container und des Netzwerkes
Backup der Container
Restore der Container
Es ist damit möglich, mit einem Befehl zwei Jiras, zwei Confluences, ein Bitbucket, ein Bamboo und ein PostgreSQL zu starten und in einem Bündel zu betreiben. Das reicht aus für fast alle Szenarien, die bei uns vorkommen.
Ausblick
Dieser Blogpost konnte nur einen groben Überblick über das System bieten. Folgende Themen werde ich in zukünftigen Artikeln gerne detaillierter ausführen:
Individuelle VM Templates und Docker Builds mit Packer. Herausforderungen beim Betreiben von Atlassian-Applikationen als Docker Images.
Bereitstellung von Systemen mit Terraform, Provisioning und Modularisierung.
Automatisches Service Discovery und Proxying mit Consul und Traefik.
Docker Details: Passende Flags, private Netzwerke, Service Discovery.
Haben Sie Fragen oder Anregungen zum diesem Blog-Beitrag? Dürfen wir Sie unterstützen? Schreiben Sie uns auf hallo@zuara.ch oder rufen Sie uns an: 031 302 60 00. Wir freuen uns auf Ihre Anfrage!