© Stmool/Shutterstock.com
Tutorial: Einführung in Azure Container Services

Container - die Azure-Edition


Viele Anwendungen bewegen sich in Richtung eines containerbasierten Ansatzes, und das aus gutem Grund: Container ermöglichen es uns, die Umgebungsanforderungen unserer Anwendung von der Anwendung selbst zu trennen.

Anstatt uns Gedanken darüber zu machen, wie wir unsere Anwendung so konfigurieren, dass sie auf verschiedenen Zielumgebungen läuft, können wir mit Hilfe von Containern explizit angeben, welche Art von Umgebung unsere Anwendung benötigt, und diese Umgebung dann automatisch für uns erstellen lassen. Von unserer lokalen Entwicklungsumgebung über das private Rechenzentrum unseres Unternehmens bis hin zu einem öffentlichen Cloud-Angebot wie Azure können Container uns dabei helfen, sicherzustellen, dass genau die gleiche Umgebung für das Hosting unserer Anwendung erstellt wird. Der Traum eines jeden Entwicklers! Wie aber sind wir hier gelandet? Dazu ist es hilfreich, uns zunächst anzuschauen, wie Softwareentwicklung vor dem Aufkommen von Containern aussah.

Bevor Container immer beliebter wurden, herrschten im standardmäßigen Workflow der Softwareentwicklung noch einige Probleme vor. Insbesondere die beiden nachfolgend beschriebenen waren ziemlich unbequem und erschwerten uns die Arbeit als Entwickler erheblich.

Fallstrick #1: Multiple Zielumgebungen

Der erste Fallstrick ist einer der ältesten Programmiererwitze überhaupt, vielleicht sogar älter als der über das Beenden von Vim: Das allzu häufige Problem von Anwendungen, die zwar auf unserer eigenen Maschine laufen, aber nirgendwo sonst. Als Anwendungen komplexer wurden und Entwickler Zugang zu mehr Entwicklungsumgebungen erhielten, stießen wir auf Probleme, wenn es darum ging, alles an einer Vielzahl von Orten gleichermaßen zum Laufen zu bringen. Bisweilen funktioniert eine Anwendung auf dem eigenen Rechner gut, vielleicht sogar auch bei QA und Staging – aber sobald sie in der Produktion eingesetzt wird, schlägt sie aus irgendeinem Grund fehl. Beim Debugging sieht man die Ursache in einer subtilen Abhängigkeit von der eigenen Produktionsumgebung. Vielleicht hat man eine Library-Version, z. B. Entity Framework, auf Version 6.3 aktualisiert, aber die entsprechende Abhängigkeit von .NET Core nicht auf 3.1 aktualisiert. Oder vielleicht wurde die falsche Konfigurationseinstellung angewendet, wodurch ein dev-Wert anstelle eines prod-Werts blieb. Diese Art subtiler Unterschiede in den Umgebungen bereitete Kopfschmerzen und führte nicht selten zu stundenlangem undurchsichtigem Debugging.

Ein weiteres häufiges Szenario: Neueinstellungen von Mitarbeitern. Ich weiß, dass einige Teams das inzwischen sehr gut machen, aber ich erinnere mich an die Tage, an denen neue Kollegen eingestellt wurden, und wie der Prozess der Einrichtung ihrer Entwicklungsumgebung eine ganze Woche dauern konnte. Manchmal erhalten sie den Rechner eines Vorgängers, und wenn wir Glück haben, bleiben die meisten Abhängigkeiten unserer Codebasis bestehen. Am wahrscheinlichsten ist jedoch, dass unsere neuen Kollegen einen völlig neuen oder komplett gelöschten Rechner erhalten und wir ihn von Grund auf neu einrichten müssen. Denken Sie jetzt an das letzte Mal, als Sie einem Kollegen helfen mussten, Ihre Codebasis von Grund auf neu einzurichten. Es sollte keine Überraschung sein, dass wir, nachdem wir uns mit unseren eigenen Umgebungen vertraut gemacht haben, alle gelernten Macken, zusätzlichen Schritte und die vollständige Liste der Abhängigkeiten vergessen, die erforderlich sind, um die Codebasis startklar zu machen. Diese Art von Szenarien war für Container wie geschaffen.

Fallstrick #2: Portabilität

In einer idealen Welt könnten sich alle Entwickler auf die Erstellung von Anwendungen für eine einzige Plattform konzentrieren. Die Realität sieht jedoch so aus, dass viele Anwendungen mehrere Plattformen und Geräte unterstützen müssen. Und nun, da Cloud-Anbieter immer häufiger als Hosts für unsere Anwendungen auftreten, sind Lift and Shifts in die Cloud auf die Portabilität dieser Anwendungen angewiesen. Vor der Einführung von Containern wurde das durch mühevoll erstellte Konfigurationsskripte, die Verwaltung vieler Umgebungsvariablen oder im schlimmsten Fall durch redundante und replizierte Codebasen erreicht, die auf eine bestimmte Plattform zugeschnitten waren. Zwar funktionierte das, aber es wurden viele Stunden damit verbracht, diese Kompatibilitäten für spezifische Umgebungen zu entwerfen und zu planen. Noch mehr Stunden wurden für die Fehlersuche bei Problemen aufgewendet, die durch diese unterschiedlichen Umgebungen verursacht wurden.

Was genau sind Container?

Es gibt viele Möglichkeiten, Container zu beschreiben, doch diese halte ich für die simpelste: „Ein Container ist ein unabhängiges Paket von Software und deren Abhängigkeiten.“ Im Zusammenhang mit der Softwareentwicklung erlaubt uns diese Definition, uns auf die praktische Anwendbarkeit von Containern zur Lösung der zuvor diskutierten Probleme zu konzentrieren. Schlüsseln wir diese Definition einmal auf: Was meinen wir, wenn wir von Abhängigkeiten sprechen? Das sind all die Dinge, die die Anwendung erfordert, um ihre eigene Umgebung zu bauen und darin zu laufen. Das beinhaltet natürlich unseren Quellcode, aber auch die spezifischen Laufzeiten und bestimmte Bibliotheksversionen sowie alle Konfigurationseinstellungen, die unsere Anwendung benötigt. Diese Abhängigkeiten werden dann zu einem unabhängigen Paket gebündelt. Das Paket ist portabel, vorhersehbar und zuverlässig, weil es alles enthält. Zu diesem Zeitpunkt kümmert es uns nicht und es spielt auch keine Rolle, wo dieses Paket eingesetzt wird; das Paket ist selbsterhaltend. Diese Option hat sich bei der Lösung der kniffligen Probleme, die wir besprochen haben, als effektiv erwiesen. Vorbei sind die Zeiten des umgebungsbezogenen Troubleshootings und Debuggings. Neue Kollegen haben nicht mehr eine lange Anlaufzeit, um ihre Entwicklungsumgebung korrekt einzurichten. Durch die Containerisierung der Anwendungen muss sich das Entwicklungsteam mit vielen der Problemszenarien nicht mehr herumplagen.

Container Services in Azure

Falls Sie sich jetzt fragen, wie das Ganze zu bewerkstelligen ist, zeige ich Ihnen gerne, wie das geht – und zwar mit den Azure Container Services. Im Speziellen bietet...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang