Ausführen von Containern in Azure Container Instances (ACI) direkt über die Docker CLI

Vor einigen Monaten haben sowohl Microsoft als auch Docker eine nahtlose Integration von Azure Container Instances (ACI) und Docker CLI angekündigt. Als Container-Enthusiast musste ich mich natürlich mit dieser Integration befassen. Ich habe es in verschiedenen Szenarien getestet, um zu sehen, wie es mich unterstützen und meine Produktivität steigern könnte.

In diesem Artikel:

TL;DR: Die Integration von ACI und Docker CLI ist ausgezeichnet. Sobald ich es konfiguriert hatte, konnte ich erfolgreich zahlreiche Container erstellen. Die Unterstützung umfasst auch Multi-Container-Anwendungen, die auf Docker Compose basieren. Es gibt aber einen Nachteil: Das Abrufen von Images aus Container-Registries war im Vergleich zu meiner lokalen Maschine langsamer. Insgesamt gefällt es mir gut und ich teile in diesem Artikel alles mit Ihnen, was Sie darüber wissen müssen.

Dieser Artikel ist eine deutsche Übersetzung. Den Originalartikel in englischer Sprache finden Sie in Thorsten Hans’ Blog.

Konfigurieren der Integration von Azure Container Instances

				
					# Interaktiven Login Flow starten
docker login azure
				
			

Alternativ können Sie sich mit einem Service Principal (SP) anmelden. Geben Sie die ID und das Kennwort des SP mit den Parametern --client-id und --client-secret an, wenn Sie docker login azure aufrufen.

Sobald Sie eingeloggt sind, erstellen Sie einen neuen Kontext. Der Kontext ist für das Weiterleiten von Anfragen verantwortlich, die von Docker CLI an Knoten oder Cluster ausgegeben werden. In diesem Kontext werden Konfigurationsdaten und vertrauliche Informationen gespeichert, um eine sichere Verbindung mit dem Ziel herzustellen (Azure Container Instances in diesem Fall).

docker context create ist ein interaktiver Befehl. Er führt Sie durch den Prozess der Konfiguration eines neuen Docker-Kontexts.

Im Rahmen dieses Assistenten erstellt Docker CLI in eastus eine neue Azure-Ressourcengruppe und legt eine neue uuid als den Namen fest. Sie können einen benutzerdefinierten Speicherort für die Azure-Ressourcengruppe unter Verwendung des Arguments --location angeben. Den Namen der Azure-Ressourcengruppe können Sie nicht anpassen. Sie können jedoch das Argument --resource-group verwenden und den Kontext mit einem vorhandenen verknüpfen.

				
					# Docker-Kontext erzeugen, um Container-Ausführung an ACI auszulagern
docker context create aci lets-try-aci

# (Optional) Benutzerdefinierte Location angeben und zu existierender Ressourcengruppe verlinken
az group create -n rg-lets-try-aci -l westeurope

docker context create aci lets-try-aci \
  --resource-group rg-lets-try-aci \
  --location westeurope
				
			

Alle konfigurierten Kontexte fragen Sie mit docker context ls ab. Um in einen bestimmten Kontext zu wechseln oder ihn zu verwenden, nutzen Sie den Befehl docker context use und übermitteln Sie den Namen des gewünschten Kontexts:

				
					# Zum Kontext lets-try-aci wechseln
docker context use lets-try-aci
				
			

Werfen Sie gerne einen Blick in die offizielle Docker-Dokumentation, um mehr über Kontexte in Docker zu erfahren.

Ausführen von Einzelcontaineranwendungen in ACI

Sie können zu diesem Zeitpunkt jeden Container in ACI ausführen. Erstellen wir zum Beispiel eine kleine Webanwendung, die einige Kontextinformationen zum Ausführungshost zurückgibt.

				
					docker run -d -p 80:80 nginxdemos/hello
# [+] Running 2/2
# ⠿ Group busy-zhukovsky    Created    3.4s
# ⠿ busy-zhukovsky          Done      25.7s
# busy-zhukovsky
				
			

Es dauerte ungefähr 30 Sekunden, um diesen Container hochzufahren. Denken Sie jedoch daran, was hinter den Kulissen passiert. Docker stellt eine sichere Verbindung her, wie im Docker-Kontext angegeben. Es weist die ARM-API von Azure an, eine Containergruppe zu erstellen. Es bezieht das gewünschte Container-Image und weist eine öffentliche IP-Adresse zu. Am Ende startet es den Container mit der angegebenen Portweiterleitung.

