Atlassian Hosting: Technische Herangehensweise

Es gibt etliche Möglichkeiten von Atlassian Hosting. Server, Data Center oder auch direkt in der Atlassian Cloud. Eine dieser Möglichkeiten ist es Atlassian Software direkt auf deinen eigenen Server oder bei AWS / Azure (Cloud Provider) zu hosten.

In diesem kurzen Artikel findest du alle Informationen und Requirements zum hosten von Atlassian Software.

Atlassian Hosting: Voraussetzungen

Offizielle Domain mit einem DNS-Server, auf dem Einträge hinzugefügt werden können und die aufgelöst werden können.

DNS-Einträge, die auf die externe IP des Servers zeigen, auf dem die Atlassian-Anwendung laufen soll.

Wenn Route 53 verwendet wird, können wir mit dem certbot und letsencrypt Wildcard-Zertifikate für die gesamte Domain generieren.

Anwendungsserver

Server-Bereitstellung

Als Applikationsserver verwenden wir in der Regel Ubuntu und lassen Ansible laufen, um ihn zu konfigurieren. Ansible nimmt dann einige Grundkonfigurationen vor und installiert benötigte Software, wie Docker auf dem Host. Es werden auch einige Docker-Anwendungen auf einem Host ausgerollt, wie der Reverse-Proxy.

Reverse-Proxy

Als Reverse-Proxy verwenden wir das Docker-Image xalt/nginx. Dieses kann sich an den Docker-Socket anhängen und ist dadurch in der Lage zu lesen, welche Docker-Container auf dem Host laufen. Wenn eine Anwendung bestimmte Parameter gesetzt hat, wird die Nginx-Konfiguration automatisch geändert und neu geladen, Upstream- und Server-Konfigurationen werden für die angegebenen virtuellen Hostnamen und Ports erstellt. Wenn der Hostname mit einem verfügbaren SSL-Zertifikat übereinstimmt, wird auch ein SSL-Listener für diese Anwendung konfiguriert. Der Reverse-Proxy kann Inhalte über 80 (http) und 443 (https) bereitstellen, diese Ports werden auf die Host-Ports 80 und 443 montiert.

Es wird ein Side-Cart-Container bereitgestellt, der Let’s Encrypt-Helfer. Dieser Container hat ebenfalls Lesezugriff auf den Docker-Socket, und wenn ein Container Let’s Encrypt-Parameter bereitstellt, initiiert er eine Let’s Encrypt-Zertifikatsherausforderung und speichert die Zertifikate, damit der Reverse-Proxy-Container sie für die https-Verbindungen verwenden kann.

Docker-Anwendung

Alle Docker-Anwendungen werden in einer Datei docker-compose.yml beschrieben, die von Ansible bereitgestellt wird. JIRA/ Confluence und die PostgreSQL-Datenbank haben ihr Home-Verzeichnis in separaten Verzeichnissen auf der gleichen Ebene wie die docker-compose.yml eingebunden. Auf diese Weise befinden sich die Anwendungskonfiguration und die Anwendungsdaten im gleichen Bereich und können leicht gepflegt werden.

JIRA/ Confluence

Dieser Docker-Container führt einen Tomcat mit der JIRA-Anwendung aus. Der Tomcat-Connector muss über Environment-Variablen des Containers korrekt konfiguriert werden. Gleiches gilt für die Anwendungsüberwachung über NewRelic. Die Heap-Parameter können auf die gleiche Weise konfiguriert werden und natürlich müssen die Reverse-Proxy-Parameter gesetzt werden, ebenso wie die Letsencrypt-Parameter, falls erforderlich.

Für Testsysteme haben wir noch ein paar weitere Features implementiert, um die Wiederherstellung der persistenten Home-Daten via ssh rsync und die Modifikation der Datenbank mit Liquibase zu ermöglichen. So können z.B. die Basis-URL oder die Applikationslinks geändert werden.

PostgreSQL

Wir verwenden in der Regel einen PostgreSQL-Container und spawnen ihn in einem separaten, anwendungsspezifischen Docker-Netzwerk unter dem DNS-Namen „db“, der nur für die in dieser docker-compose.yml-Datei angegebenen Container erreichbar ist. Benutzername, Passwort und Datenbank werden als Umgebungsparameter des Containers angegeben. Die Datenbank für JIRA/ Confluence kann auch MySQL oder OracleSQL sein, wir haben uns aber aus Kompatibilitätsgründen für PostgreSQL entschieden.

