DOCKER UND AWS

Dynamisches Hosting mit Docker und Amazon Web Services

Begriffe wie "Docker", "Infrastruktur als Code" und "DevOps" schwirren nach wie vor herum. Dieser Artikel will zeigen, wo der Vorteil in realen Anwendungen liegt und wie sie interagieren.
Dynamische Infrastruktur
In einer dynamischen Infrastruktur werden zusätzliche Server automatisch gestartet, wenn sie benötigt werden. Zwei Server sind beispielsweise in der Lage die Last am Morgen um 9 Uhr morgens bewältigen. Während des Tages und mit einer steigenden Anzahl von Anwendern werden zusätzliche Server gestartet. Zum Beispiel laufen mittags 12 Server. Die Anzahl der laufenden Server steht im Verhältnis zur Anzahl der (aktiven) Anwender. Abhängig von der Anwendung könnte es beispielsweise am Vormittag und am späten Nachmittag Lastspitzen geben.
 
Beispielsweise ist während der Nacht eine geringe Nutzung denkbar, so dass die Anzahl der Server auf ein Minimum reduziert werden kann, nur um eine Zahl zu nennen auf 2 Server. Warum nicht auf einen reduzieren? Aus Sicherheitsgründen kann sich die Anwendung an zwei verschiedenen Datencenterorten befinden. Wenn ein Datencenter ein Problem hat, "brennt noch eine Kerze“ in der anderen.
 
Cloud-Dienste wie Amazon Web Services berechnen normalerweise Server auf Minutenbasis. Das spart Geld in Zeiten geringer Nutzung. Bei Bedarf ist jedoch genug Leistung vorhanden. In den Wochen vor Weihnachten könnte es beispielsweise in Spitzenzeiten 30 Server geben. Was auch immer für eine konstante Leistung und eine hervorragende User Experience erforderlich ist.
 
Dabei werden die Server nicht manuell gestartet und gestoppt. Es gibt auch keinem Zeitplan. Die Choreographie, wenn zusätzliche Server gestartet oder heruntergefahren werden, wird in einer sogenannten Metrik definiert. Die Metrik definiert, bei welcher Serverlast zusätzliche Server für den Start vorbereitet werden und wann sie tatsächlich auf die „Bühne“ dürfen. Der Kaltstart eines neuen Servers dauert 1-2 Minuten. Die Feinabstimmung dieser Metrik ist der Schlüssel für eine beständige Leistung bei minimalen Kosten. Sobald die Metrik verfeinert ist, verwaltet sich die Umgebung dynamisch selbst. Regelmäßige Überprüfungen durch qualifizierte Administratoren sind jedoch empfehlenswert.
 
Ein Anwender merkt nicht, was auf der IT-Infrastrukturebene geschieht, wenn Server gestartet oder gestoppt werden. Die Anwendung ist einfach nur immer "da“.
 
In der Vergangenheit waren am häufigsten statische Umgebungen anzutreffen. Deren Nachteil ist offensichtlich. Die Serverkapazität muss sich an der zu erwartenden Spitzenlast orientieren. Ein Großteil dieser maximalen Kapazität wird also meistens nicht genutzt. Eine statische Umgebung erfordert an 24 Stunden am Tag und das das ganze Jahr über den finanziellen Aufwand zu betreiben, den man eigentlich nur für die Spitzenzeiten benötigt.
 
Der größte Feind einer statischen Infrastruktur ist der Erfolg. Aus Kostengründen wird in vielen Fällen eine statische Infrastruktur mit nicht allzu viel Reserve aufgebaut. Jede erfolgreiche Marketingkampagne (oder was auch immer die Nutzung und damit die Last erhöht) bedeutet daher eine latente oder akute Bedrohung der Infrastruktur. Je erfolgreicher das Marketing ist, desto langsamer wird die Web-Anwendung – oder die Server funktionieren in Folge von Überlastung überhaupt nicht mehr. Eine gut gemachte dynamische Infrastruktur bewältigt diese Spitzen mit Leichtigkeit, ohne Leistungsabfall und vermeidet den "Erfolgskonflikt".
 
Mit dynamischem Hosting lässt sich auch Redundanz schaffen: Server werden automatisch in einem anderen Datencenter gestartet, wenn ein Problem im Hauptdatencenter vorliegt. Regionales Hosting ist eine weitere Option. Für global laufende Web-Anwendungen ist es sinnvoll, die entsprechende Infrastruktur näher bei den Anwendern zu haben, da die Internet-Verbindungsgeschwindigkeit über größere Entfernungen sinken kann. Für Anwender in Asien kann sich beispielsweise eine Webanwendung, die auf Servern in Europa oder Amerika läuft, langsam anfühlen. In diesem Fall ist es sinnvoll, Server in einem asiatischen Rechenzentrum aufzusetzen. Die Infrastruktur ist dabei typischerweise global vernetzt.
 
