Udostępnij przez


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

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.

Zakres Długość Obudowa Prawidłowe znaki Sugerowany wzorzec Przykład
Nazwa kontenera1 1-63 Małe litery Alfanumeryczne i łączniki z wyjątkiem pierwszego lub ostatniego znaku <name>-<role>-container<number> web-batch-container1
Porty kontenerowe 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 Znaki alfanumeryczne oraz łączniki mogą występować w dowolnym miejscu, z wyjątkiem pierwszego lub ostatniego znaku. Nie można zawierać dwóch kolejnych łączników. <name> batch-output-volume

1 Ograniczenia dotyczą także nazw grup kontenerów, gdy nie są one określone niezależnie od wystąpień kontenerów, na przykład przy wdrożeniach poleceń az container create.

Wersja obrazu systemu operacyjnego nie jest obsługiwana

Jeśli określisz obraz, którego usługa Azure Container Instances nie obsługuje, zostanie zwrócony błąd OsVersionNotSupported. 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 Semi-Annual channel release 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ę przez pewien czas. Jeśli operacja ściągania obrazu nadal się nie powiedzie, ACI ostatecznie zakończy wdrożenie niepowodzeniem, a może zostać wyświetlony błąd Failed to pull image.

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, następujące zdarzenia są wyświetlane w wyniku 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ępności 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 mieszczą się w ramach parametrów zdefiniowanych w dostępności 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 działania 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 prac konserwacyjnych. 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 się wyłącza i uruchamia ponownie (brak nieprzerwanego procesu)

Domyślną zasadą ponownego uruchamiania dla grup kontenerów jest Zawsze, więc kontenery w grupie kontenerów są zawsze uruchamiane ponownie po zakończeniu działania. 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 do wdrożenia grupy kontenerów polecenie uruchomienia. Dzięki temu kontener będzie wciąż działał, tak jak w poniższym przykładzie.

## 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ższym przykładowym wyniku, który skróciliśmy dla zwięzłości, zobaczysz restartCount atrybut na końcu.

...
 "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 bash, jako domyślną komendę. Ponieważ powłoka sama w sobie nie jest długotrwałą usługą, te kontenery natychmiast się zamkną i wpadają w pętlę ponownego uruchamiania po skonfigurowaniu z domyślną zasadą Zawsze.

Uruchomienie kontenera trwa długo

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

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 praktykami 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, a uważasz, że powinien być, upewnij się, że skonfigurowałeś obraz kontenera do nasłuchiwania na tych samych portach, które udostępniasz w grupie kontenerów za pomocą właściwości ports.

Jeśli chcesz potwierdzić, że usługa Azure Container Instances może słuchać na porcie skonfigurowanym w obrazie kontenera, przetestuj wdrożenie obrazu aci-helloworld, który udostępnia port. Uruchom również aplikację aci-helloworld, aby nasłuchiwała 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:

  1. 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ę, na przykład PowerShell lub wiersz polecenia, musisz odpowiednio dostosować przypisanie zmiennych.

    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. Znajdź adres IP grupy kontenerów w danych wyjściowych az container createpolecenia . Wyszukaj wartość adresu IP.

  3. Po pomyślnym uruchomieniu kontenera, przejdź w przeglądarce do adresu IP i portu aplikacji w kontenerze, 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ą.

  4. Po zakończeniu pracy z kontenerem usuń go przy użyciu az container delete polecenia :

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

Problemy przy wdrażaniu grup kontenerów o charakterze poufnym

Błędy podczas korzystania z niestandardowej polityki CCE

Niestandardowe zasady CCE należy generować przy użyciu rozszerzenia 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 funkcji skrótu w polityce

Rozszerzenie confcom interfejsu linii poleceń platformy Azure używa buforowanych obrazów na komputerze lokalnym, które mogą nie odpowiadać obrazom dostępnym zdalnie. Może to prowadzić do niezgodności warstw podczas weryfikacji 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ć politykę 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.