Beheben von häufigen Problemen in Azure Container Instances

In diesem Artikel wird veranschaulicht, wie Sie häufige Probleme beim Verwalten oder Bereitstellen von Containern in Azure Container Instances behandeln. Weitere Informationen finden Sie in den häufig gestellten Fragen.

Weitere Unterstützung finden Sie in den verfügbaren Optionen für Hilfe und Support im Azure-Portal.

Probleme bei der Bereitstellung von Containergruppen

Benennungskonventionen

Wenn Sie Ihre Containerspezifikation definieren, erfordern bestimmte Parameter die Einhaltung von Benennungseinschränkungen. Die folgende Tabelle enthält die besonderen Anforderungen für Containergruppeneigenschaften. Weitere Informationen finden Sie unter Benennungskonventionen im Azure Architecture Center und unter Benennungsregeln und -einschränkungen für Azure-Ressourcen.

¹Einschränkung auch für Containergruppennamen, wenn sie nicht unabhängig von Containerinstanzen angegeben werden, z. B. mit Bereitstellungen mit dem Befehl az container create.

Betriebssystemversion des Images wird nicht unterstützt

Wenn Sie ein Image angeben, das von Azure Container Instances nicht unterstützt wird, wird der Fehler OsVersionNotSupported zurückgegeben. Der Fehler ähnelt dem folgenden, wobei {0} der Name des Images ist, das Sie bereitstellen wollten:

{
  "error": {
    "code": "OsVersionNotSupported",
    "message": "The OS version of image '{0}' is not supported."
  }
}

Dieser Fehler tritt am häufigsten bei der Bereitstellung von Windows-Images auf, die auf dem SAC-Release (Semi-Annual Channel, halbjährlicher Kanal) 1709 oder 1803 basieren. Diese werden nicht unterstützt. Informationen zu unterstützten Windows-Images in Azure Container Instances finden Sie in den häufig gestellten Fragen.

Abbild kann nicht abgerufen werden

Wenn Azure Container Instances Ihr Image zunächst nicht abrufen kann, wird der Abruf eine Zeit lang wiederholt versucht. Wenn das Abrufen des Images weiterhin fehlschlägt, schlägt die Bereitstellung in ACI schließlich fehl, und möglicherweise wird ein Failed to pull image-Fehler angezeigt.

Um dieses Problem zu beheben, löschen Sie die Containerinstanz, und wiederholen Sie die Bereitstellung. Stellen Sie sicher, dass das Image in der Registrierung vorhanden ist und Sie den Imagenamen richtig eingegeben haben.

Kann das Image nicht gepullt werden, werden in der Ausgabe von az container show Ereignisse wie die folgenden angezeigt:

"events": [
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "Pulling",
    "type": "Normal"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "Failed to pull image \"mcr.microsoft.com/azuredocs/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
    "name": "Failed",
    "type": "Warning"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:20+00:00",
    "lastTimestamp": "2017-12-21T22:57:16+00:00",
    "message": "Back-off pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

Fehler: Ressource nicht verfügbar

Aufgrund der unterschiedlichen Auslastung regionaler Ressourcen in Azure wird beim Versuch, eine Containerinstanz bereitzustellen, möglicherweise die folgende Fehlermeldung angezeigt:

The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.

Dieser Fehler gibt an, dass aufgrund starker Auslastung in der Region, in der die Bereitstellung durchgeführt werden soll, die für den Container angegebenen Ressourcen zum aktuellen Zeitpunkt nicht zugeordnet werden können. Führen Sie einen oder mehrere der folgenden Schritte aus, um das Problem zu beheben.

• Überprüfen Sie, ob Ihre Einstellungen für die Containerbereitstellung innerhalb der unter Regionale Verfügbarkeit für Azure Container Instances definierten Parameter liegen.
• Geben Sie niedrigere CPU- und Arbeitsspeichereinstellungen für den Container an.
• Führen Sie die Bereitstellung in einer anderen Azure-Region durch.
• Später bereitstellen

Probleme während der Laufzeit von Containergruppen

Der Container wurde ohne explizite Benutzereingabe isoliert neu gestartet.

Es gibt zwei allgemeine Kategorien, weshalb eine Containergruppe ohne explizite Benutzereingabe neu gestartet werden kann. Zunächst können Container aufgrund des Absturzes eines Anwendungsprozesses neu gestartet werden. Der ACI-Dienst empfiehlt die Anwendung von Lösungen für detaillierte Einblicke (z. B. Application Insights SDK, Containergruppenmetriken und Containergruppenprotokollen), um zu ermitteln, weshalb bei der Anwendung Probleme aufgetreten sind. Zweitens kann es bei Kunden aufgrund von Wartungsereignissen zu Neustarts kommen, die von der ACI-Infrastruktur initiiert werden. Für eine höhere Verfügbarkeit Ihrer Anwendung führen Sie mehrere Containergruppen hinter einer Eingangskomponente wie Application Gateway oder Traffic Manager aus.

Container wird ständig beendet und neu gestartet (kein dauerhaft laufender Prozess)

Für Containergruppen gilt standardmäßig die NeustartrichtlinieAlways, sodass Container in einer Containergruppe immer neu gestartet werden, nachdem ihre Ausführung abgeschlossen ist. Wenn Sie taskbasierte Container ausführen möchten, müssen Sie diese Option eventuell in OnFailure oder Never ändern. Wenn Sie OnFailure festlegen und der Container weiterhin neu gestartet wird, liegt unter Umständen ein Problem mit der Anwendung oder dem Skript vor, die bzw. das im Container ausgeführt wird.

Wenn Sie Containergruppen ohne lang laufende Prozesse ausführen, kann es bei Images wie Ubuntu oder Alpine zu wiederholten Beendigungen und Neustarts kommen. Das Herstellen einer Verbindung über EXEC funktioniert nicht, da der Container keinen Prozess aufweist, der diesen aktiv hält. Um dieses Problem zu beheben, schließen Sie einen Startbefehl wie das folgende Beispiel in Ihre Containergruppenbereitstellung ein, damit der Container weiterhin ausgeführt wird.

## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"

## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image mcr.microsoft.com/windows/servercore:ltsc2019
 --command-line "ping -t localhost"

Die Container Instances-API und das Azure-Portal enthalten eine restartCount-Eigenschaft. Die Anzahl von Neustarts für einen Container kann über die Azure-Befehlszeilenschnittstelle mithilfe des Befehls az container show überprüft werden. In der folgenden gekürzten Beispielausgabe sehen Sie die restartCount-Eigenschaft am Ende der Ausgabe.

...
 "events": [
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:06+00:00",
     "lastTimestamp": "2017-11-13T21:20:06+00:00",
     "message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   }
 ],
 "previousState": null,
 "restartCount": 0
...
}

Der Container braucht sehr lange zum Starten

Die folgenden drei Hauptfaktoren tragen zur Dauer des Containerstartvorgangs in Azure Container Instances bei:

• Imagegröße
• Imagespeicherort
• Zwischengespeicherte Bilder

Für Windows-Images gelten noch weitere Aspekte.

Imagegröße

Wenn Ihr Container sehr lange zum Starten braucht, aber schließlich erfolgreich startet, sehen Sie sich zunächst die Größe Ihres Container-Images an. Da Azure Container Instances Ihr Containerimage bei Bedarf abruft, steht die angezeigte Startzeit in direktem Zusammenhang mit seiner Größe.

Sie können die Größe Ihres Containerimages mit dem Befehl docker images in der Docker CLI anzeigen:

docker images

REPOSITORY                                    TAG       IMAGE ID        CREATED          SIZE
mcr.microsoft.com/azuredocs/aci-helloworld    latest    7367f3256b41    15 months ago    67.6MB

Sie können die Imagegrößen klein halten, indem Sie sicherstellen, dass Ihr endgültiges Image keine Elemente enthält, die zur Laufzeit nicht erforderlich sind. Eine Möglichkeit ist die Verwendung von mehrstufigen Builds. Mit mehrstufigen Builds können Sie leicht sicherstellen, dass das endgültige Image nur die Artefakte enthält, die Sie für Ihre Anwendung benötigen – und keinen zusätzlichen Inhalt, der zur Erstellungszeit benötigt wurde.

Imagespeicherort

Eine weitere Möglichkeit, die Auswirkungen des Pullvorgangs für das Image auf die Startdauer Ihres Containers zu reduzieren, ist das Hosten des Containerimages in Azure Container Registry in derselben Region, in der Sie Containerinstanzen bereitstellen möchten. Auf diese Weise wird der Netzwerkpfad verkürzt, den das Containerimage zurücklegen muss, sodass sich die Downloadzeit erheblich reduziert.

Zwischengespeicherte Images

Azure Container Instances verwendet einen Mechanismus für die Zwischenspeicherung, um die Dauer des Containerstartvorgangs für Images basierend auf allgemeinen Windows-Basisimages (u. a. nanoserver:1809, servercore:ltsc2019 und servercore:1809) zu verkürzen. Häufig verwendete Linux-Images wie ubuntu:1604 und alpine:3.6 werden auch zwischengespeichert. Vermeiden Sie sowohl bei Windows- als auch Linux-Images die Verwendung des latest-Tags. Hinweise finden Sie in den Best Practices für Image-Tags von Container Registry. Verwenden Sie die API List Cached Images (Zwischengespeicherte Images auflisten), um eine aktuelle Liste der zwischengespeicherten Images und Tags zu erhalten.

Windows-Container verlangsamen die Netzwerkbereitschaft

Bei der ersten Erstellung verfügen Windows-Container ggf. für bis zu 30 Sekunden (selten noch länger) über keine eingehende oder ausgehende Konnektivität. Wenn Ihre Containeranwendung eine Internetverbindung benötigt, fügen Sie eine Verzögerungs- und Wiederholungslogik hinzu, die 30 Sekunden für den Aufbau der Internetverbindung zulässt. Nach der Ersteinrichtung sollte die Containervernetzung wieder ordnungsgemäß funktionieren.

Es kann keine Verbindung zur zugrunde liegenden Docker-API hergestellt oder privilegierte Container ausgeführt werden.

Azure Container Instances bietet keinen direkten Zugriff auf die zugrundeliegende Infrastruktur, die Containergruppen hostet. Dies umfasst den Zugriff auf die Container-Runtime, die Orchestrierungstechnologie und die Ausführung privilegierter Containervorgänge. Die von ACI unterstützten Vorgänge finden Sie in der REST-Referenzdokumentation. Wenn Sie etwas nicht finden, senden Sie eine Anforderung an die ACI-Feedbackforen.

Auf die IP-Adresse der Containergruppe kann aufgrund von Portkonflikten nicht zugegriffen werden

Azure Container Instances unterstützt noch nicht die Portzuordnung wie bei der regulären Docker-Konfiguration. Wenn Sie feststellen, dass die IP-Adresse einer Containergruppe nicht erreichbar ist, obwohl sie Ihrer Meinung nach erreichbar sein sollte, vergewissern Sie sich, dass Sie Ihr Containerimage so konfiguriert haben, dass es auf denselben Ports lauscht, die Sie in Ihrer Containergruppe über die Eigenschaft ports verfügbar machen.

Wenn Sie überprüfen möchten, ob Azure Container Instances an dem Port lauschen kann, den Sie im Containerimage konfiguriert haben, testen Sie eine Bereitstellung des Images aci-helloworld, das den Port verfügbar macht. Starten Sie außerdem die aci-helloworld-App, sodass sie auf dem Port lauscht. aci-helloworld akzeptiert eine optionale Umgebungsvariable PORT, um den Standardport 80, auf dem es lauscht, außer Kraft zu setzen. Wenn Sie z.B. Port 9000 testen möchten, legen Sie die Umgebungsvariable beim Erstellen der Containergruppe fest:

1. Richten Sie die Containergruppe so ein, dass Port 9000 verfügbar gemacht wird, und übergeben Sie die Portnummer als Wert der Umgebungsvariablen. Das Beispiel ist für die Bash-Shell formatiert. Wenn Sie eine andere Shell, wie PowerShell oder Eingabeaufforderung bevorzugen, müssen Sie die Variablenzuweisung entsprechend anpassen.

   az container create --resource-group myResourceGroup \
   --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
   --ip-address Public --ports 9000 \
   --environment-variables 'PORT'='9000'
   

