Beheben von häufigen Problemen in Azure Container Instances

Artikel
10/15/2024

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.

`Scope`	Länge	Schreibweise	Gültige Zeichen	Vorgeschlagenes Muster	Beispiel
Containername¹	1 - 63	Kleinbuchstaben	Alphanumerisch und Bindestrich (beliebig), außer das erste oder letzte Zeichen	`<name>-<role>-container<number>`	`web-batch-container1`
Containerports	Zwischen 1 und 65535	Integer	Eine ganze Zahl zwischen 1 und 65535	`<port-number>`	`443`
DNS-Namensbezeichnung	5–63	Groß-/Kleinschreibung nicht beachten	Alphanumerisch und Bindestrich (beliebig), außer das erste oder letzte Zeichen	`<name>`	`frontend-site1`
Umgebungsvariable	1 - 63	Groß-/Kleinschreibung nicht beachten	Alphanumerisch und Unterstrich (beliebig), außer das erste oder letzte Zeichen	`<name>`	`MY_VARIABLE`
Volumename	5–63	Kleinbuchstaben	Alphanumerisch und Bindestriche an beliebiger Stelle, außer als erstes oder letztes Zeichen. Zwei aufeinanderfolgende Bindestriche sind nicht erlaubt.	`<name>`	`batch-output-volume`

¹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.

Pullvorgang für Image nicht möglich

Wenn Azure Container Instances den anfänglichen Pullvorgang für Ihr Image nicht durchführen kann, werden eine Zeit lang erneute Versuche gestartet. Wenn während des Pullvorgangs für das Image weiterhin ein Fehler auftritt, tritt auch während der Bereitstellung in ACI schließlich ein Fehler auf, und Sie sehen möglicherweise einen Failed to pull image-Fehler.

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"
  }
],

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.
Führen Sie die Bereitstellung zu einem späteren Zeitpunkt durch.

Probleme während der Laufzeit von Containergruppen

Isolierter Neustart ohne explizite Benutzereingabe für Container ausgeführt

Es gibt zwei allgemeine Kategorien, weshalb eine Containergruppe ohne explizite Benutzereingabe neu gestartet werden kann. Der Containerneustart kann durch den Absturz eines Anwendungsprozesses ausgelöst 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. Der Containerneustart kann aufgrund von Wartungsereignissen 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 fortlaufend beendet und neu gestartet (kein Vorgang mit langer Ausführungsdauer)

Bei Containergruppen ist standardmäßig eine Neustartrichtlinie mit der Einstellung Immer festgelegt, sodass Container in der Containergruppe immer neu gestartet werden, nachdem sie bis zum Abschluss ausgeführt wurden. 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.

Bei der Ausführung von Containergruppen ohne Prozesse mit langer Ausführungsdauer werden Images möglicherweise wiederholt beendet und neu gestartet, wie etwa bei Ubuntu oder Alpine. 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
...
}

Hinweis

Von den meisten Containerimages für Linux-Distributionen wird eine Shell, z.B. Bash, als Standardbefehl festgelegt. Da eine Shell allein kein Dienst mit langer Ausführungsdauer ist, werden diese Container sofort beendet und landen in einer Neustartschleife, wenn sie mit der Standardneustartrichtlinie Always konfiguriert wurden.

Start des Containers dauert sehr lange

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

Imagegröße
Imagespeicherort
Zwischengespeicherte Images

Für Windows-Images gelten noch weitere Aspekte.

Imagegröße

Wenn das Starten Ihres Containers sehr lange dauert, aber nach einiger Zeit erfolgreich ist, sollten Sie sich zuerst die Größe des Containerimage ansehen. Da Azure Container Instances den Pullvorgang für Ihr Containerimage nach Bedarf durchführt, ist die Startdauer direkt von der Größe abhängig.

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. Lesen Sie zur Anleitung Bewährte Methoden für Imagetags der Containerregistrierung. Verwenden Sie die API List Cached Images (Zwischengespeicherte Images auflisten), um eine aktuelle Liste der zwischengespeicherten Images und Tags zu erhalten.

Hinweis

Die Verwendung von auf Windows Server 2019 basierenden Images in Azure Container Instances befindet sich im Vorschaustadium.

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 erstmaligen Einrichtung sollten Containernetzwerke ordnungsgemäß fortgesetzt werden.

Verbinden mit zugrundeliegender Docker-API zum Ausführen privilegierte Container nicht möglich

Azure Container Instances bietet keinen direkten Zugriff auf die zugrundeliegende Infrastruktur, die Containergruppen hostet. Dies umfasst den Zugriff auf die Containerlaufzeit, die Orchestrierungstechnologie und die Ausführung privilegierter Containervorgänge ein. 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 die IP-Adresse einer Containergruppe unerwartet nicht erreichbar ist, vergewissern Sie sich, dass Sie das Containerimage so konfiguriert haben, dass es an den Ports lauscht, die Sie in der Containergruppe mithilfe der 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. Führen Sie außerdem die App aci-helloworld aus, sodass sie an dem Port lauscht. aci-helloworld akzeptiert die optionale Umgebungsvariable PORT, um den Standardport 80 zu überschreiben, an dem gelauscht wird. Wenn Sie z.B. Port 9000 testen möchten, legen Sie die Umgebungsvariable beim Erstellen der Containergruppe fest:

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'
```
Suchen Sie die IP-Adresse der Containergruppe in der Befehlsausgabe von az container create. Suchen Sie den Wert von ip.
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.
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 Bereitstellungen 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 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.

Nächste Schritte

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

Freigeben über