Stellen Sie nun sicher, dass der Container ausgeführt wird (docker ls), und browsen Sie die Anwendung mit einer öffentlichen IP-Adresse.

Sie können den Container wieder löschen, indem Sie docker rm, gefolgt von der ID des Containers, verwenden.

Port Mapping wird nicht unterstützt

Wir haben Port 80 des Docker-Containers auf Port 80 der öffentlichen IP-Adresse (von Azure selbst akquiriert) veröffentlicht. Das Veröffentlichen eines Containers funktioniert sehr gut. Port Mapping (Ändern der Portnummer während der Offenlegung) wird jedoch nicht unterstützt.

Datenträger

Echte Anwendungen müssen ihren Zustand persistieren. Sie sollten den Zustand immer außerhalb des Container-Dateisystems speichern. Bei der Arbeit mit ACI können Sie Azure Files (Teil von Azure Storage Accounts) als Datenträger verwenden. Sie können einen neue Azure File Share in Kombination mit dem erforderlichen Azure Storage Account erstellen, indem Sie docker volume create verwenden.

				
					# Neues Azure File Share (aci-test-volume) erzeugen
# und notwendigen Azure Storage Account (acidockerstorage)
docker volume create aci-test-volume --storage-account acidockerstorage
				
			

Wenn der Datenträger erstellt ist, können wir zustandsbehaftete Anwendungen in ACI ausführen, wie im nächsten Abschnitt gezeigt wird.

Multi-Container-Anwendungen in ACI mit Docker Compose ausführen

Viele Teams verwenden Docker Compose für den Inner-Loop. Mit Docker Compose können Sie Multi-Container-Anwendungen mit Inter-Container-Kommunikation schnell starten.

Sie führen Multi-Container-Anwendungen mit Docker Compose auch in ACI aus. Docker Compose verwendet den Docker-Kontext wieder. Alles, was Sie brauchen, ist eine docker-compose.yml, die eine Multi-Container-Anwendung beschreibt. Als Beispiel werden wir WordPress in ACI ausführen. Diese Konfiguration von WordPress verwendet MySQL, um den Zustand zu persistieren. Verwenden Sie den im vorherigen Abschnitt erstellten Datenträger, um den Zustand in Azure File Share auszulagern.

				
					version: '3.3'

services:
   db:
     image: mysql:5.7
     volumes:
       - data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: somewordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "80:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress
volumes:
  data:
    driver: azure_file
    driver_opts:
      share_name: aci-test-volume
      storage_account_name: acidockerstorage
				
			

Führen Sie docker compose up aus (beachten Sie den Docker CLI-Unterbefehl zum Starten einer Compose-Datei -> kein Bindestrich zwischen docker und compose).

Jetzt ist die richtige Zeit für einen Kaffee oder Tee gekommen. Das Starten beider Container hat bei mir etwa 2 Minuten gedauert …

… sind Sie mit heißem Kaffee oder Tee zurück? Super! Prüfen Sie, ob die Container laufen (docker ps). Greifen Sie mit Ihrem Browser auf die öffentliche IP zu und überprüfen Sie, ob Ihre WordPress-Instanz auf Sie wartet.

Wenn Sie mit dem Bloggen fertig sind, können Sie beide Container mit docker compose down und den darunterliegenden Datenträger mit docker volume rm acidockerstorage/aci-test-volume löschen.

Benutzerdefinierter DNS-Name

Wenn Sie Anwendungen mit mehreren Containern in ACI ausführen, können Sie einen benutzerdefinierten DNS-Namen anfordern. Genauer gesagt weisen Sie Azure an, eine Unterdomäne von azurecontainer.io mit der öffentlichen IP-Adresse des verfügbar gemachten Containers zu verknüpfen. Der FQDN folgt immer dem Schema yourdomain.region.azurecontainer.io.

Das Hinzufügen der Eigenschaft domainname zum Container wordpress in der Datei docker-compose.yml und Zuweisen von letstryaci als Wert führt zu letstryaci.westeurope.azurecontainer.io.

Hinweis: Sie können pro docker-compose.yml nur eine Domäne zuweisen.

Kosten überwachen

ACI ist günstig, wenn kurzlebige Container ausgeführt werden. Dafür ist es ausgelegt. Allerdings ist das Ausführen von Containern rund um die Uhr auf ACI – verglichen mit anderen Hosting-Funktionen in Azure – etwas zu teuer. Vergessen Sie nicht, die Prognose für Ihre monatlichen Azure-Kosten zu verfolgen.

Aufräumen

