Docker Container ohne eigene Server in der Microsoft Azure Cloud

Serverless Container in Azure
Keine Kommentare

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 Cloud-Diensts 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 Cloud-Anbieter.

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) oder als Basis für eigene Images (z. B. .NET Core Runtime auf Alpine Linux) verwenden kann. Die Firma Docker betreibt eine Public Registry, auf die man über zwei Wege zugreifen kann:

  1. Docker Hub: 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: Ü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 (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 az acr build-Kommando 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 Ihre Images automatisch innerhalb des Azure-Netzwerks in alle Ecken der Welt verteilen.
  • Sie möchten Ihre Software in Ihren CI-/CD-Prozessen in Docker Images verpacken, Sie betreiben aber keinen eigenen Docker-Host. In diesem Fall können Sie ACR verwenden, um die Images durch ACR in der Cloud zu erstellen und in Ihre ACR zu pushen.

ACR ist Serverless

ACR ist ein Paradebeispiel für Serverless. Man braucht keine virtuellen Maschinen, kümmert sich um keine Updates, braucht die Größe oder Anzahl von Servern nicht festzulegen und bezahlt, was man tatsächlich nutzt. Das Preismodell basiert auf der Größe der gespeicherten Images und auf den CPU-Sekunden, die man für das Bauen von Images verwendet. Details zu den ACR-Preisen findet man hier.

ACR Codebeispiel

Listing 1 zeigt ein Beispielskript, das mit Hilfe des Azure CLI eine Instanz von ACR anlegt, lokal ein Docker Image baut und dieses danach in der ACR veröffentlicht. Natürlich können alle Schritte auch im Azure Portal durchgeführt werden. Abbildung 1 zeigt exemplarisch einen Screenshot der ACR, wie sie nach dem Ausführen des Skripts aus Listing 1 aussieht. Achten Sie beim Durchsehen des Codebeispiels besonders auf die Tatsache, dass der Zugriff auf ACR über die Docker CLI problemlos möglich ist. Man kann Images pushen und pullen, ohne dafür auf Zusatzsoftware angewiesen zu sein. Das klappt, da ACR wie erwähnt genau die Open Source Docker Registry zugrunde liegt, die man auch vom Docker Hub kennt.

# Login and select subscription
az login
az account set --subscription ...

# Create resource group
az group create --name azure-caas-demo --location westeurope

# Create Azure Container Registry (ACR)
# Note that admin-enabled flag is for testing purposes only. Do not specify
# this flag for production systems. Use AAD principals instead.
az acr create --resource-group azure-caas-demo \
  --name azurecaas --sku Premium --admin-enabled

# Login to ACR to enable “docker push”
az acr login --name azurecaas

# Build an image locally (e.g. using Docker for Windows) that 
# you want to store in registry.
# Note the prefix of the image tag. It is the name of your ACR.
docker build -t azurecaas.azurecr.io/node:alpine .\base-image
docker tag azurecaas.azurecr.io/node:alpine azurecaas.azurecr.io/node:10-alpine

# Push image to ACR
docker push azurecaas.azurecr.io/node:alpine
docker push azurecaas.azurecr.io/node:10-alpine

# Show list of repositories in ACR
az acr repository list --name azurecaas --output table
az acr repository show-tags --name azurecaas --repository node --output table

# Let ACR build the image, you don’t need a local Docker Daemon anymore
az acr build --registry azurecaas --image node:alpine \
  -t node:10-alpine base-image
Abb. 1: Repository in ACR

Abb. 1: Repository in ACR

Rollout von Containern mit ACR

Alle Docker-bezogenen Azure-Dienste können Images aus ACR holen. Das gilt insbesondere für containerbasierende Azure Web Apps, Azure Container Instances (kurz ACI, dazu später mehr) und Azure Kubernetes Service (kurz AKS). Man muss aber nicht zwangsläufig Azure verwenden, um Container laufen zu lassen, deren Images aus ACR kommen. Auch Docker-Umgebungen, die im eigenen Rechenzentrum oder bei Kunden ausgeführt werden, können ihre Images aus ACR abholen. So richtig nützlich ist ACR aber, wenn man die Container auch im selben Azure-Rechenzentrum wie die Registry ausführt. Auf diese Weise reduziert man die über das Internet übertragene Datenmenge auf ein Minimum. Eine idealtypische Kombination von containerbezogenen Diensten in Azure könnte wie folgt aussehen:

  • Der Quellcode wird in VSTS mit Git eingecheckt.
  • Der CI-/CD-Prozess läuft in Build-Servern von Microsoft, die sich bereits innerhalb des Microsoft-Netzwerks befinden. Man hat als Kunde die Wahl, in welcher Region (z. B. Europa) der Quellcode gespeichert ist und der Build-Prozess läuft.
  • Der CI-/CD-Prozess verwendet ACR, um aus der Anwendung mit einem Docker-File ein entsprechendes Docker Image zu bauen. Der Code muss dafür das Microsoft-Netzwerk nicht verlassen und bleibt in der gewählten Region. Am Ende des Image Builds wird das Image automatisch in der ACR gespeichert.
  • ACR aktualisiert automatisch alle Images, die auf dem gerade gebauten Image basieren.
  • ACR repliziert optional die neuen Images in alle gewünschten Azure-Regionen.
  • Über Webhooks startet ACR automatisierte DevOps-Prozesse, die das Rollout der neuen Image-Versionen in den jeweiligen Containerplattformen (z. B. App Service, AKS, ACI etc.) übernehmen. Zum Automatisieren des Rollouts gibt es in Azure verschiedene hilfreiche Dienste wie Azure Automation, Azure Functions oder Logic Apps (z. B. für Prozess mit Einbindung von Menschen für Freigabeprozesse oder Behandlung von Ausnahmesituationen).

Azure Container Instances (ACI)

Wenn man sein Docker Image schon Serverless gebaut hat, will man natürlich auch den darauf aufbauenden Container Serverless in Azure betreiben. Der einfachste Weg dafür sind Azure Container Instances (kurz ACI) [8]. Eine ACI-Instanz ist etwas Ähnliches wie ein Pod in Kubernetes. Der große Unterschied ist aber, dass man einen Container in ACI binnen Sekunden starten kann, ohne dafür eine virtuelle Maschine mit Docker Daemon, ein Kubernetes-Cluster oder etwas Ähnliches konfigurieren zu müssen. Die Abrechnung erfolgt nach tatsächlichem Verbrauch von Speicher und CPU.

Hier eine Zusammenfassung der wichtigsten Eigenschaften von ACI:

  • In der Regel besteht eine ACI-Instanz aus einem Windows- oder Linux-Container. Man kann gegebenenfalls auch mehrere Container in Form einer ACI Container Group betreiben. Alle Container der Gruppe laufen auf einem gemeinsamen Host in einem gemeinsamen LAN und können nur gemeinsam gestartet und gestoppt werden.
  • CPU-Anzahl und verfügbaren Speicher kann man sich beim Starten der ACI-Instanz wünschen. Regionsspezifische Obergrenzen für CPU-Anzahl und Speichergröße müssen dabei beachtet werden.
  • ACI-Instanzen können mit einer öffentlichen IP-Adresse und einem DNS-Namen versehen werden, wenn sie über das Internet erreichbar sein sollen. Das muss aber nicht der Fall sein. Wenn der Container einfach nur einen Hintergrundjob erledigen soll und dafür kein UI vorgesehen ist, kann die Erreichbarkeit über das Internet auch weggelassen werden.
  • Jede ACI-Instanz läuft intern in einer eigenen VM und ist daher auch durch die von Virtualisierung gewohnten Mechanismen abgeschottet.
  • Container in ACI sind stateless. Man kann jedoch durch Volume Mounting Daten in die Container bringen. Eine Möglichkeit in diesem Zusammenhang ist das Mouting von Azure Files. Schreibt ein Container auf ein solches Volume, landen die Daten persistent in Azure Storage und bleiben daher erhalten, auch wenn der Container gestoppt oder gelöscht wird. Mehr Informationen über Volume Mounting findet man in der Dokumentation unter.

ACI statt Kubernetes?

ACI ist kein Ersatz für eine vollwertige Containerautomatisierungslösung wie Kubernetes. Dazu fehlen zu viele Funktionen. ACI ist auch nicht die ideale Plattform, um lange laufende Prozesse wie Webserver oder Datenbankserver zu betreiben. Dafür gibt es in Azure andere PaaS- und Serverless-Dienste, die mehr Funktionalität zu niedrigeren Preisen bieten. ACI ist aus meiner Sicht primär für zwei Anwendungsfälle eine spannende Plattform:

  • Man kann mehr oder weniger kurzlebige Prozesse (z. B. Datenimport oder -export, Reportgenerierung, Sandbox zum Ausführen eines kundenspezifischen Skripts etc.) in ACI auslagern und dadurch die restliche Infrastruktur entlasten.
  • Man verwendet ACI nicht direkt, sondern als Erweiterung einer größeren Lösung zum Abdecken schwankender Systemlast. Ein Beispiel dafür ist das Kubernetes Virtual Kubelet with ACI. Es fügt ein virtuelles Kubelet zu Kubernetes hinzu, mit dem Pods nicht auf Kubernetes-Knoten sondern in ACI ausgeführt werden können. Der Kubernetes-Cluster kann dadurch schlank gehalten werden. Lastspitzen deckt ACI ab und sind daher auch nur bei tatsächlichem Bedarf zu bezahlen.

ACI Codebeispiel

Listing 2 enthält ein Skript, das einen Webserver (nginx) in ACR pusht und daraus anschließend einen Container in ACI hochfährt. Wie schon bei ACR gilt hier, dass Container natürlich auch interaktiv über das Azure Portal gewartet werden können. Ganz im Sinne von DevOps ist Automatisierung mit Skripts aber die zu bevorzugende Variante. In diesem Zusammenhang ein Tipp: Man kann im Azure Portal eine interaktive Cloud Shell anfordern (Abb. 2). Dadurch bekommt man direkt im Browser eine Shell, in der die Azure CLI schon installiert und mit dem eigenen Account verbunden ist.

# Get ACR password
az acr credential show --name azurecaas 	--query "passwords[0].value"

# Push demo webserver to ACR
docker tag nginx:alpine azurecaas.azurecr.io/nginx:alpine
docker push azurecaas.azurecr.io/nginx:alpine

# Create container instance from image in ACR
az container create --resource-group azure-caas-demo \
  --name web-demo --image azurecaas.azurecr.io/nginx:alpine \
  --cpu 1 --memory 1 --ip-address public --ports 80 \
   --registry-password ...

# Get IP address of container instance
az container show --resource-group azure-caas-demo \
  --name web-demo --query ipAddress.ip

# View container logs
az container logs --resource-group azure-caas-demo --name web-demo
Abb. 2: Azure Cloud Shell

Abb. 2: Azure Cloud Shell

Azure App Service

Wer mit Azure schon Erfahrung gesammelt hat, denkt beim Thema Web-Apps und Web-APIs wahrscheinlich zuerst an Azure App Service. App Service gibt es seit einiger Zeit auch für Linux. Als Teil dieses Angebots kann man selbst erstellte Docker Images als Basis für Docker-Container verwenden, in denen der jeweils gewünschte Webserver (z. B. Kestrel mit .NET Core, Node.js, nginx etc.) läuft. Sogar App-Service-Web-Apps mit mehreren Containern (z. B. WordPress mit einer MySQL-Datenbank) kann man in einer Preview-Version schon probieren. Windows-Container werden von App Service im Moment leider noch nicht unterstützt.

Abbildung 3 zeigt beispielhaft, wie eine Azure Web App auf Basis eines Docker-Image aus ACR angelegt wird. Achten Sie insbesondere auf die unterstützten Quellen für Container. Neben ACR werden auch der zuvor schon erwähnte Docker Hub und private Registries unterstützt, die im eigenen Rechenzentrum laufen können.

Abb. 3: ACR-Integration in Azure Web Apps

Abb. 3: ACR-Integration in Azure Web Apps

Azure Functions

App Service alleine ist PaaS, aber noch nicht Serverless. Azure Functions machten daraus erst einen Serverless-Dienst, indem der sogenannte Consumption Plan hinzugefügt wurde. Verwendet man ihn, braucht man weder Größe noch Anzahl an Servern festzulegen. App Service kümmert sich automatisch um die Skalierung. Außerdem bezahlt man im Consumption Plan nicht nach reservierten Ressourcen, sondern nach CPU- und Speicherverbrauch.

Azure Functions gibt es mittlerweile auch für Linux und Docker – sind also Azure Functions + Consumption Plan = Serverless Container? Leider nicht. Diese Kombination wird von Azure aktuell nicht unterstützt. Man kann zwar Azure Functions in Containern laufen lassen (in der Cloud und außerhalb der Cloud), der Consumption Plan von App Service ist damit aber nicht kompatibel. Man benötigt stattdessen einen sogenannten App Service Plan, bei dem man zwar die Server nicht selbst warten, Anzahl und Größe der Server sowie Regeln für automatische Skalierung aber selbst einstellen muss und auch das Bezahlmodell basiert auf reservierten Servern, nicht auf tatsächlicher Nutzung.

Trotzdem, App Service für Linux ist ein toller Service, um Web-Apps, Web-APIs und Serverless Functions in Docker-Containern zu betreiben. Im Moment hat es noch mehr PaaS- als Serverless-Charakter, es spart trotzdem eine Menge Zeit im Vergleich zum Eigenbau eines entsprechenden Containerclusters.

Azure Kubernetes Service (AKS)

Zum Ausführen größerer, komplexerer Containerumgebungen braucht man eine Containerautomatisierungsplattform wie Azure Kubernetes Service (kurz AKS). AKS ist die Open Source Software Kubernetes, allerdings betrieben von Microsoft in Azure. AKS ist ein perfektes Beispiel für PaaS:

  • Das Anlegen eines Kubernetes-Clusters wird mit AKS zum Kinderspiel. Es genügen wenige Klicks im Portal oder eine Zeile Skriptcode mit der Azure CLI. Die einzige kleine Hürde ist die Verbindung von ACR mit AKS. Listing 3zeigt, wie das gemacht wird.
  • Microsoft übernimmt die Wartung des Clusters. Manuelles Einspielen von Patches gehört der Vergangenheit an. Das Upgrade von einer Kubernetes-Version auf die andere kann wie die Installation im Portal oder über ein Skript erledigt werden.
  • AKS ist tief in die Azure-Infrastruktur integriert. Erstellt man beispielsweise einen Load Balancer Service in Kubernetes, weist Azure diesem automatisch eine öffentliche IP-Adresse zu, damit es über das Internet erreichbar wird. Ein weiteres Beispiel für die Integration sind die Treiber für Azure Storage und Azure Files, die in AKS für Kubernetes Persistent Volumes von Haus aus zur Verfügung stehen.

Als Serverless kann man AKS nicht bezeichnen. Durch die oben erwähnte Kombination mit ACI geht die Plattform aber in diese Richtung. Man wird sehen, welche Serverless-Funktionen Microsoft in Zukunft noch in AKS integrieren wird.

# Register AKS provider for Azure CLI
az provider register -n Microsoft.ContainerService

# Create service principal for AKS that it can use to access ACR
az ad sp create-for-rbac --name azurecaas --password ...

# Get ID of ACR. We need this ID in subsequent CLR commands.
az acr show --name azurecaas --resource-group azure-caas-demo --query "id"

# Assign "reader" role in ACR to AKS service principal
az role assignment create --assignee ...(app id) --role Reader \
  --scope ...(ACR id)

# Create AKS cluster
az aks create --resource-group azure-caas-demo \
  --name azure-caas-kube --node-count 3 --generate-ssh-keys \
  --location westeurope --client-secret ... \
  --service-principal ...(app id)

Fazit

Die Installation und der Betrieb von nichttrivialen Docker-Umgebungen ist eine Herausforderung. Man braucht eine Menge Erfahrung und Wissen, um diese Aufgabe professionell und effizient erledigen zu können. In der Regel können und wollen sich nur sehr große Organisationen das entsprechende Wissen in Form spezialisierter Teams leisten. Die Docker Containertechnologie ist aber für jede Organisation ein Gewinn. Gemanagte Umgebungen in öffentlichen Cloud-Computing-Umgebungen wie Azure sind für kleine und mittelgroße Teams eine attraktive Lösung. Sie können sich auf die Entwicklung konzentrieren und überlassen die Betriebsdetails Firmen wie Microsoft.

Azure gehört zu den führenden Anbietern von PaaS-Diensten für Docker Container. App Service, Service Fabric und gemanagtes Kubernetes sind nur drei Beispiele dafür. Serverless würde die Betriebsebene noch weiter abstrahieren als PaaS. Erste Schritte in diese Richtung geht Microsoft mit ACR und ACI. Damit ist das Ende aber noch lange nicht erreicht. Microsofts Strategie geht konsequent in Richtung Serverless und vermutlich werden wir in Zukunft mehr und mehr Ergebnisse daraus auch in den Azure-Containerdiensten sehen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -