Rozwiązywanie typowych problemów w usłudze Azure Container Instances

Artykuł
08/29/2024

W tym artykule pokazano, jak rozwiązywać typowe problemy z zarządzaniem kontenerami lub wdrażaniem ich w usłudze Azure Container Instances. Zobacz też często zadawane pytania.

Jeśli potrzebujesz dodatkowej pomocy technicznej, zobacz dostępne opcje Pomocy i obsługi technicznej w witrynie Azure Portal.

Problemy podczas wdrażania grupy kontenerów

Konwencje nazewnictwa

Podczas definiowania specyfikacji kontenera niektóre parametry wymagają przestrzegania ograniczeń nazewnictwa. W poniższej tabeli przedstawiono określone wymagania dotyczące właściwości grupy kontenerów. Aby uzyskać więcej informacji, zobacz Konwencje nazewnictwa w Centrum architektury platformy Azure oraz reguły i ograniczenia nazewnictwa dla zasobów platformy Azure.

Scope	Długość	Wielkość liter	Prawidłowe znaki	Sugerowany wzorzec	Przykład
Nazwa^{kontenera 1}	1-63	Małe litery	Alfanumeryczne i łączniki z wyjątkiem pierwszego lub ostatniego znaku	`<name>-<role>-container<number>`	`web-batch-container1`
Porty kontenera	Od 1 do 65535	Integer	Liczba całkowita z zakresu od 1 do 65535	`<port-number>`	`443`
Etykieta nazwy DNS	5-63	Bez uwzględniania wielkości liter	Alfanumeryczne i łączniki z wyjątkiem pierwszego lub ostatniego znaku	`<name>`	`frontend-site1`
Zmienna środowiskowa	1-63	Bez uwzględniania wielkości liter	Alfanumeryczne i podkreślenie (_) w dowolnym miejscu z wyjątkiem pierwszego lub ostatniego znaku	`<name>`	`MY_VARIABLE`
Nazwa woluminu	5-63	Małe litery	Alfanumeryczne i łączniki z wyjątkiem pierwszego lub ostatniego znaku. Nie można zawierać dwóch kolejnych łączników.	`<name>`	`batch-output-volume`

¹Ograniczenie dotyczy również nazw grup kontenerów, jeśli nie są określone niezależnie od wystąpień kontenera, na przykład we az container create wdrożeniach poleceń.

Wersja obrazu systemu operacyjnego nie jest obsługiwana

Jeśli określisz obraz, który usługa Azure Container Instances nie obsługuje, OsVersionNotSupported zostanie zwrócony błąd. Błąd jest podobny do następującego, gdzie {0} jest nazwą obrazu, który próbowano wdrożyć:

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

Ten błąd występuje najczęściej podczas wdrażania obrazów systemu Windows opartych na półrocznej wersji kanału 1709 lub 1803, które nie są obsługiwane. Aby uzyskać informacje o obsługiwanych obrazach systemu Windows w usłudze Azure Container Instances, zobacz Często zadawane pytania.

Nie można pobrać obrazu

Jeśli usługa Azure Container Instances początkowo nie może ściągnąć obrazu, ponawia próbę na czas. Jeśli operacja ściągania obrazu zakończy się niepowodzeniem, usługa ACI ostatecznie zakończy się niepowodzeniem Failed to pull image wdrożenia i może zostać wyświetlony błąd.

Aby rozwiązać ten problem, usuń wystąpienie kontenera i ponów próbę wdrożenia. Upewnij się, że obraz istnieje w rejestrze, a nazwa obrazu została wpisana poprawnie.

Jeśli nie można ściągnąć obrazu, zdarzenia takie jak poniżej są wyświetlane w danych wyjściowych polecenia 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"
  }
],

Błąd niedostępny zasobu

Ze względu na różne obciążenia zasobów regionalnych na platformie Azure podczas próby wdrożenia wystąpienia kontenera może wystąpić następujący błąd:

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.

Ten błąd wskazuje, że ze względu na duże obciążenie w regionie, w którym próbujesz wdrożyć, nie można przydzielić zasobów określonych dla kontenera w tym czasie. Aby rozwiązać problem, użyj co najmniej jednego z poniższych kroków zaradczych.

Sprawdź, czy ustawienia wdrażania kontenera należą do parametrów zdefiniowanych w obszarze Dostępność regionów dla usługi Azure Container Instances
Określanie niższych ustawień procesora CPU i pamięci dla kontenera
Wdrażanie w innym regionie świadczenia usługi Azure
Wdrażanie w późniejszym czasie

Problemy podczas wykonywania grupy kontenerów

Kontener miał izolowane ponowne uruchomienie bez jawnych danych wejściowych użytkownika

