© 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äufig...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang