Ein einfacher Container braucht Hosting? Azure Container Instances mit einem Image aus deiner Registry bereitstellen

#containers#container-instances#container-registry

Azure Container Instances (ACI) führt Container aus, ohne dass du eine VM oder einen Kubernetes-Cluster verwalten musst. Es eignet sich für kleine eigenständige Workloads, temporäre Dienste oder Batch-Aufgaben. ACR speichert das Image; ACI lädt es herunter und führt es aus. Nach der Bereitstellung darf dein Laptop ausgeschaltet sein: Der Azure-Container läuft weiter.

Dieses Lab startet Nginx aus deiner vorhandenen Basic-Registry acrctcontainersneu in North Europe. Verwende deinen tatsächlichen Registry-Namen, falls er abweicht. ACI stellt eine Containergruppe bereit: einen oder mehrere Container mit gemeinsamer Hostumgebung und Netzwerk. Unsere Gruppe enthält einen Container.

Private ACR → authentifizierter Image-Pull → ACI → öffentlicher HTTP-Endpunkt

Das Image bleibt privat; die Beispiel-Webseite ist öffentlich erreichbar. HTTP dient hier nur der vorübergehenden Demo mit einer Startseite ohne Benutzerdaten oder Anmeldung. Eine echte Anwendung braucht passende TLS- und Zugriffseinstellungen.

Verwende das Azure-Portal, um die Containergruppe zu erstellen, Status und Logs zu prüfen und aufzuräumen. Nur das Vorbereiten und Hochladen des Images erfolgt mit lokalem Docker und der Azure CLI. Du brauchst Berechtigungen zum Erstellen von Containerinstanzen und zum Aktivieren/Lesen der Registry-Administratorzugangsdaten. Die Bereitstellung erstellt kostenpflichtige Azure-Ressourcen.

Ein für ACI geeignetes Image vorbereiten

ACI unterstützt Linux-amd64-Images, nicht arm64. Im vorherigen Trip hast du auf einem Apple-Silicon-Mac möglicherweise ein arm64-Image hochgeladen. Erstelle ein separates Tag v2-amd64. v1 bleibt für deinen bisherigen lokalen Test erhalten.

Führe lokal bei laufendem Docker Folgendes aus und passe den Registry-Namen an:

az login
az account set --subscription "CloudTrips TEST"
ACR_NAME="acrctcontainersneu"
ACR_SERVER=$(az acr show --name "$ACR_NAME" --query loginServer -o tsv)
az acr login --name "$ACR_NAME"

docker pull --platform linux/amd64 nginx:stable-alpine
docker tag nginx:stable-alpine "$ACR_SERVER/cloudtrips/nginx:v2-amd64"
docker push --platform linux/amd64 "$ACR_SERVER/cloudtrips/nginx:v2-amd64"

Sowohl Pull als auch Push verwenden --platform linux/amd64. Ein Tag wie v2-amd64 ist nur ein Name und wandelt kein ARM-Image um. Docker auf Apple Silicon kann mehrere Varianten unter demselben lokalen Namen speichern. Verlasse dich deshalb nicht auf ein einfaches lokales docker image inspect oder das Taggen, um amd64 auszuwählen.

Stoppe bei einem fehlgeschlagenen Befehl. Warte auf den erfolgreichen Push und prüfe anschließend das Image in deiner Registry:

docker buildx imagetools inspect "$ACR_SERVER/cloudtrips/nginx:v2-amd64" \
  --format '{{json .Image}}'

Das JSON muss “architecture”: “amd64” und “os”: “linux” enthalten. Erstelle ACI erst nach dieser erfolgreichen Registry-Prüfung. Bei arm64 wiederhole Pull und Push mit ausdrücklicher Plattformangabe. Erkennt docker push die Option --platform nicht, aktualisiere zuerst Docker Desktop.

Registry-Zugriff für die Portal-Bereitstellung aktivieren

Öffne Container registries → deine Registry → Access keys. Setze Admin user → Enabled und speichere bei Bedarf.

Dieser Portal-Ablauf verwendet die gemeinsamen Administratorzugangsdaten der Registry für den Image-Pull. Deine persönliche Anmeldung mit az acr login authentifiziert nur deinen lokalen Docker-Client. Für die Containergruppe in diesem Lab brauchst du keine verwaltete Identität oder IAM-Rollenzuweisung. Registry-Passwörter dürfen nicht in Screenshots erscheinen.

Lass das Administratorkonto aktiviert, solange du diese Containergruppe verwendest: Spätere Image-Pulls können es benötigen. Deaktiviere es nach dem Löschen der Gruppe wieder, falls es nicht anderweitig verwendet wird.

Containergruppe im Portal erstellen

Suche nach Container instances → Create. Trage unter Basics ein:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-aci-test-neu (neu erstellen oder vorhandene Gruppe verwenden)
Container name: aci-ctnginx-neu
Region: North Europe
SKU: Standard (falls angezeigt)
Image source: Azure Container Registry
Registry: deine vorhandene Registry, zum Beispiel acrctcontainersneu
Image / Repository: cloudtrips/nginx
Image tag: v2-amd64
OS type: Linux
Size: 1 vCPU, 1 GiB memory

