Felsöka vanliga problem med Azure Container Instances

Artikel
08/29/2024

Den här artikeln visar hur du felsöker vanliga problem med att hantera eller distribuera containrar till Azure Container Instances. Se även Vanliga frågor och svar.

Om du behöver mer support kan du läsa mer i tillgängliga alternativ för hjälp + support i Azure-portalen.

Problem vid distribution av containergrupper

Namngivningskonventioner

När du definierar containerspecifikationen måste vissa parametrar följa namngivningsbegränsningarna. I följande tabell visas de specifika kraven för egenskaper för containergrupper. Mer information finns i Namngivningskonventioner i Azure Architecture Center och namngivningsregler och begränsningar för Azure-resurser.

Omfattning	Längd	Skiftläge	Giltiga tecken	Föreslaget mönster	Exempel
Containernamn¹	1–63	Gemener	Alfanumeriskt och bindestreck var som helst utom det första eller sista tecknet	`<name>-<role>-container<number>`	`web-batch-container1`
Containerportar	Mellan 1 och 65535	Integer	Heltal mellan 1 och 65535	`<port-number>`	`443`
DNS-namnetikett	5-63	Ej skiftlägeskänslig	Alfanumeriskt och bindestreck var som helst utom det första eller sista tecknet	`<name>`	`frontend-site1`
Miljövariabel	1–63	Ej skiftlägeskänslig	Alfanumeriskt och understreck (_) var som helst utom det första eller sista tecknet	`<name>`	`MY_VARIABLE`
Volymnamn	5-63	Gemener	Alfanumeriska och bindestreck var som helst utom det första eller sista tecknet. Får inte innehålla två bindestreck i följd.	`<name>`	`batch-output-volume`

¹Begränsning även för containergruppnamn när de inte anges oberoende av containerinstanser, till exempel med az container create kommandodistributioner.

Os-version av avbildning stöds inte

Om du anger en avbildning som Azure Container Instances inte stöder returneras ett OsVersionNotSupported fel. Felet liknar följande, där {0} är namnet på den avbildning som du försökte distribuera:

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

Det här felet uppstår oftast vid distribution av Windows-avbildningar som baseras på halvårskanalversion 1709 eller 1803, som inte stöds. Information om Windows-avbildningar som stöds i Azure Container Instances finns i Vanliga frågor och svar.

Det går inte att hämta avbildningen

Om Azure Container Instances ursprungligen inte kan hämta avbildningen försöker den igen för tid. Om avbildningshämtningen fortsätter att misslyckas misslyckas ACI slutligen distributionen och du kan se ett Failed to pull image fel.

Lös problemet genom att ta bort containerinstansen och försöka distribuera igen. Kontrollera att avbildningen finns i registret och att du har skrivit avbildningsnamnet korrekt.

Om avbildningen inte kan hämtas visas händelser som följande i utdata från az container show:

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

Resursen är inte tillgänglig

På grund av varierande regional resursbelastning i Azure kan du få följande fel när du försöker distribuera en containerinstans:

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.

Det här felet anger att de resurser som angetts för containern inte kan allokeras vid den tidpunkten på grund av hög belastning i den region där du försöker distribuera. Använd ett eller flera av följande åtgärdssteg för att lösa problemet.

Kontrollera att dina inställningar för containerdistribution ligger inom de parametrar som definierats i Regiontillgänglighet för Azure Container Instances
Ange lägre processor- och minnesinställningar för containern
Distribuera till en annan Azure-region
Distribuera vid ett senare tillfälle

Problem vid körning av containergrupper

Containern hade en isolerad omstart utan explicita användarindata

Det finns två breda kategorier för varför en containergrupp kan startas om utan explicita användarindata. För det första kan containrar uppleva omstarter som orsakas av en programprocesskrasch. ACI-tjänsten rekommenderar att du tillämpar observerbarhetslösningar som Application Insights SDK, containergruppsmått och containergruppsloggar för att avgöra varför programmet upplevde problem. För det andra kan kunder uppleva omstarter som initieras av ACI-infrastrukturen på grund av underhållshändelser. Om du vill öka programmets tillgänglighet kör du flera containergrupper bakom en ingresskomponent, till exempel en Application Gateway eller Traffic Manager.

Containern avslutas och startar om kontinuerligt (ingen tidskrävande process)

Containergrupper har som standard en omstartsprincip för Always, så containrar i containergruppen startar alltid om när de har körts. Du kan behöva ändra detta till OnFailure eller Aldrig om du tänker köra uppgiftsbaserade containrar. Om du anger OnFailure och fortfarande ser kontinuerliga omstarter kan det uppstå ett problem med programmet eller skriptet som körs i containern.

När du kör containergrupper utan tidskrävande processer kan du se upprepade avslut och omstarter med avbildningar som Ubuntu eller Alpine. Anslutning via EXEC fungerar inte eftersom containern inte har någon process som håller den vid liv. Lös problemet genom att ta med ett startkommando som i följande exempel med distributionen av containergruppen för att behålla containern igång.

## 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"

API:et för containerinstanser och Azure-portalen innehåller en restartCount egenskap. Om du vill kontrollera antalet omstarter för en container kan du använda kommandot az container show i Azure CLI. I följande exempelutdata, som vi trunkerade för korthet, ser restartCount du egenskapen i slutet av utdata.

...
 "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
...
}

Kommentar

De flesta containeravbildningar för Linux-distributioner anger ett gränssnitt, till exempel bash, som standardkommando. Eftersom ett gränssnitt på egen hand inte är en tidskrävande tjänst avslutas dessa containrar omedelbart och hamnar i en omstartsloop när de konfigureras med standardprincipen Always restart.

Det tar lång tid att starta containrar

De tre primära faktorerna som bidrar till starttiden för containrar i Azure Container Instances är:

Bildstorlek
Bildplats
Cachelagrade avbildningar

Windows-avbildningar har ytterligare överväganden.

Bildstorlek

Om det tar lång tid att starta containern, men så småningom lyckas, börjar du med att titta på storleken på containeravbildningen. Eftersom Azure Container Instances hämtar containeravbildningen på begäran är starttiden som du ser direkt relaterad till dess storlek.

Du kan visa storleken på containeravbildningen docker images med hjälp av kommandot i Docker CLI:

docker images

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

Nyckeln till att hålla bildstorlekarna små är att se till att den slutliga avbildningen inte innehåller något som inte krävs vid körning. Ett sätt att göra detta är med flerstegsversioner. Flerstegsversioner gör det enkelt att se till att den slutliga avbildningen endast innehåller de artefakter som du behöver för ditt program och inte något av det extra innehåll som krävdes vid bygget.

Bildplats

Ett annat sätt att minska effekten av avbildningshämtningen på containerns starttid är att vara värd för containeravbildningen i Azure Container Registry i samma region där du tänker distribuera containerinstanser. Detta förkortar den nätverkssökväg som containeravbildningen behöver färdas, vilket avsevärt förkortar nedladdningstiden.

Cachelagrade avbildningar

Azure Container Instances använder en cachelagringsmekanism för att påskynda starttiden för containrar för avbildningar som bygger på vanliga Windows-basavbildningar, inklusive nanoserver:1809, servercore:ltsc2019och servercore:1809. Vanliga Linux-avbildningar som ubuntu:1604 och alpine:3.6 cachelagras också. Undvik att använda taggen för både Windows- och Linux-avbildningar latest . Mer information finns i Metodtips för Container Registry-avbildningstaggen. Om du vill ha en uppdaterad lista över cachelagrade bilder och taggar använder du API:et List cachelagrade avbildningar .

Kommentar

Användning av Windows Server 2019-baserade avbildningar i Azure Container Instances är en förhandsversion.

