Softwarebetrieb in der Cloud am Beispiel der Atlassian Toolchain

Die Aktuelle Entwicklung bezüglich des Betriebs eigener Server zeigt deutlich, dass viele – auch größere – Firmen den Auf- und Ausbau eigener Rechenzentren scheuen. Dies lässt sich auf die hohen Anforderungen sowie den damit verbundenen Kosten für Betrieb und Sicherheit zurückführen. Auch der Einsatz traditioneller Cloudanwendungen wird auf Grund der mangelnden Datenhoheit und der Gefahr des Ortes der Datenhaltung (außerhalb von Deutschland) gemieden. Mit diesem Artikel möchten wir unsere Erfahrungen hinsichtlich des Betriebs von Atlassian Anwendungen im Software as a Service Modell (Managed Hosting) beschreiben.

Ausgangssituation

Als DevOps-Team im Atlassian Umfeld sehen wir die verschiedensten Konfigurationen und Umgebungen, in denen Tools wie beispielsweise Jira und Confluence betrieben werden. In historisch gewachsenen Umgebungen, welche wir oft auch im BaFin-Bereich sehen, werden die Applikationen „hart“ auf einer dedizierten virtuellen Maschine und dort alle Updates manuell installiert. In größeren Umgebungen werden zugehörige Datenbanken glücklicherweise meist auf ein zentrales Datenbankcluster ausgelagert, wodurch die Performance verbessert wird. Hinsichtlich Security, Backups sowie Updates haben wir bisher alles von „es ist Aufgabe des Applikations-Teams“ bis hin zu vollüberwachten, zentralisierten Lösungen gesehen. Diese Varianz ist jedoch oft auch mit einer deutlichen Komplexität hinsichtlich der Einführung neuer Anwendungen oder auch nur dem Einspielen von Updates verbunden. Aus diesem Grund kommen Kunden aus verschiedensten Bereichen auf uns als Dienstleister zu, um Initiativen wie „Cloud First“ zu realisieren. Oft hören wir auch die Frage “Könnt Ihr das für uns betreiben, aber sicher und in Deutschland?”

Neben der Reise, die wir bei unseren Kunden beobachten, haben auch wir als DevOps-Team von it-economics eine Reise in Richtung der Cloud begonnen. Wir, also Alexander und Christian, als Autoren dieses Artikels betreiben privat auch verschiedene Server, jedoch haben wir uns aktiv gegen AWS als Quelle für Rechenpower sowie gegen den heimischen Server und für einen regulären Hostingprovider entschieden. Unsere Gründe hierfür waren klar die Kosten und unsere Anforderungen. Wir betreiben keine Applikationen mit Geheimanwendungen, keine kritische Infrastruktur, aber die initialen Anschaffungskosten für Serverhardware sowie der Aufwand selbst jegliche Wartung zu übernehmen war uns zu viel. Ebenso sehen wir viele Parallelen bei kleineren Unternehmen, die Atlassian Anwendungen einführen und sich am Ende für einen Standard-Hoster mit Absicherung nach bestem Wissen und Gewissen durch die eigene IT entscheiden.

Anforderungen

Eine zentrale Grundanforderung unserer Kunden aus dem DACH-Raum ist die Einhaltung der geltenden Gesetze. Insbesondere die Einhaltung der Datenschutzgrundverordnung (DSGVO) sowie eine Datenspeicherung innerhalb von Deutschland, maximal aber innerhalb von Europa, sind hier im Fokus. Hinzu soll in der Regel auch eine automatische Erkennung von Angriffen inklusive deren Abwehr, eine entsprechende Firewall sowie Virenschutz installiert sein. Die Erstellung von Backups soll automatisiert stattfinden – und wenn eine Wiederherstellung notwendig ist soll diese natürlich mit minimalem Aufwand unmittelbar wieder zu einem betriebsbereiten Zustand führen. Auch die Möglichkeit, verschiedene Stagingumgebungen zu nutzen ist hoch nachgefragt – also die Trennung von Entwicklung, Abnahme und Produktion. Diese Trennung dient vor Allem dem einfachen Umgebungs-Abgleich für reproduzierbare Updates und das Ausrollen von Anpassungen, die zunächst in einer nicht kritischen Umgebung ausgiebig getestet wurden.

Umsetzung

Für die Priorisierung der einzelnen Anforderungen haben wir uns entschieden, die Reproduzierbarkeit und Übertragbarkeit als wichtigste Anforderung einzustufen. Für die Umsetzung arbeiten wir strikt mit diesen drei zentralen Methoden:

  • Infrastructure as Code
    Manuelles Eingreifen auf den Cloud-Servern ist nicht notwendig, sämtliche Aktivitäten werden mit Skripten automatisiert, die via Versionskontrolle (git) verwaltet werden.
  • Templates und Images
    Durch die Verwendung von Templates als “Kochrezepte” und daraus resultierende Images – sowohl sog. Amazon Machine Images wie auch Dockerimages – sorgen für Reproduzierbarkeit in unseren Systemen.
  • CI/CD
    Continuous Integration (CI), Continuous Delivery (CD) und Continuous Deployment sind die Kernkonzepte von CI/CD, die wir unserer Arbeit ebenfalls zu Grunde legen. Der Release-Prozess insbesondere für unsere eingesetzten Images, welcher ausführliche Test-Phasen durchläuft, lässt nicht den Rechner eines einzelnen Entwicklers zur Quelle von “Works for me” Systemen werden. Das zentrale CI/CD System übernimmt die Bereitstellung der Komponenten und unterstützt die Reproduzierbarkeit.

Unter Einhaltung dieser drei Methoden ist in unserem Setup die Erstellung und Konfiguration von Infrastruktur oder Images mit Hilfe von Ansible umgesetzt. So stellen wir sicher, dass durch Wiederverwendung von Rollen und Playbooks immer die benötigten Tools vorhanden und konfiguriert sind.

Um diese Struktur auch für komplexe Cloud-Infrastrukturen gewährleisten zu können, setzen wir in Abhängigkeit vom Zielsystem ein bis mehrere Cloudformation-Templates auf, welche eine reproduzierbare Zielumgebung garantieren. Das Softwaremanagement, also die Installation und Wartung von Applikationen, baut in unserem Konzept auf einem Mix von Amazon Machine Images (AMIs) und der Containerisierung mit Docker auf.

In unserem Ablauf wird demnach für jede Applikation ein eigenes Docker-Image erstellt und getestet. Ist der Test der einzelnen Images erfolgreich, werden diese durch Bamboo mit einem entsprechenden Tag versehen und publiziert. Im Anschluss erstellt Bamboo ein entsprechendes AMI, auf welchem die vorbereitenden Docker-Images bereits vorliegen und dadurch alles für den Betrieb vorbereitet ist.

Der Rollout der AMIs erfolgt durch eine Aktualisierung des jeweiligen mittels CloudFormation-Template angelegten Stacks.

Somit sind in unserem Betriebskonzept die Docker-Installation sowie der Host als vollkommen volatile Daten eingestuft, die jederzeit zurückgesetzt werden können.

Die Persistierung der Daten erfolgt für die in Amazon Web Services (AWS) betriebenen Applikation durch Nutzung verschiedener AWS-Dienste. Hierbei dienen RDS (Relation Database Service) als Datenbankserver sowie EFS (Elastic File System) als Netzwerkspeicher. Die Anforderung der automatischen Sicherung wird in unserem Fall durch Amazon Backup durchgeführt, einem Dienst, der automatisiert Sicherungen von Datenbank und Dateisystem anlegt und geplant vorhält.

Um die Verfügbarkeit der Anwendung hinsichtlich Systemausfällen und Angriffen sicherzustellen, liegen unsere Applikationen generell hinter Network-, beziehungsweise Application-Loadbalancern, für welche Amazon selbst einen grundlegenden DDOS-Schutz bietet. Des Weiteren wird die Gesundheit jeder Anwendung durch spezifische Health-Checks geprüft und bei Erkennung von Ausfällen automatisch neu gestartet. Um die Anforderung der Sicherheit gegenüber Angriffen wie SQL-Injection, etc. gewährleisten zu können, wird eine Kombination von WAF (Web Application Firewall) und Guard Duty (Anomalieerkennung und Angriffserkennung) eingesetzt, welche automatisch verdächtigen Datenverkehr sperrt. Um die möglichen Angriffsvektoren auf die Applikationsserver weiter einzuschränken, ist das Applikationsnetz strikt vom direkten Internetzugriff getrennt, sodass ein Zugriff also nur über die Loadbalancer, der Internetverkehr nur über ein NAT-Gateway möglich sind. Sofern ein administrativer Zugriff notwendig ist, wird ein entsprechender Bastion-Host (Sprungserver) zu diesem Zweck gestartet, sodass ein entsprechend abgesicherter Sprung ins Apllikationsnetz möglich ist. Der Status der Applikationsserver wird ferner durch CloudWatch Metriken sowie den Amazon Simple Systems Manager überwacht. Ein Zugriff auf die entsprechende Konsole ist durch dedizierte Rollen eingeschränkt und erfordert eine Authentifizierung mittels zweitem Faktor.

AWS Cloud

Zusammenfassung

Um die gestiegenen Anforderungen an den Betrieb von Applikationen im Internet zu gewährleisten wechseln immer mehr Kunden zu Software as a Service oder Platform as a Service Anbietern. Wir als it-economics bieten unseren Kunden ein maßgeschneidertes Paket für den gemanagten Betrieb ihrer Applikationen in unserem Managed Hosting. Sollte das Managed Hosting keine Option sein, bieten wir die Option Managed Service, also den dockerisierten Anwendungsbetrieb auf Ihren Servern.

 

Autoren: Alexander Barth, Christian Walonka