Istnieją dwie szerokie kategorie, dla których grupa kontenerów może zostać ponownie uruchomiona bez jawnych danych wejściowych użytkownika. Najpierw kontenery mogą napotkać ponowne uruchomienia spowodowane awarią procesu aplikacji. Usługa ACI zaleca stosowanie rozwiązań do obserwacji, takich jak zestaw SDK usługi Application Insights, metryki grupy kontenerów i dzienniki grup kontenerów , aby określić, dlaczego aplikacja napotkała problemy. Po drugie, klienci mogą napotkać ponowne uruchomienia inicjowane przez infrastrukturę usługi ACI z powodu zdarzeń konserwacji. Aby zwiększyć dostępność aplikacji, uruchom wiele grup kontenerów za składnikiem ruchu przychodzącego, takim jak usługa Application Gateway lub usługa Traffic Manager.

Kontener ciągle kończy działanie i uruchamia się ponownie (brak długotrwałego procesu)

Grupy kontenerów są domyślne dla zasad ponownego uruchamiania zawsze, więc kontenery w grupie kontenerów są zawsze uruchamiane ponownie po uruchomieniu do ukończenia. Może być konieczne zmianę tej opcji na OnFailure lub Nigdy , jeśli zamierzasz uruchamiać kontenery oparte na zadaniach. Jeśli określisz wartość OnFailure i nadal widzisz ciągłe ponowne uruchomienia, może wystąpić problem z aplikacją lub skryptem wykonanym w kontenerze.

Po uruchomieniu grup kontenerów bez długotrwałych procesów mogą pojawić się powtarzające się zakończenia i ponowne uruchomienie obrazów, takich jak Ubuntu lub Alpine. Nawiązywanie połączenia za pośrednictwem narzędzia EXEC nie będzie działać, ponieważ kontener nie ma procesu utrzymującego go w życiu. Aby rozwiązać ten problem, dołącz polecenie uruchamiania, takie jak w poniższym przykładzie z wdrożeniem grupy kontenerów, aby zachować działanie kontenera.

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

Interfejs API usługi Container Instances i witryna Azure Portal zawierają restartCount właściwość. Aby sprawdzić liczbę ponownych uruchomień kontenera, możesz użyć polecenia az container show w interfejsie wiersza polecenia platformy Azure. W poniższych przykładowych danych wyjściowych, które obcinaliśmy w celu zwięzłości, zobaczysz restartCount właściwość na końcu danych wyjściowych.

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

Uwaga

Większość obrazów kontenerów dla dystrybucji systemu Linux ustawia powłokę, taką jak powłoka bash, jako domyślne polecenie. Ponieważ powłoka samodzielnie nie jest długotrwałą usługą, te kontenery natychmiast wyjdą i wchodzą w pętlę ponownego uruchamiania po skonfigurowaniu przy użyciu domyślnych zasad Zawsze uruchamiaj ponownie.

Uruchomienie kontenera trwa długo

Trzy podstawowe czynniki, które przyczyniają się do czasu uruchamiania kontenera w usłudze Azure Container Instances, to:

Rozmiar obrazu
Lokalizacja obrazu
Obrazy buforowane

Obrazy systemu Windows mają dalsze uwagi.

Rozmiar obrazu

Jeśli uruchomienie kontenera zajmuje dużo czasu, ale ostatecznie zakończy się powodzeniem, zacznij od przyjrzenia się rozmiarowi obrazu kontenera. Ponieważ usługa Azure Container Instances ściąga obraz kontenera na żądanie, widoczny czas uruchamiania jest bezpośrednio związany z jego rozmiarem.

Rozmiar obrazu kontenera można wyświetlić przy użyciu docker images polecenia w interfejsie wiersza polecenia platformy Docker:

docker images

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

Kluczem do utrzymywania małych rozmiarów obrazów jest zapewnienie, że końcowy obraz nie zawiera żadnych elementów, które nie są wymagane w czasie wykonywania. Jednym ze sposobów wykonania tej czynności jest użycie kompilacji wieloetapowych. Kompilacje wieloetapowe ułatwiają zapewnienie, że końcowy obraz zawiera tylko artefakty potrzebne dla aplikacji, a nie każdą dodatkową zawartość wymaganą w czasie kompilacji.

Lokalizacja obrazu

Innym sposobem zmniejszenia wpływu ściągania obrazu na czas uruchamiania kontenera jest hostowanie obrazu kontenera w usłudze Azure Container Registry w tym samym regionie, w którym zamierzasz wdrożyć wystąpienia kontenerów. Skraca to ścieżkę sieci, którą obraz kontenera musi podróżować, znacznie skracając czas pobierania.

Obrazy buforowane

Usługa Azure Container Instances używa mechanizmu buforowania, aby przyspieszyć czas uruchamiania kontenera dla obrazów opartych na typowych obrazach podstawowych systemu Windows, w tym nanoserver:1809, servercore:ltsc2019i servercore:1809. Często używane obrazy systemu Linux, takie jak ubuntu:1604 i alpine:3.6 są również buforowane. W przypadku obrazów systemu Windows i Linux unikaj używania tagu latest . Zapoznaj się z najlepszymi rozwiązaniami dotyczącymi tagów obrazów usługi Container Registry, aby uzyskać wskazówki. Aby uzyskać aktualną listę buforowanych obrazów i tagów, użyj interfejsu API List Cached Images .