2. Suchen Sie die IP-Adresse der Containergruppe in der Befehlsausgabe von az container create. Suchen Sie den Wert von ip.

3. Nachdem der Container erfolgreich bereitgestellt wurde, navigieren Sie im Browser zu der IP-Adresse und dem Port der Containeranwendung, z. B. 192.0.2.0:9000.

   In der Web-App sollte die Meldung „Willkommen bei Azure Container Instances“ angezeigt werden.

4. Wenn Sie den Container nicht mehr benötigen, entfernen Sie ihn mithilfe des Befehls az container delete:

   az container delete --resource-group myResourceGroup --name mycontainer
   

Probleme bei der Bereitstellung vertraulicher Containergruppen

Richtlinienfehler bei der Verwendung einer benutzerdefinierten CCE-Richtlinie

Benutzerdefinierte CCE-Richtlinien müssen mit der Confcom-Erweiterung der Azure CLI generiert werden. Stellen Sie vor dem Generieren der Richtlinie sicher, dass alle Eigenschaften, die in Ihrer ARM-Vorlage angegeben sind, gültig sind und Ihren Erwartungen bezüglich der Inhalte, die in einer vertraulichen Computingrichtlinie dargestellt werden sollten, entsprechen. Einige zu überprüfende Eigenschaften sind z. B. das Containerimage, Umgebungsvariablen, Volumeeinbindungen und Containerbefehle.

Fehlender Hashwert in der Richtlinie

Die confcom-Erweiterung der Azure CLI verwendet zwischengespeicherte Images auf Ihrem lokalen Computer, die möglicherweise nicht mit denen übereinstimmen, die remote verfügbar sind, was bei der Überprüfung der Richtlinie zu einem Ebenenkonflikt führen kann. Stellen Sie sicher, dass Sie alle alten Images entfernen und die neuesten Containerimages in Ihre lokale Umgebung pullen. Sobald Sie sicher sind, dass Sie über den neuesten SHA-Hash verfügen, sollten Sie die CCE-Richtlinie neu generieren.

Der Prozess/Container wurde mit dem folgenden Exitcode beendet: 139

Dieser Exitcode tritt aufgrund von Einschränkungen des Basisimages der Ubuntu-Version 22.04 auf. Es wird empfohlen, ein anderes Basisimage zu verwenden, um dieses Problem zu beheben.

Containerausgangscodes

Wenn ein Container in Azure Container Instances beendet wird, meldet die Plattform einen Beendigungscode, der angibt, warum der Prozess beendet wurde. Sie können Exitcodes anzeigen, indem Sie Containerereignisse mithilfe des Befehls "az container show" oder im Azure-Portal unter "Containerereignisse"> überprüfen.

In der folgenden Tabelle werden häufig auftretende Exitcodes beschrieben:

Plattformgesteuerte Beendigungen (Ausgangscodes 7147 und 7148)

Ausgangscodes 7147 und 7148 sind Plattformausgangscodes, die aus der zugrunde liegenden Infrastruktur stammen. Möglicherweise werden diese Codes nicht immer direkt in den Containerdetails angezeigt, aber sie stimmen mit "Killing container (platform initiated)"-Nachrichten überein, die in Containerereignissen angezeigt werden. Häufige Ursachen von plattformgesteuerten Beendigungen sind:

• Infrastrukturwartung: Die Plattform hat Ihren Container als Teil der routinemäßigen Wartung oder des Lastenausgleichs verschoben.
• Ressourceneinschränkungen: Der zugrunde liegende Host, der zum Freigeben von Ressourcen erforderlich ist.
• Aktualisierungen der Plattform: Die Infrastruktur wurde aktualisiert, wodurch Neustarts der Container erforderlich wurden.

Diese Beendigungen werden in einer Cloudumgebung erwartet. Für eine höhere Verfügbarkeit Ihrer Anwendung führen Sie mehrere Containergruppen hinter einer Eingangskomponente wie Application Gateway oder Traffic Manager aus.

Weitere Informationen zu plattforminitiierten Beendigungen finden Sie unter Diagnose allgemeiner Codepaketfehler mithilfe von Service Fabric.

Nächste Schritte

Erfahren Sie, wie Sie Containerprotokolle und -ereignisse abrufen, um Ihre Container zu debuggen.