Otwórz powłokę kontenera (SSH) i uruchamiaj polecenia w Azure App Service

App Service zapewnia uwierzytelniony dostęp do działających kontenerów aplikacji na potrzeby rozwiązywania problemów i zadań administracyjnych. Traktuj dostęp do kontenerów jako operację uprzywilejowaną i przyznawaj dostęp tylko użytkownikom, którzy go potrzebują.

App Service zapewnia dostęp SSH do aplikacji hostowanych w niestandardowych kontenerach Windows w przeglądarce. Nie jest wymagana żadna specjalna konfiguracja obrazu dla sesji przeglądarki.

Polecenie Azure CLI az webapp exec jest obsługiwane tylko dla aplikacji webowych na Linuksa. Nie używaj przykładów interfejsu wiersza polecenia systemu Linux z tego artykułu dla planów usługi App Service w systemie Windows.

Dla wbudowanych i niestandardowych kontenerów Linuksa nowszy terminal przeglądarkowy i az webapp exec używają Kudu jako uwierzytelnionego serwera proxy do połączenia z działającym kontenerem. Te opcje nie wymagają instalacji serwera SSH, osadzania hasła SSH, eksponowania portu SSH ani uruchamiania daemona SSH w niestandardowym obrazie. Starsze Kudu WebSSH i dostęp az webapp ssh mogą nadal wymagać serwera SSH w niestandardowym obrazie.

Użyj portalu Azure do sesji przeglądarkowej lub użyj polecenia az webapp exec w wersji zapoznawczej do lokalnej sesji terminala lub wykonania odłączonego polecenia. Terminal przeglądarki wymaga obecności /bin/bash w obrazie i obecnie nie obsługuje wyboru innej powłoki. Jeśli obraz ma inną powłokę systemową, użyj zamiast tego az webapp exec --shell /bin/sh. Obrazy bez powłoki, w tym obrazy distroless, nie mogą otworzyć interaktywnej sesji.

Prerequisites

  • Dla przykładów CLI zainstaluj Azure CLI 2.90.0 lub nowszy i zaloguj się. Sprawdź swoją wersję za pomocą az version. Możesz też użyć Azure Cloud Shell, jeśli jego CLI spełnia ten wymóg.
  • Do interaktywnej sesji CLI użyj interaktywnego terminala i powłoki istniejącej na Twoim obrazie. Domyślnie jest to /bin/bash; dla obrazu bez bashu określ --shell /bin/sh, jeśli ta powłoka jest dostępna.

Otwieranie sesji SSH w przeglądarce

Twoja aplikacja i jej kontener muszą działać przed otwarciem sesji w przeglądarce.

W portalu Azure otwórz aplikację App Service. W sekcji Narzędzia Programistyczne wybierz SSH, a następnie wybierz Go. Zaloguj się na swoje konto Azure, jeśli pojawi się taki monit.

Sesja otwiera się w przeglądarce, gdzie możesz uruchamiać polecenia wewnątrz kontenera aplikacji.

Połączenie SSH

Otwieranie sesji SSH za pomocą interfejsu wiersza polecenia platformy Azure

Polecenie preview az webapp exec otwiera interaktywną powłokę w głównym kontenerze aplikacji. Sesja korzysta z lokalnego terminala na Windows, macOS i Linux; nie otwiera przeglądarki.

az webapp exec --resource-group <resource-group-name> --name <app-name>

Dla obrazu, który używa /bin/sh zamiast bash:

az webapp exec --resource-group <resource-group-name> --name <app-name> --shell /bin/sh

Możesz uruchamiać polecenia i sprawdzać ich wyniki podczas tej sesji. Na przykład, użyj top , jeśli jest zainstalowany na obrazie. Aby obejrzeć kontener SCM/Kudu zamiast kontenera aplikacji:

az webapp exec --resource-group <resource-group-name> --name <app-name> --target kudu

Aplikacja i kontenery Kudu to różne środowiska. Uruchamiaj polecenia zależne od środowiska uruchomieniowego aplikacji, zależności lub łączności sieciowej aplikacji w kontenerze aplikacji.

Wybierz instancję lub slot wdrożenia

Domyślnie CLI łączy się z jedną instancją aplikacji. Aby znaleźć identyfikatory instancji:

az webapp list-instances --resource-group <resource-group-name> --name <app-name> --output table

Aby połączyć się z konkretną instancją:

az webapp exec --resource-group <resource-group-name> --name <app-name> --instance <instance-id>

Dodaj --slot <slot-name>, aby uzyskać dostęp do slotu wdrożenia. Wybierając instancję slotu, dodaj --slot także do az webapp list-instances.

Tryb powłoki interaktywnej obsługuje tylko jedną instancję naraz.

Uruchamiaj polecenia bez interaktywnej sesji

Użyj --mode execute do wysłania polecenia do głównego kontenera aplikacji bez otwierania sesji terminalowej. Komenda działa w tle. Ten tryb jest przydatny do diagnostyki w tle lub innych prac, które nie wymagają natychmiastowych wyników.

Important

Tryb Execute to fire-and-forget. Wynik o statusie accepted potwierdza jedynie, że żądanie zostało zaakceptowane, a nie że polecenie zostało wykonane, ukończone lub zakończyło się powodzeniem. CLI nie zwraca standardowego wyjścia, błędu standardowego ani kodu wyjścia z polecenia zdalnego. Nieudane przesłanie powoduje błąd CLI, ale udane wywołanie CLI nie jest dowodem udanego zdalnego wykonania. Użyj interaktywnej powłoki, gdy chcesz od razu zobaczyć wynik.

Uruchom program bezpośrednio

Używa się --command do określenia programu i jego argumentów. Cytuj całe polecenie:

az webapp exec --resource-group <resource-group-name> --name <app-name> --mode execute --command "python3 /home/site/wwwroot/scripts/diagnostics.py" --working-directory /home/site/wwwroot --instance <instance-id>

Zamień ścieżkę skryptu na ścieżkę do skryptu wdrożonego w aplikacji. Plik wykonywalny i jego zależności muszą istnieć w kontenerze.

--command nie interpretuje operatorów powłoki, takich jak >, |, czy &&. Używaj --shell-command zamiast tego, gdy potrzebujesz shella. Te dwie opcje są wzajemnie wykluczające się.

Przechwycenie wyjścia i sprawdzenie zakończenia

Poniższy przykład wykorzystuje cytowanie klienta Bash, na przykład w Cloud Shell. Wysyła polecenie diagnostyczne tylko do odczytu dla jednej instancji i zapisuje osobno jego dane wyjściowe oraz status wyjścia. Zastąp <run-id> nowym identyfikatorem dla każdego wywołania oraz <instance-id> identyfikatorem z az webapp list-instances.

az webapp exec --resource-group <resource-group-name> --name <app-name> \
  --mode execute --instance <instance-id> --shell /bin/sh \
  --shell-command 'uname -a > /home/LogFiles/diagnostics-<run-id>.log 2>&1; result=$?; printf "%s\n" "$result" > /home/LogFiles/diagnostics-<run-id>.exit'

Upewnij się, że istnieją /bin/sh i polecenie diagnostyczne, oraz że /home/LogFiles istnieje i jest zapisywalne. Trwałość /home w niestandardowych kontenerach zależy od konfiguracji magazynu w aplikacji. Pojedyncze cudzysłowy powstrzymują powłokę klienta przed rozwinięciem $? i $result przed dotarciem żądania do kontenera.

Po przesłaniu otwórz interaktywną powłokę aplikacji na tej samej instancji i obejrzyj pliki:

cat /home/LogFiles/diagnostics-<run-id>.log
cat /home/LogFiles/diagnostics-<run-id>.exit

Zarejestrowany status wyjścia 0 oznacza, że polecenie diagnostyczne zakończyło się sukcesem. Status niezerowy oznacza niepowodzenie; sprawdź log. Jeśli plik statusu nie istnieje, nie potwierdzono zakończenia: polecenie może nadal działać, mogło nie zostać rozpoczęte lub mogło zostać przerwane. Nie wyciągaj wniosków o sukcesie na podstawie akceptacji ani na podstawie niepełnego dziennika. Użyj identyfikatora nowego przebiegu, aby starszy plik statusu nie mógł zostać pomylony z aktualnym wynikiem.

CLI nie zapewnia interfejsu API do odpytywania o zakończenie. Przekierowanie wyjścia do pliku nie czyni go automatycznie dostępnym w strumieniowaniu logów App Service.

W przypadku migracji bazy danych lub innych operacji, które zmieniają stan współdzielony, wybierz jedną instancję, sprawdzaj zakończenie osobno i nie wykonuj operacji ponownie tylko dlatego, że uruchomienie nie zwróciło żadnego wyjścia. Zachowaj interaktywny przepływ pracy, gdy musisz upewnić się, że operacja zakończyła się powodzeniem, przed kontynuowaniem.

Uruchamianie niezależnych poleceń na wielu instancjach