Falls einer der Anwendungsserver ein Problem hat ("hängt"), ist kein manuelles Eingreifen erforderlich. Durch die Verwendung von Selbstheilungsfunktionen wird der Server automatisch aus dem Betrieb genommen, gelöscht, dann installiert, konfiguriert und wieder in Betrieb genommen. Es bleibt dabei, dass die Inbetriebnahme eines Servers etwa 1-2 Minuten dauert und von den Anwendern nicht bemerkt wird. Das bedeutet, dass sich die Hosting-Umgebung ohne manuelle Arbeit von Server-Administratoren selbst reparieren kann, ohne dass die Anwender ein Problem bemerken.
 
Updates sind dem Selbstheilungsprozess sehr ähnlich. Ein Update bedeutet, den Anwendungsservern einfach nur mitzuteilen, dass eine neue Software-Version verfügbar ist. Server für Server wird aus dem Dienst entfernt, gelöscht und erneut installiert, jetzt aber mit der neuen Software-Version. In vielen Fällen ist es nicht erforderlich, während der Installation von Updates eine Wartungsseite anzuzeigen. Updates können während des normalen Betriebs installiert werden.
Dynamisches Hosting ist beeindruckend, leicht zu erklären und die Vorteile liegen auf der Hand. Aber es gibt noch mehr zu entdecken!
Infrastructure As Code
Infrastructure As Code ist weniger spektakulär als dynamisches Hosting, hat ebenfalls ein enormes Potenzial.
 
Um die Vorteile von Infrastructure As Code zu verstehen, werfen wir einen Blick auf den traditionellen Ansatz. Nicht nur die Server waren größtenteils statisch, sondern auch deren Einrichtung und Konfiguration waren hauptsächlich manuelle Schritte.
 
Es mag das Management überraschen, aber es ist kein Geheimnis für Server-Administratoren, dass Infrastruktur-Setup und Änderungen oft nicht oder nicht ausreichend dokumentiert werden. Mit anderen Worten, man kann in einen Raum mit Server-Administratoren eine große Stille erzeugen, wenn man nach einem Installations- und Änderungsblog fragt. Auf der anderen Seite ist das Dokumentieren zeitaufwendig und Server-Administratoren stehen immer unter großem Druck, insbesondere Änderungen durchzuführen sind. In einer Notfallsituation kann eine ordnungsgemäße Dokumentation jedoch „lebensrettend“ sein. Andersherum ist eine Änderung an der Infrastruktur ohne Dokumentation bis zu einem gewissen Grad wie das Fahren im Dunkeln mit ausgeschalteten Scheinwerfern.
 
Infrastructure As Code funktioniert am besten in virtuellen Umgebungen. Das Öffnen des Kartons in dem ein neuer Server geliefert wird und das Anschließen der Kabel kann nicht als Code geschrieben werden (außer es gibt Roboter ...). In einer virtuellen Umgebung können diese Schritte wie auch alle weiteren Setup- und Konfigurationsarbeiten als Code geschrieben werden.
 
Im Falle eines Totalverlusts kann die Wiederherstellung der Infrastruktur Hunderte von manuellen Schritten und mehrere Arbeitstage in einer traditionellen Umgebung erfordern – abhängig auch von der Existenz und Qualität der Dokumentation. Mit der Infrastructure As Code kann sogar eine sehr komplexe Serverumgebung in 30 Minuten komplett eingerichtet und konfiguriert werden. Ein "Mausklick" ist die einzige manuelle Arbeit, die dafür notwendig ist.
 
Der totale Verlust der Infrastruktur ist natürlich kein allzu wahrscheinliches Szenario. Der Wiederaufbau einer Infrastruktur erklärt lediglich die allgemeine Idee von Infrastructure As Code. Es gibt zahlreiche Vorteile, die Infrastruktur in Form von Source-Code zu haben. 
 
Es ist übliche Praxis für Source-Code eine Versionskontrolle zu haben und ebenso kann der Code, der die Serverinfrastruktur definiert, auch versioniert werden. Infrastrukturänderungen sind kontrolliert, vollständig nachvollziehbar, versioniert und können, falls erforderlich, einfacher rückgängig gemacht werden. Da das Risiko geringer ist, ist es sinnvoll, die Infrastruktur häufiger zu optimieren und über mehr Leistung zu geringeren Kosten zu erzielen. Auch das Arbeiten in Teams an der Server-Infrastruktur ist einfacher, da zuerst der Code geschrieben wird, dann mögliche Teamarbeitskonflikte gelöst werden und erst zuletzt die endgültige Infrastrukturdefinition als Ganzes angewendet wird.
 