Vergessen Sie nicht, zum Standard-Docker-Kontext zurückzukehren. Andernfalls leiten alle Operationen (wie docker ps oder docker run) Anfragen an ACI weiter. Wenn Sie den in diesem Artikel erstellten Docker-Kontext entfernen möchten, verwenden Sie den Befehl docker context rm lets-try-aci, nachdem Sie zum Standardkontext zurückgeschaltet haben:

				
					# Zum Default-Kontext zurück wechseln
docker context use default

# Den lets-try-aci Kontext löschen
docker context rm lets-try-aci
				
			

Überprüfen Sie Ihr Azure-Abonnement, nachdem Sie einen ACI-Kontext entfernt haben. Docker CLI löscht keine laufenden Containerinstanzen. Das war zumindest meine Erfahrung.Überprüfen Sie Ihr Azure-Abonnement, nachdem Sie einen ACI-Kontext entfernt haben. Docker CLI löscht keine laufenden Containerinstanzen. Das war zumindest meine Erfahrung.

Schlussfolgerung

Ich verwende ACI regelmäßig und mag das Erlebnis. Es ist gut, neben Azure Kubernetes Service (AKS) einen einfachen (sprich: serverlosen) Ansatz zu haben. Beachten Sie jedoch, dass das Beziehen des Container-Images zu ACI einige Zeit in Anspruch nehmen kann. Das heißt, es eignet sich hervorragend für Jobs und Aufgaben, bei denen die Bootstrap-Dauer nicht kritisch ist.

Die nahtlose Integration mit Docker CLI ist ein großer Vorteil und wird die Einführung von ACI vorantreiben.

Auf der Ignite 2021 hat Microsoft zudem einen weiteren Azure-Dienst für Serverless Containers, Azure Container Apps, vorgestellt. Erste Infos zur Preview findet man bei Microsoft Docs. Dort finden Sie auch einen Vergleich der Optionen für Container-Anwendungen in Azure.

Wenn Sie keine weiteren Artikel unserer Experten verpassen möchten, melden Sie sich zu unserem kostenlosen monatlichen Newsletter an.

Mehr Artikel zu Cloud Native, Azure, Docker
Kostenloser
Newsletter

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Newsletter Anmeldung
Diese Artikel könnten Sie interessieren
Cloud Native
favicon

Cloud Security: The 4C’s Of Cloud-Native Security – Part 5

In the last part of the article series on the 4C's of cloud-native security, we will look at securing the cloud environment itself. Although actual steps to harden your cloud infrastructure differ based on the cloud vendor and the services used to architecture your cloud-native application, many concepts and methodologies are quite similar.
14.04.2022
Cloud Native
favicon

Code Security: The 4C’s Of Cloud-Native Security – Part 4

In this part of the article series on the 4C's of cloud-native security, we will take a closer look at code security. We will briefly inspect why code security is essential, why it should be addressed from the beginning, and why trends such as shift-left security are important aspects of overall security considerations.
18.03.2022
Cloud Native
favicon

Cluster Security: The 4C’s Of Cloud-Native Security – Part 3

Securing the Kubernetes cluster (which may act as a runtime platform for several components of typical cloud-native applications) addresses one of the 4C's in cloud-native security. If you haven't heard about the 4C's of cloud-native security yet or want a quick refresher, you should read my corresponding introduction article.
04.03.2022
Cloud Native
favicon

Container Security: The 4C’s Of Cloud-Native Security – Part 2

Securing the container images of your cloud-native application building blocks addresses one of the 4C's in cloud-native security. If you haven't heard about the 4C's of cloud-native security yet or want a quick refresher, you should read my corresponding introduction post.
24.02.2022
Cloud Native
favicon

Code, Container, Cluster, Cloud: The 4C’s Of Cloud-Native Security – Part 1

Containers and cloud-native design patterns gained popularity over the past years. More and more organizations use containers in production and adopt cloud-native practices and methodologies to get even more value from existing containerized applications and underlying technologies such as container orchestrators like Kubernetes.
15.02.2022
Infrastructure as Code
favicon

Infrastructure-as-Code (IaC): Bicep und Terraform im Vergleich

Infrastructure as Code (IaC) ist eine wichtige Technik in der Automatisierung. Teams beginnen ihren Weg zu Cloud-Native oft so, dass sie alles automatisieren und die Infrastruktur ist hier keine Ausnahme. Die stetig wachsende Akzeptanz von Cloud-Diensten und die Digitalisierung sind nur einige Gründe, warum IaC-Tools wie Terraform so beliebt sind. Project Bicep ist hier ganz neu - eine neue Sprache, die erstellt wurde, um Azure Infrastruktur-Deployments als Code auszudrücken
09.09.2021