Långsam nätverksberedskap för Windows-containrar

Vid första skapandet kanske Windows-containrar inte har någon inkommande eller utgående anslutning i upp till 30 sekunder (eller längre, i sällsynta fall). Om ditt containerprogram behöver en Internetanslutning lägger du till fördröjnings- och återförsökslogik så att 30 sekunder kan upprätta Internetanslutning. Efter den inledande installationen bör containernätverk återupptas på rätt sätt.

Det går inte att ansluta till underliggande Docker-API eller köra privilegierade containrar

Azure Container Instances exponerar inte direkt åtkomst till den underliggande infrastrukturen som är värd för containergrupper. Detta omfattar åtkomst till containerkörning, orkestreringsteknik och körning av privilegierade containeråtgärder. Om du vill se vilka åtgärder som ACI stöder läser du REST-referensdokumentationen. Om något saknas skickar du en begäran på ACI-feedbackforumen.

Det går inte att komma åt containergruppens IP-adress på grund av felmatchade portar

Azure Container Instances har ännu inte stöd för portmappning som med vanlig Docker-konfiguration. Om du upptäcker att en containergrupps IP-adress inte är tillgänglig när du anser att den borde vara det, se till att du har konfigurerat containeravbildningen så att den lyssnar på samma portar som du exponerar i containergruppen med ports egenskapen .

Om du vill bekräfta att Azure Container Instances kan lyssna på den port som du konfigurerade i containeravbildningen testar du en distribution av avbildningen aci-helloworld som exponerar porten. aci-helloworld Kör även appen så att den lyssnar på porten. aci-helloworld accepterar en valfri miljövariabel PORT för att åsidosätta standardporten 80 som den lyssnar på. Om du till exempel vill testa port 9000 anger du miljövariabeln när du skapar containergruppen:

Konfigurera containergruppen så att port 9000 exponeras och skicka portnumret som värdet för miljövariabeln. Exemplet är formaterat för Bash-gränssnittet. Om du föredrar ett annat gränssnitt, till exempel PowerShell eller Kommandotolken, måste du justera variabeltilldelningen i enlighet med detta.
```
az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'
```
Hitta IP-adressen för containergruppen i kommandoutdata för az container create. Leta efter ip-värdet.
När containern har etablerats bläddrar du till IP-adressen och porten för containerprogrammet i webbläsaren, till exempel: 192.0.2.0:9000.

Du bör se meddelandet "Välkommen till Azure Container Instances!" som visas av webbappen.
När du är klar med containern tar du bort den med kommandot az container delete :
```
az container delete --resource-group myResourceGroup --name mycontainer
```

Problem vid distribution av konfidentiella containergrupper

Principfel vid användning av anpassad CCE-princip

Anpassade CCE-principer måste genereras azure CLI-konfigurationstillägget. Innan du genererar principen kontrollerar du att alla egenskaper som anges i ARM-mallen är giltiga och matchar vad du förväntar dig ska representeras i en princip för konfidentiell databehandling. Vissa egenskaper som ska verifieras är containeravbildningen, miljövariabler, volymmonteringar och containerkommandon.

Hash saknas från principen

Azure CLI-konfigurationstillägget använder cachelagrade avbildningar på den lokala datorn som kanske inte matchar dem som är tillgängliga via fjärranslutning, vilket kan resultera i nivåmatchningsfel när principen verifieras. Se till att du tar bort alla gamla avbildningar och hämtar de senaste containeravbildningarna till din lokala miljö. När du är säker på att du har den senaste SHA:en bör du återskapa CCE-principen.

Process/container avslutad med slutkod: 139

Den här slutkoden inträffar på grund av begränsningar med Ubuntu Version 22.04-basavbildningen. Rekommendationen är att använda en annan basavbildning för att lösa problemet.

Nästa steg

Lär dig hur du hämtar containerloggar och händelser för att felsöka dina containrar.

Dela via