Beim Ausrollen neuer Software-Versionen ist es üblich, sie in einer Staging- (oder Integrations-) Umgebung zu testen, bevor sie „live“ gehen. Das Einrichten dieser "Test" -Umgebung ist nicht nur schneller und einfacher, es ist auch garantiert, dass die Testumgebung absolut identisch ist. Die manuelle Einrichtung einer Staging-Umgebung, die mit der Produktionsumgebung identisch ist, erfordert lange, harte, konzentrierte Arbeit (und ist dabei eher langweilig). Failover-Redundanz und Backup-Lösungen sind klar definiert und es ist einfacher, Diskrepanzen zu erkennen, statt sich in falscher Sicherheit zu wiegen.
 
Infrastructure As Code ist eine hervorragende Idee für dynamische Infrastrukturen. Wenn Server nicht mehr benötigt werden, können sie einfach gelöscht werden, was Kosten spart und die Struktur transparent hält. Wenn ein neuer Server gestartet wird, wird er innerhalb von 1-2 Minuten automatisch „von Null auf“ neu eingerichtet und konfiguriert. Dies geschieht immer und immer wieder und dabei absolut zuverlässig.
 
In internationalen Infrastrukturen sind mit Infrastructure As Code Server weltweit auf identische Weise eingerichtet, was die Verwaltung und Kontrolle so einfach wie möglich macht.
 
Ein Mangel an Dokumentation in der IT ist ein nicht zu unterschätzendes Risiko für jedes Unternehmen bzw. jede Organisation. Mit Infrastructure As Code gibt es eine vollständige, lesbare und versionierte Dokumentation der Umgebung.
Docker
Infrastruktur als Code wird oft in Verbindung mit Docker angetroffen. Docker führt eine andere Denkweise für das ein, was bisher unter dem Begriff "Server" verstanden wurde. Mit Docker wird eine Anwendung in kleinere Teile aufgespaltet, die dann als einzelne Dienste in Docker-Containern ausgeführt werden. Die Docker-Container kommunizieren miteinander, so dass die Anwendung wiederum als Ganzes ausgeführt werden kann. Erst für eine dockerisierte Anwendung ist eine individuelle und optimale Konfiguration der Docker-Container möglich.
 
Es ist kein geheimer Trick, sondern eine Standardvorgehen in der IT größere Probleme zu lösen, indem man sie in kleinere Teile aufteilt und dann die einzelnen Lösungen mit dem verbindet, was das größere Problem löst. Natürlich hat dieses Verfahren seinen eigenen Namen: teile und herrsche (oft auch lateinisch „divide et impera“). Bei höherer Komplexität ist Modularisierung das Schlüsselwort, um "Glück" durch Vorhersagbarkeit und Zuverlässigkeit zu ersetzen. Aber es lässt sich auch ohne Docker modularisieren, weswegen das alleine noch nicht der Punkt ist. Die Modularisierung ist bis hierhin zunächst nur eine Voraussetzung für den Einsatz von Docker. 
 
Eine der größten Herausforderungen beim Verwalten von Serverinfrastrukturen für komplexe Anwendungen besteht darin, zueinander passende Versionen für Bibliotheken, Basisanwendungen und andere Komponenten von Drittanbietern zu finden. Mit anderen Worten, es ist oft ein zeitraubendes Puzzle, einen Server für die Installation einer Anwendung vorzubereiten. Da mindestens aus Sicherheitsgründen Updates benötigt werden, beginnt das Puzzle mit jeder neuen Version von vorne. Neben der Kompatibilität sind auch Optimierungen eine Herausforderung. Eine Konfigurationseinstellung, die ideal für Modul A ist, kann das Modul B verlangsamen.
 
Wäre es nicht eine gute Idee, wenn jeder Teil (Service) der Anwendung eine eigene technische Plattform hätte? Das ist in der Tat die Kernidee von Docker. Die Umgebung für jedes Modul der Anwendung wird als Docker-Container bezeichnet. Das mag zunächst so klingen als wäre es umständlich, aber in der Praxis ist es einfacher, mehrere Docker-Container zu verwalten, als das Puzzle zu lösen. Infrastructure As Code ermöglicht dabei die effiziente Kontrolle über mehrere Docker-Container.
 
Die Anwendung oder besser jedes Modul der Anwendung wird mit dem zugrunde liegenden System gebündelt. Wie bereits erwähnt, vereinfacht das die Einrichtung und Verwaltung der Anwendung und ihrer Umgebung. Docker macht die Anwendung letztlich auch unabhängig vom Betriebssystem.
 