Für Testsysteme haben wir ein paar weitere Features implementiert, um die Wiederherstellung der persistenten Home-Daten per ssh rsync zu ermöglichen.

Backup

Dieser Container führt im Grunde einen Cron-Job aus, der den JIRA/Confluence- und PostgreSQL-Container herunterfährt und die persistenten Home-Ordner per rsync auf den Backup-Server überträgt. Dieser Container wird ebenfalls durch mehrere Umgebungsparameter konfiguriert, wie z.B. die Cron-Job-Zeit, den Namen des Backup-Servers und benötigt außerdem einige Mount-Punkte, wie z.B. den Docker-Socket, um Docker-Container von innerhalb eines Docker-Containers herunterzufahren und zu starten. Außerdem werden weitere Mounts benötigt, um zu lokalisieren, wo sich die Daten befinden, die gesichert werden sollen.

Web-Anfrage

Wenn auf eine Docker-Anwendung zugegriffen werden soll, gibt der Benutzer in der Regel einen DNS-Namen in den Browser ein. Die IP versucht, durch eine DNS-Anfrage an R53 aufgelöst zu werden. Die Antwort ist in der Regel ein A-Record, der auf den Server zeigt, auf dem die Anwendung läuft. Der Browser baut eine Verbindung zum Port 80 des Anwendungsservers auf. Dort leitet der Docker-Proxy die Anfragen an den Nginx-Reverse-Proxy weiter, der auf https umleitet, wenn ein gültiges Zertifikat für den virtuellen Hostnamen der Anwendung existiert. Wenn diese Direktive vom Browser ausgeführt wurde, wird die Anfrage auf Port 443 am Applikationsserver angenommen. Diese geht an den Reverse-Proxy, der sie dann an den konfigurierten Upstream, die Atlassian-Anwendung, sendet und die Antwort an den anfragenden Browser ausliefert, um dort weitere Ressourcen zu laden und im en die heruntergeladene Webseite zu rendern.

Atlassian Hosting: Backup-Server

Dieser Host wird normalerweise mit großem Speicher bereitgestellt, um die Anwendungsdaten mehrerer Docker-Anwendungen zu speichern. Er wird ebenfalls über Ansible provisioniert.
Hier wird standardmäßig nicht Docker installiert, sondern rsync und rsnapshot, die für unser Backup-Konzept die wichtigsten Bestandteile sind. Rsync wird für den Datentransport von Host zu Host, aber auch für rsnapshot eingesetzt.
Die übliche Konfiguration für den Aufbewahrungsmechanismus erlaubt die Speicherung von 7 täglichen, 4 wöchentlichen und 12 monatlichen Backups. Dabei wird für die Sicherung die Verwendung von Hard-Links erzwungen, um Platz zu sparen, wenn eine Datei seit dem letzten Tag nicht mehr angefasst wurde.
Auf diese Weise wird etwa das 2,5-fache der ursprünglichen Anwendungsgrößen verbraucht (rsync der Daten vom Anwendungsserver zum Backup-Server verbraucht 1 + die rsnapshot-Kopie davon und die entsprechenden Deltas nehmen noch einmal die 1,5-fache Größe ein), um Backups zu haben, die bis zu 12 Monate zurückgespielt werden können.

Mehr zu Managed Atlassian Hosting

Das ganze Konzept erfordert die Erzeugung eines SSH-Schlüssels auf dem Applikationsserver und die Speicherung des öffentlichen Schlüssels in den autorisierten Schlüsseln des Root-Benutzers des Backup-Servers:

1. Synchronisieren der Daten (rsync) vom Backup-Container (Anwendungsserver) zum Backup-Server.
2. Rsnapshot wird durch eine Cronjob-Logik ausgelöst, um die verschiedenen Aufbewahrungskonfigurationen einmal pro Tag, Woche und Monat auszuführen.
3. Eine Docker-Applikation wird mit den korrekt angegebenen Backup-Parametern gestartet und wird diese Daten vom Backup-Server rsyncen, bevor die Applikation startet.

Die Daten, die wiederhergestellt werden sollen, können im Docker-Container von JIRA/Confluence und PostgreSQL konfiguriert werden. Wenn das aktuellste Backup benötigt wird, können die Zielordner des rsync-Backups angegeben werden. Wenn jedoch Daten eines älteren Backups wiederhergestellt werden sollen, benötigen wir hier den richtigen rsnapshot-Pfad.