Atlassian Testumgebungen automatisieren

3. Aug. 2020 | Clustering, DevOps, Hashicorps, Testumgebung

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:

  1. Die erforderlichen Produkte sind Jira, Confluence, Bitbucket und Bamboo.
  2. Eine Instanz muss in unter 30 Minuten zur Verfügung stehen.
  3. Die Version des Produktes sollte einfach bestimmbar sein.
  4. Es muss ein Setup mit externer Datenbank möglich sein.
  5. Die Geschwindigkeit sollte mit out-of-the-box Produktivinstanzen vergleichbar sein.
  6. Die Instanzen sollten vollständig eliminierbar sein, ohne Spuren zu hinterlassen.
  7. Die Instanzen sollen einfach gesichert werden können und wiederherstellbar sein.
  8. Ein einigermassen versierter Techniker sollte eine Instanz erstellen können, ohne das System näher zu kennen.
  9. 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:

  1. Aufsetzen des Basissystems
  2. Aufsetzen der Datenbank und einrichten eines Schemas
  3. Herunterladen des Produktes, ins Home-Verzeichnis entpacken und Rechte anpassen
  4. Konfigurationsdateien anpassen
  5. Proxy konfigurieren
  6. 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 Packageinstallationen, 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 Provisionierungstools wie Ansible haben wir trotz guter Erfahrungen verzichtet, um die Komplexität nicht weiter zu erhöhen. Ausserdem 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 Konfiuration 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 heisst, 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:

  • Individuele 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!

Der Autor:

Roman Maire

Roman Maire

roman.maire@zuara.ch

Direkt: +41 79 307 60 29

      

Weitere Fachartikel und Neuigkeiten von Zuara

Phänomene ineffektiver Teams

Kennen Sie das? Irgendwie happert es dem Team an Drive, z.B. werden nicht alle User-Stories aufs Sprint-Ende umgesetzt oder auf dem KanBan Board stapeln sich die MMFs in der "To-Deploy"-Spalte. Und dann hat das Ganze auch noch keine Konsequenzen für die...

In Confluence Finden, statt ewiges Suchen

Haben Sie auch schon versucht, in Confluence etwas zu finden und dafür kostbare Zeit verschwendet?  Die Indexierung von Confluence ist wirklich ein grosser Vorteil, kann aber auch dazu führen, dass das Gesuchte durch die Masse an Ergebnissen einfach nicht gefunden...

Atlassian Testumgebungen 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...

Tabellenkalkulation in Confluence

Excel ist aufgrund der vielfältigen Möglichkeiten zur Tabellenkalkulation sowie der Flexibilität in vielen Unternehmen weit verbreitet. Deshalb taucht auch in Zusammenhang mit dem Einsatz von Confluence oft die Frage auf, welche Funktionen zur Tabellenkalkulation...

Word Integration in Confluence

Eine häufige Anforderung bei der Arbeit mit Confluence ist die Integration von Office. Office ist bei vielen Unternehmen im Einsatz und bei einer Einführung von Confluence stellt sich dann die Frage, wie sich die Microsoft-Welt mit der Atlassian-Welt verbinden lässt....

Alle im Homeoffice – auch Schülerinnen und Schüler

Aus aktuellem Anlass stellt sich für viele Schulen und Organisationen die Frage, wie ihre Mitarbeitenden weiterhin möglichst reibungslos zusammenarbeiten können und wie der Schulunterricht fortgesetzt werden kann. Teams und Klassen haben die folgenden Ansprüche, um...

Digital Workplace/Home-Office – wie verteilte Zusammenarbeit gut funktioniert und wie nicht

Eines vorweg: Ja, ich weiss, es schreiben zur Zeit alle über den "Digital Workplace" und die Zusammenarbeit aus dem Home-Office heraus. Schliesslich ist das gerade DAS Trend-Thema bedingt durch die Corona-Krise. Und viele Organisationen haben gemerkt, dass sie in...

Confluence ist auch ein Content Management System

Genialer Werkzeugkasten: Die Software Atlassian® Confluence® ist ein Wiki oder neudeutsch ein Social Collaboration Hub - also eine elektronische Plattform, auf der Menschen zusammenarbeiten, Inhalte und Wissen teilen, organisieren und diskutieren. Confluence kann noch...

Jira App-Entwicklung: JQL verarbeiten ohne Kopfschmerzen

Die Herausforderung In vielen Projekten haben wir Kundenanforderungen, die mit den normalen Bordmitteln von Jira nicht mehr zu erfüllen sind. Häufig ist die einfachste Lösung, selbst ein kleines Add-on zu implementieren. Eine solche Anforderung, die wir kürzlich...

Ineffektive Teams – Lösungsansätze

Oder warum Agile motiviert. In unserem vorderen Post haben wir die Phänomene ineffektiver Teams aufgeführt: Social Loafing (Soziales Faulenzen) Free Riding (Trittbrettfahren) Sucker-Effekt (Trottel-Effekt) Group Think Nun möchten wir Lösungsansätze liefern, um diesen...