Dies ist im Wesentlichen das gleiche wie es aus der Virtualisierung bekannt ist. Das Ausführen eines Windows-Servers als virtuelle Maschine macht ihn unabhängig von der Hardware –  und damit den jeweiligen Treibern. Die Hardware ist dann immer die gleiche: die "simulierte", virtuelle Hardware. Und diese ändert sich nicht, wenn eine Serverhardware ausgetauscht wird. Docker kombiniert die Vorteile der Virtualisierung mit den Vorteilen der Modularisierung von Anwendungen.
 
Eine reproduzierbare, unabhängige Umgebung bietet auch große Vorteile beim Testen neuer Versionen einer Software. Eine 100% identische Testumgebung eliminiert eben ein weiteres Risiko.
Amazon Web Services
Amazon Web Services verwendet eine Technologie, die im Wesentlichen mit der von Docker identisch ist. Mit der Docker-Technologie kommt auch eine andere Denkweise in das Hosting. Man bezahlt jetzt eher für Rechenzeit als einen Server zu mieten. Darüber hinaus können die Docker-Container perfekt auf die Anforderungen zugeschnitten werden. Das bedeutet, dass sich gegebenenfalls auch ein günstigeres Amazon Web Services-Produkt wählen lässt, wenn dies für die Anforderungen ausreicht. Amazon verwendet tatsächlich Konfektionsgrößen wie S, M, L, XL, XXL, bietet aber auch Produkte mit unterschiedlichen Features an. Das richtige Produkt in der richtigen Größe für jeden Docker-Container zu finden, kann eine Herausforderung sein, zahlt sich aber aus, indem die Betriebskosten an das gewünschte Maß an Leistung und Zuverlässigkeit angepasst werden können.
DevOps
Die Entwicklung von Web-Software und die Ausführung auf Servern waren früher zwei verschiedene Tätigkeitsbereiche. Technologien wie Docker und Cloud-Dienste wie Amazon Web Services führen zu einer anderen Denkweise über die Infrastruktur ein. DevOps bedeutet, dass das Software-Entwicklungsteam einige Verantwortlichkeiten von den Server-Administratoren übernimmt. Da die Infrastruktur als Code definiert ist, gibt es eine sauber strukturierte Schnittstelle zwischen Softwareentwicklern und Server-Administratoren.

Die Softwareentwickler haben die tiefgreifendsten Kenntnisse der Anwendung, der Module der Anwendung und wie sie interagieren. Es naheliegend, dass die Spezialisten, die nah an der Software-Entwicklung sind, mit ihrem Wissen die jeweiligen Teile der Infrastruktur definieren.
Leistungen von h.com
h.com entwickelt Web-Software, die für Docker bereit ist. Falls notwendig ist dabei völlig unproblematisch diese auf einem „traditionellen“ Server-Setup auszuführen. Wenn Sie andere Anforderungen haben, entwickelt h.com ihre Anwendung maßgeschneidert für ihre Umgebung.
 
h.com unterstützt Sie auch bei der Migration ihrer bestehenden Anwendung zu einer dynamischen Infrastruktur. Amazon Web Services bietet große Anzahl von Produkten (die man auch „Dschungel“ nennen könnte). Die richtigen zu finden und richtig einzurichten ist nicht immer einfach. Wir können sie bei der Einrichtung einer Amazon Web Services-Infrastruktur unterstützen oder diese Aufgabe komplett für sie übernehmen. Oder wir unterstützen wir sie beim Dockerisieren Ihrer bestehenden Anwendung. Wir sind da, wo sie uns brauchen. 
 
Als Teil der DevOps-Idee überwacht und optimiert h.com auch die Infrastruktur und passt sie an, wenn ein Software-Updates dies erfordern.
 
h.com erstellt komplexe Setups mit Skalierbarkeit, Redundanz, Failover-Strategie und Backup-Lösungen. Mit der Erfahrung komplexer internationaler Infrastrukturen können wir genauso gut der Leuchtturm im Nebel der Cloud bei der Einrichtung kleinerer Umgebungen sein. 
Christian Haag, 
Gründer und Geschäftsführer von h.com networkers GmbH
h.com networkers GmbH
Schäferstraße 4
40479 Düsseldorf
Germany
Contact us
+49 (211) 233942-0
info@hcom.de
Information About Cookies On This Site
We use cookies on the site for our own business purposes including keeping track of your preferences and collecting aggregated statistics to analyze how our site is used. By using this site you agree that cookies are stored.