Az Azure Container Instances gyakori hibáinak elhárítása

Cikk
05/24/2023

Ez a cikk bemutatja, hogyan háríthatja el a tárolók Azure Container Instances való kezelésével vagy üzembe helyezésével kapcsolatos gyakori problémákat. Lásd még : Gyakori kérdések.

Ha további támogatásra van szüksége, tekintse meg a Azure Portal elérhető Súgó + támogatási lehetőségek című témakört.

Tárolócsoport üzembe helyezése során felmerülő problémák

Elnevezési konvenciók

A tároló specifikációinak meghatározásakor bizonyos paramétereknek meg kell felelnie az elnevezési korlátozásoknak. Az alábbi táblázat a tárolócsoport tulajdonságaira vonatkozó konkrét követelményeket tartalmazza. További információ: Elnevezési konvenciók az Azure Architecture Centerben és az Azure-erőforrások elnevezési szabályai és korlátozásai.

Hatókör	Hossz	Kis- és nagybetűk	Érvényes karakterek	Javasolt minta	Példa
Tároló neve¹	1–63	Kisbetűs	Alfanumerikus és kötőjel bárhol, kivéve az első vagy az utolsó karaktert	`<name>-<role>-container<number>`	`web-batch-container1`
Tárolóportok	1 és 65535 között	Egész szám	1 és 65535 közötti egész szám	`<port-number>`	`443`
DNS-névcímke	5-63	Kis- és nagybetűk megkülönböztetése nélkül	Alfanumerikus és kötőjel bárhol, kivéve az első vagy az utolsó karaktert	`<name>`	`frontend-site1`
Környezeti változó	1–63	Kis- és nagybetűk megkülönböztetése nélkül	Alfanumerikus és aláhúzásjel (_) bárhol az első vagy az utolsó karakter kivételével	`<name>`	`MY_VARIABLE`
Kötet neve	5-63	Kisbetűs	Alfanumerikus és kötőjelek bárhol, kivéve az első vagy az utolsó karaktert. Nem tartalmazhat két egymást követő kötőjelet.	`<name>`	`batch-output-volume`

¹ Korlátozás a tárolócsoportnevekre is, ha nincsenek megadva a tárolópéldánytól függetlenül, például parancstelepítések esetén az container create .

A rendszerkép operációsrendszer-verziója nem támogatott

Ha olyan képet ad meg, amelyet Azure Container Instances nem támogat, OsVersionNotSupported a rendszer hibát ad vissza. A hiba a következőhöz hasonló, ahol {0} az üzembe helyezni kívánt rendszerkép neve:

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

Ez a hiba leggyakrabban az Semi-Annual Channel 1709-es vagy 1803-es kiadásán alapuló Windows-rendszerképek telepítésekor fordul elő, amelyek nem támogatottak. A Azure Container Instances támogatott Windows-rendszerképeivel kapcsolatban lásd: Gyakori kérdések.

Nem sikerült lekérni a rendszerképet

Ha Azure Container Instances kezdetben nem tudja lekérni a rendszerképet, újrapróbálkozásokat fog végrehajtani. Ha a rendszerkép-lekérési művelet továbbra is sikertelen, az ACI végül meghiúsul az üzembe helyezés során, és hibaüzenet jelenhet meg Failed to pull image .

A probléma megoldásához törölje a tárolópéldányt, és próbálkozzon újra az üzembe helyezéssel. Győződjön meg arról, hogy a rendszerkép létezik a beállításjegyzékben, és hogy helyesen adta-e meg a rendszerkép nevét.

Ha a rendszerképet nem lehet lekéreni, az az container show kimenetében az alábbihoz hasonló események jelennek meg:

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

Az erőforrás nem érhető el hiba

Az Azure különböző regionális erőforrás-terhelése miatt a következő hibaüzenet jelenhet meg egy tárolópéldány üzembe helyezésekor:

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.

Ez a hiba azt jelzi, hogy az üzembe helyezési régióban a nagy terhelés miatt a tárolóhoz megadott erőforrások nem foglalhatók le. A probléma megoldásához kövesse az alábbi megoldási lépéseket.

Ellenőrizze, hogy a tároló üzembehelyezési beállításai a Régió rendelkezésre állása szakaszban meghatározott paraméterek közé tartoznak-e Azure Container Instances
A tároló alacsonyabb processzor- és memóriabeállításainak megadása
Üzembe helyezés egy másik Azure-régióban
Üzembe helyezés későbbi időpontban

Tárolócsoport futtatókörnyezete során felmerülő problémák

A tároló külön újraindítást kapott explicit felhasználói bevitel nélkül

Két átfogó kategória létezik arra vonatkozóan, hogy egy tárolócsoport miért indulhat újra explicit felhasználói bevitel nélkül. Először is előfordulhat, hogy a tárolók újraindulnak egy alkalmazásfolyamat összeomlása miatt. Az ACI szolgáltatás olyan megfigyelhetőségi megoldásokat javasol, mint az Application Insights SDK, a tárolócsoport-metrikák és a tárolócsoport-naplók, hogy megállapítsa , miért tapasztalt problémákat az alkalmazás. Másodszor, az ügyfelek karbantartási események miatt újraindulhatnak az ACI-infrastruktúra által. Az alkalmazás rendelkezésre állásának növelése érdekében futtasson több tárolócsoportot egy bemeneti összetevő, például egy Application Gateway vagy Traffic Manager mögött.

A tároló folyamatosan kilép és újraindul (nem hosszan futó folyamat)

A tárolócsoportok alapértelmezés szerint az Alwaysújraindítási szabályzatát követik, így a tárolócsoportban lévő tárolók mindig újraindulnak, miután a futtatásuk befejeződött. Ha feladatalapú tárolókat szeretne futtatni, előfordulhat, hogy ezt OnFailure vagy Never (Soha) állapotra kell módosítania. Ha az OnFailure értéket adja meg, és továbbra is folyamatos újraindításokat lát, előfordulhat, hogy probléma van a tárolóban végrehajtott alkalmazással vagy szkripttel.

Ha hosszú ideig futó folyamatok nélkül futtat tárolócsoportokat, ismétlődő kilépéseket és újraindításokat láthat olyan rendszerképekkel, mint az Ubuntu vagy az Alpine. Az EXEC-n keresztüli csatlakozás nem fog működni, mivel a tároló nem tartja életben a folyamatot. A probléma megoldásához adjon meg egy indítási parancsot a következőhöz hasonló módon a tárolócsoport üzembe helyezéséhez, hogy a tároló fusson.

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

A Container Instances API és a Azure Portal tartalmaznak egy tulajdonságotrestartCount. A tároló újraindításainak számának ellenőrzéséhez használhatja az az container show parancsot az Azure CLI-ben. Az alábbi példakimenetben (amely rövidség kedvéért csonkolt) a kimenet végén láthatja a restartCount tulajdonságot.

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

Megjegyzés

A Linux-disztribúciók legtöbb tárolólemezképe alapértelmezett parancsként beállít egy rendszerhéjat, például a basht. Mivel a rendszerhéj önmagában nem hosszú ideig futó szolgáltatás, ezek a tárolók azonnal kilépnek, és újraindítási hurokba kerülnek, amikor az alapértelmezett Always restart szabályzattal vannak konfigurálva.

A tároló indítása hosszú időt vesz igénybe

A tároló indítási idejének Azure Container Instances három fő tényezője a következő:

Képméret
Kép helye
Gyorsítótárazott képek

A Windows-rendszerképek további szempontokat is figyelembe veendők.

Képméret

Ha a tároló elindítása hosszú időt vesz igénybe, de végül sikeres lesz, először vizsgálja meg a tárolórendszerkép méretét. Mivel Azure Container Instances igény szerint lekéri a tárolórendszerképet, a megjelenő indítási idő közvetlenül a méretéhez kapcsolódik.

A tárolórendszerkép méretét a docker images Docker parancssori felületének parancsával tekintheti meg:

docker images

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

A képméretek kis méretűek tartásának kulcsa annak biztosítása, hogy a végső lemezkép ne tartalmazzon semmit, amire futásidőben nincs szükség. Ennek egyik módja a többszakaszos buildek. A többfázisú buildek megkönnyítik annak biztosítását, hogy a végső lemezkép csak az alkalmazáshoz szükséges összetevőket tartalmazza, és ne tartalmazza a buildeléskor szükséges további tartalmakat.

Kép helye

A rendszerkép lekérésének a tároló indítási idejére gyakorolt hatását úgy is csökkentheti, ha a tárolólemezképet ugyanabban a régióban üzemelteti Azure Container Registry, ahol tárolópéldányokat kíván üzembe helyezni. Ez lerövidíti a tárolólemezkép által igényelt hálózati útvonalat, jelentősen lerövidítve a letöltési időt.

Gyorsítótárazott képek

Azure Container Instances gyorsítótárazási mechanizmussal felgyorsítja a tároló indítási idejét a windowsos alaprendszerképekre épülő rendszerképek esetében, beleértve a nanoserver:1809, servercore:ltsc2019és servercore:1809rendszert. A gyakran használt Linux-rendszerképek, például ubuntu:1604 a és alpine:3.6 a is gyorsítótárazva vannak. Windows- és Linux-rendszerképek esetén ne használja a címkét latest . Útmutatásért tekintse át a Container Registry rendszerképcímkéjének ajánlott eljárásait . A gyorsítótárazott képek és címkék naprakész listájához használja a Gyorsítótárazott képek listázása API-t.

Megjegyzés

A Windows Server 2019-alapú rendszerképek használata Azure Container Instances előzetes verzióban érhető el.

