Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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:
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'Znajdź adres IP grupy kontenerów w danych wyjściowych
az container createpolecenia . Wyszukaj wartość adresu IP.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ą.
Po zakończeniu pracy z kontenerem usuń go przy użyciu
az container deletepolecenia :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.