Die Container-Technologie ist seit längerer Zeit in aller Munde, jedoch kommen erst jetzt immer mehr Kunden im Schweizer Markt mit Ihr in Berührung.
Die Grundlagen
Die Technologie sollte mittlerweile den meisten in der IT-Branche geläufig sein. Ich möchte hier aber Trotzdem kurz und bündig auf die Unterschiede eingehen.
Dazu möchte ich das obige Bild, aus einem Kurs den ich mal entwickelt habe, nehmen.
Links sieht man einen typischen Type-1 Hypervisor. Type 1, weil für den über der Hardware nur eine dünne Virtualisierungsschicht läuft und nicht ein volles Betriebssystem, wie das etwa bei VirtualBox oder Parallels etc. der Fall ist. Die bekanntesten Vertreter sind vSphere, KVM, Hyper-V (Server).
In der Mitte sehen wir das „typische“ Container Design. Wir haben ein Betriebssystem und abstrahiert einzelnen Container. Simplifiziert gesagt, stellt der Container auf dem Betriebssystem einen Prozess mit speziell „eingeschränkten“ Zugriffen auf die Systemressourcen dar.
Rechts sehen wir eine Vermischung der Technologien. Z.B. für Hoster sehr interessant. Durch die Virtualisierung haben wir eine grössere Abstraktion und in der VM selbst können wir wieder multiple Container laufen lassen.
Azure Container Instances (ACI)
Der Dienst ermöglicht es mir sehr schnell einen Container, ohne das Konfigurieren irgendeiner Plattform zu starten. Persönlich sehe ich den Dienst aber eher für eine sehr simple Applikationen oder für kleinere Tasks. Will ich eine mehr Möglichkeiten zur Orchestrierung und Skalierung haben, so würde ich jedem empfehlen, direkt auf den Azure Kubernetes Service (AKS) zu wechseln.
Azure Kubernetes Service (AKS)
Der Vorteil von AKS ist, dass der Grundaufbau durch Azure vorgenommen wird und die „Management-Nodes“ nicht verrechnet werden. Das heisst, als Kunde zahle ich nur die Worker-Nodes. Das heisst wiederum, nur die Leistung, die ich aktiv verwende.
Wichtigsten Basis Elemente von Kubernetes:
Node: Maschinen, welche die zugewiesenen Tasks ausführen.
Pod: Ein Set von einem oder mehreren Containern, welche auf eine Node erstellt werden. Das kleinste „Objekt“, das es auf Kubernetes gibt.
Service: Die Möglichkeit eine Applikation, welche auf Pods läuft, von der „Aussenwelt“ erreichbar zu machen.
Kubectl: Ein Command Line Interface (CLI), mit welchem man den Kubernetes Cluster verwalten kann.
kubelet: Ein „Agent“, welcher auf jedem Node läuft. Er kommuniziert mit dem „Control Panel“ und stellt sicher, dass die Container eines Pods laufen.
Eine Applikation wird also getrennt vom Service definiert. Dies geschieht in YAML, einer beschreibenden Sprache.
Das heisst, um eine Applikation der Aussenwelt bekannt zu machen, muss man mindestens eine app.yml und eine service.yml Datei erstellen.
Beispiel einer app.yml
Beispiel einer service.yml
Erste Schritte mit AKS
Um zu sehen, wie unglaublich einfach die Erstellung ist, gehen wir jetzt einmal die ersten Schritte durch. In späteren Blogs sehen wir dann noch die Details, wie auch die Integration in eine DevOps-Pipeline etc.
Im „Azure Portal“ suchen wir nach AKS.
Dort angelangt, gehen wir auf „Add“
Dort setzen wir im ersten Blade als erstes die Subscription, Namen, Location und Version.
Wichtig: Am Ende des Blades wählen wir die Grösse für unsere Worker Nodes aus. Für die Hochverfügbarkeit empfiehlt es sich normalerweise, mindestens drei Nodes zu erstellen.
Für diese Demo nehme ich einen Node. Dies kann man später, je nach Bedarf, hochskalieren.
Jetzt können wir auf „Review + create“ gehen und haben bereits einen lauffähigen AKS Cluster.
Im nächsten Post werden wir unser erstes Container Image erstellen und auf ein Azure Container Registry „hochladen“.
Mit Hilfe der hier aufgeführten App und Serivce Templates, können wir unseren ersten Demo-Service erstellen.
Also Vorbereitung dazu können Sie ja schon einmal Visual Studio installieren 🙂 Die Community Edition reicht.