A Windows-tárolók lassú hálózati készültség

A kezdeti létrehozáskor előfordulhat, hogy a Windows-tárolók legfeljebb 30 másodpercig (ritka esetekben hosszabb ideig) nem rendelkeznek bejövő vagy kimenő kapcsolattal. Ha a tárolóalkalmazásnak internetkapcsolatra van szüksége, adjon hozzá késleltetési és újrapróbálkozási logikát, hogy 30 másodpercig engedélyezhesse az internetkapcsolatot. A kezdeti beállítás után a tárolóhálózatnak megfelelően kell folytatódnia.

Nem lehet csatlakozni a mögöttes Docker API-hoz, és nem futtathatók emelt szintű tárolók

Azure Container Instances nem teszi elérhetővé a tárolócsoportokat üzemeltető mögöttes infrastruktúrához való közvetlen hozzáférést. Ez magában foglalja a tároló-futtatókörnyezethez, a vezénylési technológiához és a kiemelt tárolóműveletek futtatásához való hozzáférést. Az ACI által támogatott műveletek megtekintéséhez tekintse meg a REST referenciadokumentációját. Ha valami hiányzik, küldjön egy kérést az ACI visszajelzési fórumain.

Előfordulhat, hogy a tárolócsoport IP-címe nem érhető el az eltérő portok miatt

Azure Container Instances még nem támogatja a portleképezést, mint a normál Docker-konfigurációval. Ha úgy találja, hogy egy tárolócsoport IP-címe nem érhető el, ha úgy véli, hogy annak lennie kell, győződjön meg arról, hogy konfigurálta a tárolórendszerképet, hogy a tulajdonsággal ports a tárolócsoportban közzétett portokat figyelje.

Ha meg szeretné erősíteni, hogy Azure Container Instances figyelheti a tárolólemezképben konfigurált portot, tesztelje a aci-helloworld portot elérhetővé tevő lemezkép üzembe helyezését. Futtassa az aci-helloworld alkalmazást úgy is, hogy a porton figyeljen. aci-helloworld elfogad egy választható környezeti változót PORT , amely felülbírálja az alapértelmezett 80-s portot, amelyen figyel. A 9000-s port teszteléséhez például állítsa be a környezeti változót a tárolócsoport létrehozásakor:

Állítsa be a tárolócsoportot úgy, hogy elérhetővé tegye a 9000-es portot, és adja meg a portszámot a környezeti változó értékeként. A példa a Bash-rendszerhéjhoz van formázva. Ha egy másik rendszerhéjat, például a PowerShellt vagy a parancssort részesíti előnyben, ennek megfelelően módosítania kell a változó-hozzárendelést.
```
az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'
```
Keresse meg a tárolócsoport IP-címét a parancs kimenetében az container create. Keresse meg az IP értékét.
A tároló sikeres kiépítése után keresse meg a tárolóalkalmazás IP-címét és portját a böngészőben, például: 192.0.2.0:9000.

Ekkor megjelenik a webalkalmazás által megjelenített "Üdvözöljük Azure Container Instances!" üzenet.
Ha végzett a tárolóval, távolítsa el a az container delete következő paranccsal:
```
az container delete --resource-group myResourceGroup --name mycontainer
```

Bizalmas tárolócsoportok üzembe helyezése során felmerülő problémák

Szabályzathibák egyéni CCE-szabályzat használata közben

Az egyéni CCE-szabályzatokat létre kell hozni az Azure CLI-konferenciabővítményt. A szabályzat létrehozása előtt győződjön meg arról, hogy az ARM-sablonban megadott összes tulajdonság érvényes, és megegyezik azzal, amit egy bizalmas számítási szabályzatban elvár. Az érvényesítendő tulajdonságok közé tartozik a tárolórendszerkép, a környezeti változók, a kötetcsatlakozások és a tárolóparancsok.

Hiányzó kivonat a szabályzatból

Az Azure CLI confcom bővítmény gyorsítótárazott lemezképeket fog használni a helyi gépen, amelyek nem feltétlenül egyeznek meg a távolról elérhető lemezképekkel, ami rétegeltérést eredményezhet a szabályzat érvényesítésekor. Győződjön meg arról, hogy eltávolítja a régi lemezképeket, és lekéri a legújabb tárolórendszerképeket a helyi környezetbe. Ha biztos abban, hogy a legújabb SHA-t használja, újra kell generálnia a CCE-szabályzatot.

Folyamat/tároló lezárva kilépési kóddal: 139

Ez a kilépési kód az Ubuntu 22.04-es alaprendszerképének korlátozásai miatt következik be. A probléma megoldásához ajánlott egy másik alaprendszerképet használni.

Következő lépések

Megtudhatja, hogyan kérdezheti le a tárolónaplókat és -eseményeket a tárolók hibakereséséhez.