Tryb wykonania akceptuje również listę identyfikatorów instancji oddzielonych przecinkami lub --instance all. Żądania dla wielu instancji są przesyłane równolegle. Na przykład uruchom wdrożony skrypt diagnostyczny dla poszczególnych instancji na każdej instancji:

az webapp exec --resource-group <resource-group-name> --name <app-name> --mode execute --command "python3 /home/site/wwwroot/scripts/diagnostics.py" --instance all

Skrypt musi rejestrować własne wyniki. Używaj różnych ścieżek wyjściowych dla każdej instancji i uruchomienia, jeśli pamięć masowa jest współdzielona. Nie używaj all do migracji współdzielonej bazy danych ani innych operacji, które muszą zostać uruchomione tylko raz. Jeśli niektóre zgłoszenia zakończą się niepowodzeniem, CLI zgłasza błąd, mimo że inne instancje mogły zaakceptować polecenie.

Dodaj --slot <slot-name>, aby uruchomić względem slotu wdrożenia.

Limitations

  • Tryb wykonania dotyczy tylko głównego kontenera aplikacji. Możesz używać --target kudu tylko w interaktywnym trybie powłoki.
  • Używaj --working-directory lub --cwd tylko w trybie wykonania i podaj absolutną ścieżkę.
  • Podaj absolutną ścieżkę dla --shell. W trybie wykonywania można go używać tylko z --shell-command.
  • Ten podgląd nie oferuje transferu plików, przekierowania portów ani opcji wyboru dowolnych kontenerów sidecar. Korzystaj z obsługiwanych metod wdrożenia do przesyłania plików.
  • Wykonanie w trybie odłączonym nie jest trwałym harmonogramatorem zadań. Ponowne uruchomienie lub wymiana kontenera może przerwać pracę. Nie zakładaj automatycznych ponowień ani wykonania dokładnie raz.

Kontroluj dostęp SSH

Wyłącz dostęp SSH w aplikacjach, które go nie potrzebują, ustawiając właściwość konfiguracji aplikacji sshEnabled na false. Poniższe przykłady wykorzystują cytowanie JSON w Bashu:

az webapp config set --resource-group <resource-group-name> --name <app-name> \
  --generic-configurations '{"sshEnabled": false}'

Aby ponownie włączyć dostęp SSH:

az webapp config set --resource-group <resource-group-name> --name <app-name> \
  --generic-configurations '{"sshEnabled": true}'

Aby obejrzeć konfigurację:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query sshEnabled

Dodaj --slot <slot-name>, aby skonfigurować lub sprawdzić slot wdrożenia.

Aby zarządzać zasadami dla aplikacji i slotów, użyj wbudowanych zasad Aplikacje App Service powinny mieć wyłączony protokół SSH i Sloty aplikacji App Service powinny mieć wyłączony protokół SSH. Zobacz informacje o zasadach App Service, aby znaleźć linki do przypisań.

Obie polityki są domyślnie ustawione na Audit i obsługują również Deny oraz Disabled. Oceniają nieobecną lub różną od false sshEnabled wartość jako niezgodną. Audyt zgłasza niezgodność; nie wyłącza SSH. Deny zapobiega niezgodnym zmianom zasobów; nie rekonfiguruje automatycznie istniejących aplikacji. Możesz przypisywać zasady w zakresie subskrypcji lub grupy zarządzającej, w tym głównej grupy zarządzania dzierżawy, na potrzeby zarządzania w całej dzierżawie.

Konfiguracja SSH i zgodność z polityką nie zastępują zabezpieczenia dostępu do SCM/Kudu. Używaj odpowiednich uprawnień RBAC i ograniczeń dostępu do sieci.

Rozwiązywanie problemów z dostępem do kontenerów

  • Potwierdź, że aplikacja uruchamia się pomyślnie. Przejrzyj logi diagnostyczne pod kątem błędów uruchamiania.
  • Aby uzyskać dostęp do CLI, sprawdź wersję CLI, wybraną aplikację, slot i instancję oraz czy istnieje żądany plik wykonywalny lub powłoka.
  • Sprawdź autoryzację i łączność sieciową z punktem końcowym SCM. Nie musisz włączać podstawowego uwierzytelniania publikowania; interfejs CLI obsługuje uwierzytelnianie Microsoft Entra, gdy podstawowe uwierzytelnianie SCM jest wyłączone. Zobacz Wyłącz podstawową autentyzację.
  • Zmiany wprowadzane wewnątrz kontenera nie zastępują konieczności aktualizacji i ponownego wdrożenia aplikacji lub obrazu. Restarty kontenera mogą usuwać pliki spoza trwałego magazynu.

Treści powiązane

  • Ostatnia aktualizacja o