Uwaga

Korzystanie z obrazów opartych na systemie Windows Server 2019 w usłudze Azure Container Instances jest w wersji zapoznawczej.

Kontenery systemu Windows spowalniają gotowość sieci

Podczas początkowego tworzenia kontenery systemu Windows mogą nie mieć łączności przychodzącej ani wychodzącej przez maksymalnie 30 sekund (lub dłużej, w rzadkich przypadkach). Jeśli aplikacja kontenera wymaga połączenia z Internetem, dodaj logikę opóźnienia i ponawiania prób, aby umożliwić 30 sekund nawiązywanie łączności z Internetem. Po wstępnej konfiguracji sieć kontenerów powinna zostać odpowiednio wznowiona.

Nie można nawiązać połączenia z podstawowym interfejsem API platformy Docker ani uruchamiać kontenerów uprzywilejowanych

Usługa Azure Container Instances nie uwidacznia bezpośredniego dostępu do podstawowej infrastruktury, która hostuje grupy kontenerów. Obejmuje to dostęp do środowiska uruchomieniowego kontenera, technologii orkiestracji i uruchamiania uprzywilejowanych operacji kontenera. Aby zobaczyć, jakie operacje obsługuje usługa ACI, zapoznaj się z dokumentacją referencyjną REST. Jeśli brakuje czegoś, prześlij żądanie na forach opinii usługi ACI.

Adres IP grupy kontenerów może nie być dostępny z powodu niezgodności portów

Usługa Azure Container Instances nie obsługuje jeszcze mapowania portów, tak jak w przypadku regularnej konfiguracji platformy Docker. Jeśli okaże się, że adres IP grupy kontenerów nie jest dostępny, jeśli uważasz, że powinien to być, upewnij się, że skonfigurowano obraz kontenera do nasłuchiwania tych samych portów, które uwidaczniasz w grupie kontenerów za pomocą ports właściwości .

Jeśli chcesz potwierdzić, że usługa Azure Container Instances może nasłuchiwać na porcie skonfigurowanym w obrazie kontenera, przetestuj wdrożenie aci-helloworld obrazu, który uwidacznia port. Uruchom również aplikację aci-helloworld , aby nasłuchiwać na porcie. aci-helloworld akceptuje opcjonalną zmienną środowiskową PORT , aby zastąpić domyślny port 80, na który nasłuchuje. Aby na przykład przetestować port 9000, ustaw zmienną środowiskową podczas tworzenia grupy kontenerów:

Skonfiguruj grupę kontenerów, aby uwidocznić port 9000 i przekazać numer portu jako wartość zmiennej środowiskowej. Przykład jest sformatowany dla powłoki Bash. Jeśli wolisz inną powłokę, taką jak program PowerShell lub wiersz polecenia, musisz odpowiednio dostosować przypisanie zmiennej.
```
az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'
```
Znajdź adres IP grupy kontenerów w danych wyjściowych az container createpolecenia . Wyszukaj wartość adresu IP.
Po pomyślnym aprowizacji kontenera przejdź do adresu IP i portu aplikacji kontenera w przeglądarce, na przykład: 192.0.2.0:9000.

Powinien zostać wyświetlony komunikat "Witamy w usłudze Azure Container Instances!" wyświetlany przez aplikację internetową.
Po zakończeniu pracy z kontenerem usuń go przy użyciu az container delete polecenia :
```
az container delete --resource-group myResourceGroup --name mycontainer
```

Problemy podczas wdrożeń poufnych grup kontenerów

Błędy zasad podczas korzystania z niestandardowych zasad CCE

Niestandardowe zasady CCE należy wygenerować rozszerzenie confcom interfejsu wiersza polecenia platformy Azure. Przed wygenerowaniem zasad upewnij się, że wszystkie właściwości określone w szablonie usługi ARM są prawidłowe i zgodne z oczekiwaniami w zasadach poufnego przetwarzania. Niektóre właściwości do zweryfikowania obejmują obraz kontenera, zmienne środowiskowe, instalowanie woluminów i polecenia kontenera.

Brak skrótu z zasad

Rozszerzenie confcom interfejsu wiersza polecenia platformy Azure używa buforowanych obrazów na komputerze lokalnym, które mogą nie odpowiadać tym, które są dostępne zdalnie, co może spowodować niezgodność warstw po zweryfikowaniu zasad. Upewnij się, że usunięto wszystkie stare obrazy i pobraliśmy najnowsze obrazy kontenera do środowiska lokalnego. Po upewnieniu się, że masz najnowsze sha, należy ponownie wygenerować zasady CCE.

Proces/kontener zakończony kodem zakończenia: 139

Ten kod zakończenia występuje z powodu ograniczeń dotyczących obrazu podstawowego ubuntu w wersji 22.04. Zaleca się użycie innego obrazu podstawowego w celu rozwiązania tego problemu.

Następne kroki

Dowiedz się, jak pobierać dzienniki kontenerów i zdarzenia , aby ułatwić debugowanie kontenerów.

Udostępnij za pośrednictwem