Verwende bei Bedarf Change size. Meldet die Registry-Auswahl weiterhin deaktivierten Administratorzugriff, aktualisiere das Formular nach der Aktivierung. Alternativ öffnest du Registry → Repositories → cloudtrips/nginx → v2-amd64 → Run instance. Prüfe dort dieselben Einstellungen.

Wähle unter Networking:

Networking type: Public
DNS name label: für diesen IP-Test leer lassen
Ports: 80
Protocol: TCP

Falls das Formular einen DNS-Namen verlangt, wähle einen eindeutigen Wert wie ctnginx-deineinitialen-neu. Du kannst trotzdem über die öffentliche IP testen. Nginx lauscht auf Port 80; eine Zuordnung 8082:80 gibt es hier nicht.

Lass unter Advanced die Einstellung Restart policy → Always bestehen, Command-Overrides und Umgebungsvariablen leer und füge für dieses Lab keinen Log-Analytics-Workspace hinzu. Always startet einen beendeten Containerprozess neu; zusätzliche Replikate oder automatische Skalierung entstehen dadurch nicht.

Erstellungsformular für Container Instances mit Registry-Image, Linux und Ressourcengröße, ohne Zugangsdaten.

Wähle Review + create, prüfe die Image-Endung cloudtrips/nginx:v2-amd64 und wähle Create. Warte auf die Bereitstellung und öffne Go to resource. Prüfe unter Overview und Containers, dass der Container Running ist und eine öffentliche IP hat.

ACI-Übersicht mit laufendem Container, öffentlicher IP und Image aus der privaten Registry.

Im Browser testen

Kopiere die Public IP address aus Overview der Containerinstanz. Öffne im Browser:

http://<öffentliche-IP>/

Erwartet wird die Nginx-Startseite. Verwende ausdrücklich HTTP; dieses Lab richtet kein HTTPS ein. Hier gibt es keine lokale Zuordnung 8082:80: Der Azure-Endpunkt verwendet direkt Port 80. Falls Nginx noch startet, warte kurz und aktualisiere die Seite.

Diese IP gehört zu Azure, nicht zu localhost auf deinem Computer. Die Antwort zeigt, dass ACI dein Registry-Image heruntergeladen hat und es in Azure ausführt. Nach Stoppen/Starten oder Neuerstellen der Gruppe kann sich die IP ändern.

Browser mit der Nginx-Startseite unter der öffentlichen IP der Containerinstanz.

Logs und Fehler im Portal prüfen

Öffne aci-ctnginx-neu → Containers → nginx → Logs für die Nginx-Ausgabe und Events für Start- und Image-Pull-Meldungen. Aktualisiere die Logs nach dem Aufruf der Webseite, um die Anfrage zu sehen. Scheitert die Bereitstellung, bevor die Ressource verfügbar ist, öffne Resource group → Deployments → fehlgeschlagene Bereitstellung → Operation details.

  • Image nicht erreichbar / unauthorized: Prüfe, dass Admin user und öffentlicher Netzwerkzugriff der Registry aktiviert sind und Repository/Tag existieren. Aktualisiere das Erstellungsformular und wähle die Registry erneut. Blockiert eine fehlgeschlagene Gruppe den Versuch, lösche vorher nur aci-ctnginx-neu.
  • Exec format error / nicht unterstützte Architektur: Prüfe das Registry-Image wie oben. Der Tag-Name allein beweist amd64 nicht.
  • MissingSubscriptionRegistration: Registriere Microsoft.ContainerInstance unter Subscriptions → CloudTrips TEST → Resource providers und warte auf den Abschluss.
  • Kapazitäts- oder Kontingentfehler: Prüfe Region und Ressourcen. Falls eine andere unterstützte Region nötig ist, wähle vor dem nächsten Versuch die entsprechende Region im Erstellungsformular.
  • Browser schlägt fehl: Prüfe Running-Zustand, aktuelle öffentliche IP, Port 80 und http://, nicht HTTPS oder Port 8082.

Abschließen

Lösche aci-ctnginx-neu über Overview → Delete oder die Gruppe rg-cloudtrips-aci-test-neu, falls alle Ressourcen darin nur für dieses Lab bestimmt sind. Deaktiviere anschließend Registry → Access keys → Admin user, wenn kein anderer Workload das Konto benötigt. Falls du nach der vorherigen Anleitung bereits id-ctaci-pull erstellt hast: Dieser Ablauf verwendet die Identität nicht. Entferne ihre Registry-Rollenzuweisung und lösche die Lab-Identität, sobald sie nicht mehr benötigt wird.

Behalte rg-cloudtrips-containers-test-neu mit der Registry für spätere Trips. Das Löschen eines lokalen Docker-Containers beendet den Azure-Workload nicht. Für die Registry fallen weiterhin eigene Kosten an.