© Liashko/Shutterstock.com
Docker-Container ohne eigene Server in der Microsoft-Azure-Cloud

Serverless-Container in Azure


Containertechnologie ist ein heißes Thema. Jeder spricht darüber, viele möchten sie einsetzen, erst wenige tun es im größeren Stil. Der Grund für die Zurückhaltung ist meiner Erfahrung nach oft Respekt vor der großen und komplexen Basisinfrastruktur, die man braucht, um eine nennenswerte Anzahl an Containern sicher und hochverfügbar zu betreiben. Muss für den professionellen Einstieg in die Containerwelt erst einmal eine Menge Basiswissen über Registries, Kubernetes und Co. gesammelt werden? Nicht, wenn man sich für Serverless-Containerdienste in der Cloud entscheidet.

Bevor wir uns in die Containerwelt stürzen, ein paar Sätze über Serverless: Das Konzept scheint zu implizieren, dass man keine Server mehr braucht, um seine Software in der Cloud zu betreiben. Natürlich ist das nicht der Fall, irgendwo müssen Server stehen und jemand muss sich um sie kümmern. Der Unterschied von Serverless zu Infrastructure as a Service (IaaS) und Platform as a Service (PaaS) ist, dass die Server für den Benutzer des jeweiligen Clouddiensts noch weiter abstrahiert sind. Man kümmert sich weder um die Installation noch um die Wartung und auch nicht um die Skalierung der Server. Das alles übernimmt der Cloudanbieter.

Dazu kommt ein verändertes Preismodell. Bei IaaS und PaaS bezahlt man, was man reserviert. Im Gegensatz dazu bezahlt man bei Serverless, was man wirklich nutzt (z. B. Speichermenge, CPU-Sekunden). Insofern kann man IaaS und PaaS mit einem Hotel und Serverless mit Strom vergleichen. Das Hotelzimmer muss man reservieren und man bezahlt, auch wenn man nicht darin schläft. Serverless ist wie Strom aus der Steckdose. Man verlässt sich darauf, dass er da ist, wenn man ihn braucht und man bezahlt die tatsächlich in Anspruch genommene Leistung.

Die Entwicklung von IaaS über PaaS zu Serverless ist in der Microsoft Azure Cloud noch nicht abgeschlossen. Die ersten beiden sind seit Langem verfügbar und robust. Serverless ist vergleichsweise neu. Nicht alle containerbezogenen Serverless-Dienste in Azure sind der Preview-Phase entwachsen, beziehungsweise gibt es noch Einschränkungen bezüglich automatischer Skalierung und nutzungsbasierender Verrechnung. Dieser Artikel konzentriert sich auf die bereits verfügbaren Serverless-Containerangebote und geht auf wichtige Einschränkungen und Integrationsmöglichkeiten ein.

Azure Container Registry (ACR)

Fertige Images sind einer der großen Vorteile der Plattform Docker. Egal ob Betriebssystem, Datenbank oder Webserver, für nahezu jede gängige Serverplattform gibt es Images, die man entweder unverändert nutzen (z. B. Microsoft SQL Server [1]) oder als Basis für eigene Images (z. B. .NET Core Runtime auf Alpine Linux [2]) verwenden kann. Die Firma Docker betreibt eine Public Registry, auf die man über zwei Wege zugreifen kann:

  1. Docker Hub [3]: Hier findet man alle öffentlich zugänglichen Images der Docker Public Registry. Manche Images mit kommerziellen Produkten werden von Docker Vendor Partners wie Microsoft veröffentlicht. Für Open-Source-Projekte gibt es Official Images, die von der jeweiligen Community gewartet werden. Neben diesen beiden Varianten mit offiziellem Charakter kann aber jeder Benutzer eigene Images in den Docker Hub laden. Die Nutzung dieser Images erfolgt auf eigene Gefahr.

  2. Docker Store [4]: Über dieses Frontend stehen nur die Images der Docker Vendor Partners zur Verfügung.

Welchen Weg soll man gehen, wenn man als Softwarehersteller eigene Images veröffentlichen will? Man könnte sich als Docker Technology Partner zertifizieren lassen und Images im Docker Store veröffentlichen. Das ist eine gute Option, wenn man Software an Externe verteilen will. Für interne Images oder Images, die nur einem eingeschränkten Kundenkreis zur Verfügung gestellt werden sollen, ist es aber kein gangbarer Weg.

Genau diese Lücke füllt die Azure Container Registry [5] (kurz ACR). Technisch basiert sie auf der Open-Source-Implementierung der Docker Registry, die auch Basis für Docker Hub und Docker Store ist. Sie ist aber insofern privat, als dass man sie in der eigenen Azure Subscription anlegt und den Zugang über Azure-AD-Konten regelt. Neben dem Speichern von Linux- und Windows-basierenden Images kann ACR auch das Bauen von Images übernehmen. Man muss also keinen eigenen Docker Daemon betreiben, um beispielsweise im Rahmen des CI-/CD-Prozesses Images zu erstellen. Das kann ACR mit dem Kommando az acr build für einen übernehmen (diese Funktion ist aktuell in der Preview-Phase und daher für den Produktivbetrieb noch nicht freigegeben). Auch das automatische Bauen von abgeleiteten Images bei einem Git Commit oder bei Änderung eines Basis-Image beherrscht ACR mit dem az acr build-task-Kommando (ebenfalls noch als Preview). Um ACR nahtlos in automatisierte Prozesse einbinden zu können, unterstützt der Dienst Webhooks, also das Senden eines HTTP-POST-Requests, wenn sich etwas am Inhalt des Repositories ändert (Push oder Delete eines Image).

Einsatzszenarien für ACR

Hier einige Beispiele für typische Einsatzszenarien von ACR:

  • Sie sind Softwarehersteller und möchten nur Ihren Kunden Zugriff auf Ihre Images geben. Über Azure AD steuern Sie die Zugriffsrechte.

  • Sie entwickeln interne Software und brauchen eine Registry zum Verteilen der Images auf Ihre eigenen Server im Haus oder in der Cloud.

  • Sie betreiben Anwendungen über die ganze Welt verteilt in mehreren Azure-Rechenzentren. Mit dem ACR-Premium-Preisplan können Sie I...

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

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