Azure Container Instances
Starten Sie mit ACI ohne Serververwaltung in Sekunden eine containerisierte Anwendung, konfigurieren Sie Umgebungsvariablen und Volume-Einbindungen und verstehen Sie die Abrechnung von ACI.
Azure Container Instances ist eine kostenlose Azure Fundamentals-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Azure Fundamentals-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Azure Fundamentals-Kurs umfasst insgesamt 4 Lektionen.
Was sind Azure Container Instances?
Azure Container Instances (ACI) ermöglichen es, containerisierte Workloads in Azure auszuführen, ohne Server oder Orchestratoren verwalten zu müssen. Sie stellen ein Container-Image bereit, und Azure führt es innerhalb weniger Sekunden auf gemeinsam genutzter Infrastruktur mit mehreren Mandanten aus. ACI eignet sich ideal für kurzlebige Aufgaben, Batchaufträge, Build-Agents und ereignisgesteuerte Workloads, bei denen der Betrieb eines vollständigen Kubernetes-Clusters einen unverhältnismäßig hohen Aufwand bedeuten würde.
Eine Container Instance erstellen
Starten Sie einen ACI-Container mit einem einzigen Befehl: az container create. Geben Sie Image, Ressourcengruppe, CPU und Arbeitsspeicher an. ACI ruft das Image ab, weist Ressourcen zu und startet den Container – in der Regel innerhalb von 5–10 Sekunden. Jede Container Instance erhält einen eindeutigen vollqualifizierten Domänennamen (FQDN), wenn Sie ein DNS-Namenslabel zuweisen, und ist dadurch sofort aus dem Internet erreichbar.
# Run an Nginx container accessible from the internet
az container create \
--name my-nginx \
--resource-group MyRG \
--image nginx:latest \
--cpu 1 \
--memory 1 \
--dns-name-label my-nginx-demo \
--ports 80
# Access at: http://my-nginx-demo.<region>.azurecontainer.ioUmgebungsvariablen und sichere Werte
Übergeben Sie Konfigurationsdaten an ACI-Container mithilfe von Umgebungsvariablen, die beim Erstellen angegeben werden. Verwenden Sie für vertrauliche Werte wie API-Schlüssel oder Kennwörter sichere Umgebungsvariablen. Diese werden nach der Bereitstellung weder im Azure-Portal noch in der CLI-Ausgabe angezeigt, wodurch eine versehentliche Offenlegung in Protokollen oder Prüfpfaden verhindert wird. Sichere Werte sind zur Laufzeit innerhalb des Containers weiterhin als normale Umgebungsvariablen verfügbar.
# Pass regular and secure environment variables
az container create \
--name my-app \
--resource-group MyRG \
--image mycontainerregistry.azurecr.io/myapp:v1.0 \
--environment-variables APP_ENV=production \
--secure-environment-variables \
DATABASE_PASSWORD='super-secret-password' \
API_KEY='my-api-key'
# View logs from the running container
az container logs --name my-app --resource-group MyRGAbrechnung und Ressourcenzuweisung bei ACI
ACI wird sekundenweise auf Grundlage der zugewiesenen CPU-Kerne und GB Arbeitsspeicher abgerechnet. Es gibt keinen Mindestabrechnungszeitraum. Sie zahlen nur, solange der Container ausgeführt wird – sobald er beendet wird, endet auch die Abrechnung. Dadurch ist ACI für kurzlebige Workloads äußerst kostengünstig. Sie können pro Containergruppe zwischen 0,1 und 4 CPU-Kerne sowie zwischen 0,1 und 16 GB Arbeitsspeicher in unterstützten Kombinationen zuweisen.
# Small: 0.5 CPU, 0.5 GB memory
az container create --name small-task --resource-group MyRG \
--image my-batch-image:latest --cpu 0.5 --memory 0.5 \
--restart-policy Never # Don't restart after completion
# Large: 4 CPU, 16 GB memory for intensive tasks
az container create --name ml-inference --resource-group MyRG \
--image ml-model:latest --cpu 4 --memory 16Neustartrichtlinien
ACI unterstützt drei Neustartrichtlinien, die das Verhalten eines Containers nach seinem Beenden steuern. Always (Standard) startet den Container bei jedem Beenden neu – geeignet für langlebige Dienste. Never führt den Container einmal aus und belässt ihn anschließend im beendeten Zustand – ideal für Batchaufträge. OnFailure startet den Container nur neu, wenn er mit einem Exitcode ungleich null beendet wird – nützlich für Muster mit Wiederholung bei Fehlern.
# Batch job: run once, never restart
az container create \
--name data-processor \
--resource-group MyRG \
--image my-batch-image:latest \
--restart-policy Never \
--environment-variables BATCH_DATE=2025-01-01
# Check the container's final state
az container show \
--name data-processor \
--resource-group MyRG \
--query '{state:instanceView.state, exitCode:instanceView.currentState.exitCode}'Containergruppen: Bereitstellungen mit mehreren Containern
Eine Containergruppe ist eine Sammlung von Containern, die einen gemeinsamen Lebenszyklus, ein gemeinsames Netzwerk und gemeinsamen Speicher haben – ähnlich wie ein Kubernetes-Pod. Container in derselben Gruppe teilen sich eine lokale IP-Adresse und einen Port-Namensraum und können dadurch über localhost miteinander kommunizieren. Ein häufig verwendetes Muster ist ein Hauptanwendungscontainer zusammen mit einem Sidecar-Container (z. B. einem Logging-Agent oder Proxy) in derselben Gruppe, definiert über eine YAML- oder ARM-Vorlage.
# multi-container.yaml
apiVersion: '2021-09-01'
location: eastus
name: my-container-group
properties:
containers:
- name: app
properties:
image: myapp:v1.0
ports: [{port: 80}]
resources: {requests: {cpu: 1, memoryInGb: 1}}
- name: log-forwarder
properties:
image: fluent-bit:latest
resources: {requests: {cpu: 0.5, memoryInGb: 0.5}}
osType: Linux
restartPolicy: Always
type: Microsoft.ContainerInstance/containerGroups
# Deploy from YAML
# az container create --resource-group MyRG --file multi-container.yamlVolume-Bereitstellungen: Integration von Azure Files
ACI-Container sind standardmäßig zustandslos – Daten, die in das Dateisystem des Containers geschrieben werden, gehen beim Neustart des Containers verloren. Hängen Sie eine Azure Files-Freigabe als Volume ein, um Daten über Neustarts hinweg dauerhaft zu speichern oder Daten zwischen Containern derselben Gruppe gemeinsam zu nutzen. Geben Sie beim Erstellen der Container Instance den Namen und Schlüssel des Speicherkontos sowie den Namen der Dateifreigabe an.
# Mount an Azure Files share for persistent storage
az container create \
--name stateful-app \
--resource-group MyRG \
--image myapp:v1.0 \
--azure-file-volume-account-name mystorageaccount \
--azure-file-volume-account-key '<storage-account-key>' \
--azure-file-volume-share-name myfileshare \
--azure-file-volume-mount-path /data
# Data written to /data persists in the Azure Files shareGPU Container Instances
ACI unterstützt GPU-Containerinstanzen (K80, V100) für Workloads zur ML-Inferenz, Videoverarbeitung und wissenschaftlichen Berechnung. GPU-Instanzen sind in ausgewählten Regionen verfügbar und erfordern Linux-Container. Sie werden pro GPU und Sekunde abgerechnet und sind daher für Szenarien mit anfallenden Inferenzspitzen wirtschaftlich: Sie starten einen GPU-Container, führen das Modell aus und beenden ihn anschließend sofort. Das ist wesentlich günstiger als eine dedizierte GPU-VM, die rund um die Uhr läuft.
# Create a GPU-enabled container instance
az container create \
--name gpu-inference \
--resource-group MyRG \
--image my-ml-model:latest \
--gpu-count 1 \
--gpu-sku V100 \
--cpu 4 \
--memory 16 \
--os-type LinuxACI mit einem virtuellen Netzwerk
Stellen Sie ACI-Containergruppen in einem dedizierten Subnetz innerhalb eines VNet bereit, um ihnen private IP-Adressen zu geben und den Zugriff auf andere mit dem VNet verbundene Ressourcen (Datenbanken, VMs) zu ermöglichen, ohne diese dem Internet auszusetzen. VNet-integriertes ACI erfordert ein dediziertes, delegiertes Subnetz (delegiert an Microsoft.ContainerInstance/containerGroups) und unterstützt keine Zuweisung öffentlicher IP-Adressen.
# Create an ACI container in a VNet
az container create \
--name private-task \
--resource-group MyRG \
--image myapp:v1.0 \
--vnet MyVNet \
--subnet ContainerSubnet \
--restart-policy Never
# The container gets a private IP from the subnet CIDR
# It can reach VNet resources (SQL, Redis, VMs) on private IPsACI als virtueller Kubelet-Node
ACI lässt sich über das Open-Source-Projekt Virtual Kubelet als virtueller Node in AKS integrieren. Wenn in einem AKS-Cluster eine Bedarfsspitze auftritt, die die Kapazität seiner VM-Nodes überschreitet, kann Kubernetes Pods auf einem virtuellen ACI-Node einplanen und dadurch echte ACI-Containerinstanzen starten. Dies ermöglicht eine unbegrenzte Skalierung für Bedarfsspitzen, ohne zusätzliche VM-Nodes im Voraus bereitzustellen. Sie zahlen nur während der Bedarfsspitze für die ACI-Compute-Ressourcen.
# Enable virtual nodes on an AKS cluster
az aks enable-addons \
--name myAKSCluster \
--resource-group MyRG \
--addons virtual-node \
--subnet-name VirtualNodeSubnet
# Schedule a burst pod on ACI via node selector
# spec:
# nodeSelector:
# kubernetes.io/role: agent
# beta.kubernetes.io/os: linux
# type: virtual-kubelet
# tolerations:
# - key: virtual-kubelet.io/provider
# operator: ExistsWann Sie ACI, AKS oder App Service verwenden sollten
Wählen Sie ACI für kurzlebige Aufgaben, Batchaufträge, CI-Build-Agents und einzelne Container, bei denen der Kubernetes-Overhead unnötig ist. Wählen Sie AKS für langlebige Microservices mit mehreren Containern, die Diensterkennung, Integritätsprüfungen, fortlaufende Updates und Clusternetzwerke benötigen. Wählen Sie App Service, wenn Sie PaaS-Komfortfunktionen (Bereitstellungsslots, verwaltete Zertifikate, integrierte Authentifizierung) nutzen möchten, ohne das Containernetzwerk selbst verwalten zu müssen.
Schnelltest
Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.
Zusammenfassung der Lektion
In dieser Lektion haben Sie Folgendes gelernt: Azure Container Instances führen Container innerhalb weniger Sekunden ohne Serververwaltung aus und werden pro CPU- und Arbeitsspeichersekunde abgerechnet. Containergruppen ermöglichen es mehreren Containern, Netzwerk und Speicher ähnlich wie ein Kubernetes-Pod gemeinsam zu nutzen, und Neustartrichtlinien (Always, Never, OnFailure) steuern den Lebenszyklus von Containern nach ihrem Beenden. Als Nächstes sehen wir uns Kubernetes-Konzepte für Azure an.
Häufig gestellte Fragen
Ist die Lektion „Azure Container Instances“ kostenlos?
Ja — der vollständige Text von „Azure Container Instances“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Azure Fundamentals-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Azure Fundamentals-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Azure Container Instances“?
Starten Sie mit ACI ohne Serververwaltung in Sekunden eine containerisierte Anwendung, konfigurieren Sie Umgebungsvariablen und Volume-Einbindungen und verstehen Sie die Abrechnung von ACI. Du übst Azure Fundamentals mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Azure Fundamentals zu starten?
Keine Vorkenntnisse erforderlich. Azure Fundamentals auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.
Wie lange dauert die Lektion „Azure Container Instances“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Azure Fundamentals-Lektion Code schreiben und ausführen?
Ja. Jede Azure Fundamentals-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Azure Container Registry
- Azure Container Instances
- Kubernetes-Konzepte für Azure
- Workloads in AKS bereitstellen