Konfigurowanie niestandardowego kontenera dla usługi Azure App Service

  • Artykuł

W tym artykule przedstawiono sposób konfigurowania niestandardowego kontenera do uruchamiania w usłudze aplikacja systemu Azure Service.

Ten przewodnik zawiera kluczowe pojęcia i instrukcje dotyczące konteneryzacji aplikacji systemu Windows w usłudze App Service. Nowi użytkownicy usługi aplikacja systemu Azure powinni najpierw postępować zgodnie z przewodnikiem Szybki start i samouczkiem dotyczącym kontenera niestandardowego.

Ten przewodnik zawiera kluczowe pojęcia i instrukcje dotyczące konteneryzacji aplikacji systemu Linux w usłudze App Service. Jeśli dopiero zaczynasz aplikacja systemu Azure Service, najpierw postępuj zgodnie z przewodnikiem Szybki start i samouczkiem dotyczącym kontenera niestandardowego. Dostępny jest również przewodnik Szybki start i samouczek dotyczący aplikacji z wieloma kontenerami. Aby zapoznać się z kontenerami przyczepki (wersja zapoznawcza), zobacz Samouczek: konfigurowanie kontenera przyczepki dla kontenera niestandardowego w usłudze aplikacja systemu Azure (wersja zapoznawcza).

Uwaga

Jednostka usługi nie jest już obsługiwana w przypadku uwierzytelniania ściągania obrazu kontenera systemu Windows. Zalecanym sposobem jest użycie tożsamości zarządzanej zarówno dla kontenerów systemu Windows, jak i Linux

Obsługiwane obrazy nadrzędne

W przypadku niestandardowego obrazu systemu Windows musisz wybrać odpowiedni obraz nadrzędny (obraz podstawowy) dla odpowiedniej struktury:

Pobieranie obrazu nadrzędnego podczas uruchamiania aplikacji może zająć trochę czasu. Można jednak skrócić czas uruchamiania, korzystając z jednego z następujących obrazów nadrzędnych, które już zostały zbuforowane w usłudze Azure App Service:

  • mcr.microsoft.com/windows/servercore:ltsc2022
  • mcr.microsoft.com/windows/servercore:ltsc2019
  • mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022
  • mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
  • mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-ltsc2022
  • mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-1809
  • mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-ltsc2022
  • mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-1809

Zmienianie obrazu platformy Docker kontenera niestandardowego

Aby zmienić istniejący kontener niestandardowy z bieżącego obrazu platformy Docker na nowy obraz, użyj następującego polecenia:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <docker-hub-repo>/<image>

Używanie obrazu z rejestru prywatnego

Aby użyć obrazu z rejestru prywatnego, takiego jak usługa Azure Container Registry, uruchom następujące polecenie:

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <image-name> --docker-registry-server-url <private-repo-url> --docker-registry-server-user <username> --docker-registry-server-password <password>

W przypadku nazwy użytkownika> i <hasła> podaj poświadczenia logowania dla prywatnego konta rejestru.<

Używanie tożsamości zarządzanej do ściągania obrazu z usługi Azure Container Registry

Wykonaj poniższe kroki, aby skonfigurować aplikację internetową do ściągania z usługi Azure Container Registry (ACR) przy użyciu tożsamości zarządzanej. W krokach jest używana tożsamość zarządzana przypisana przez system, ale można również użyć tożsamości zarządzanej przypisanej przez użytkownika.

  1. Włącz tożsamość zarządzaną przypisaną przez system dla aplikacji internetowej przy użyciu az webapp identity assign polecenia :

    az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv

    Zastąp <app-name> ciąg nazwą użytą w poprzednim kroku. Dane wyjściowe polecenia (filtrowane według --query argumentów i --output ) to identyfikator jednostki usługi przypisanej tożsamości.

  2. Pobierz identyfikator zasobu usługi Azure Container Registry:

    az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv

    Zastąp ciąg <registry-name> nazwą rejestru. Dane wyjściowe polecenia (filtrowane według --query argumentów i --output ) to identyfikator zasobu usługi Azure Container Registry.

  3. Udziel tożsamości zarządzanej uprawnienia dostępu do rejestru kontenerów:

    az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"

    Zastąp następujące wartości:

    • <principal-id> z identyfikatorem jednostki usługi z az webapp identity assign polecenia
    • <registry-resource-id> za pomocą identyfikatora rejestru kontenerów z az acr show polecenia

    Aby uzyskać więcej informacji na temat tych uprawnień, zobacz Co to jest kontrola dostępu oparta na rolach platformy Azure.

  4. Skonfiguruj aplikację tak, aby korzystała z tożsamości zarządzanej do ściągania z usługi Azure Container Registry.

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

    Zastąp następujące wartości:

    • <app-name> z nazwą aplikacji internetowej.

    Napiwek

    Jeśli używasz konsoli programu PowerShell do uruchamiania poleceń, musisz użyć ucieczki ciągów w argumencie --generic-configurations w tym i następnym kroku. Na przykład: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'.

  5. (Opcjonalnie) Jeśli aplikacja używa tożsamości zarządzanej przypisanej przez użytkownika, upewnij się, że tożsamość jest skonfigurowana w aplikacji internetowej, a następnie ustaw acrUserManagedIdentityID właściwość, aby określić jej identyfikator klienta:

    az identity show --resource-group <group-name> --name <identity-name> --query clientId --output tsv

    Zastąp <identity-name> wartość tożsamości zarządzanej przypisanej przez użytkownika i użyj danych wyjściowych <client-id> , aby skonfigurować identyfikator tożsamości zarządzanej przypisanej przez użytkownika.

    az  webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'

Wszystko jest ustawione, a aplikacja internetowa używa teraz tożsamości zarządzanej do ściągania z usługi Azure Container Registry.

Używanie obrazu z rejestru chronionego przez sieć

Aby nawiązać połączenie i ściągnąć z rejestru w sieci wirtualnej lub lokalnie, aplikacja musi zostać zintegrowana z siecią wirtualną. Integracja z siecią wirtualną jest również wymagana w usłudze Azure Container Registry z prywatnym punktem końcowym. Po skonfigurowaniu sieci i rozpoznawania nazw DNS można włączyć routing obrazu ściągnięcia przez sieć wirtualną, konfigurując ustawienie lokacji vnetImagePullEnabled :

az resource update --resource-group <group-name> --name <app-name> --resource-type "Microsoft.Web/sites" --set properties.vnetImagePullEnabled [true|false]

Nie widzę zaktualizowanego kontenera

Jeśli zmienisz ustawienia kontenera platformy Docker tak, aby wskazywały nowy kontener, może upłynąć kilka minut, zanim aplikacja będzie obsługiwać żądania HTTP z nowego kontenera. Podczas ściągania i uruchamiania nowego kontenera usługa App Service nadal obsługuje żądania ze starego kontenera. Dopiero po uruchomieniu nowego kontenera i gotowości do odbierania żądań usługa App Service zacznie wysyłać do niego żądania.

Jak są przechowywane obrazy kontenerów

Przy pierwszym uruchomieniu niestandardowego obrazu platformy Docker w usłudze App Service usługa App Service wykonuje docker pull polecenie i ściąga wszystkie warstwy obrazu. Te warstwy są przechowywane na dysku, tak jak w przypadku korzystania z platformy Docker w środowisku lokalnym. Za każdym razem, gdy aplikacja zostanie ponownie uruchomiona, usługa App Service wykonuje docker pullpolecenie , ale ściąga tylko warstwy, które uległy zmianie. Jeśli nie ma żadnych zmian, usługa App Service używa istniejących warstw na dysku lokalnym.

Jeśli aplikacja zmieni wystąpienia obliczeniowe z jakiegokolwiek powodu, takie jak skalowanie w górę i w dół warstw cenowych, usługa App Service musi ponownie ściągnąć wszystkie warstwy. To samo dotyczy skalowania w poziomie w celu dodania większej liczby wystąpień. Istnieją również rzadkie przypadki, w których wystąpienia aplikacji mogą ulec zmianie bez operacji skalowania.

Konfigurowanie numeru portu

Domyślnie usługa App Service zakłada, że niestandardowy kontener nasłuchuje na porcie 80. Jeśli kontener nasłuchuje innego portu, ustaw WEBSITES_PORT ustawienie aplikacji w aplikacji usługi App Service. Można go ustawić za pośrednictwem usługi Cloud Shell. W powłoce Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_PORT=8000

W programie PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_PORT"="8000"}

Usługa App Service umożliwia obecnie kontenerowi uwidocznienie tylko jednego portu dla żądań HTTP.

Skonfiguruj zmienne środowiskowe

Kontener niestandardowy może używać zmiennych środowiskowych, które muszą być dostarczane zewnętrznie. Możesz przekazać je za pośrednictwem usługi Cloud Shell. W powłoce Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings DB_HOST="myownserver.mysql.database.azure.com"

W programie PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"}

Po uruchomieniu aplikacji ustawienia aplikacji usługi App Service są automatycznie wstrzykiwane do procesu jako zmienne środowiskowe. Zmienne środowiskowe kontenera można zweryfikować przy użyciu adresu URL https://<app-name>.scm.azurewebsites.net/Env.

Jeśli aplikacja używa obrazów z rejestru prywatnego lub z usługi Docker Hub, poświadczenia umożliwiające uzyskanie dostępu do repozytorium są zapisywane w zmiennych środowiskowych: DOCKER_REGISTRY_SERVER_URLi DOCKER_REGISTRY_SERVER_USERNAMEDOCKER_REGISTRY_SERVER_PASSWORD. Ze względu na zagrożenia bezpieczeństwa żadna z tych nazw zmiennych zarezerwowanych nie jest widoczna dla aplikacji.

W przypadku kontenerów opartych na usługach IIS lub .NET Framework (4.0 lub nowszych) są one wstrzykiwane jako System.ConfigurationManager ustawienia aplikacji platformy .NET i automatycznie parametry połączenia przez usługę App Service. Dla wszystkich innych języków lub struktur są one udostępniane jako zmienne środowiskowe dla procesu, z jednym z następujących odpowiednich prefiksów:

  • APPSETTING_
  • SQLCONTR_
  • MYSQLCONTR_
  • SQLAZURECOSTR_
  • POSTGRESQLCONTR_
  • CUSTOMCONNSTR_

Ta metoda działa zarówno w przypadku aplikacji jednokontenerowych, jak i aplikacji wielokontenerowych, w których zmienne środowiskowe są określone w pliku docker-compose.yml .

Używanie trwałego magazynu udostępnionego

Możesz użyć katalogu C:\home w niestandardowym systemie plików kontenera, aby utrwalać pliki po ponownym uruchomieniu i udostępniać je między wystąpieniami. Katalog C:\home jest udostępniany w celu umożliwienia niestandardowemu kontenerowi uzyskiwania dostępu do magazynu trwałego.

Gdy magazyn trwały jest wyłączony, zapisy w C:\home katalogu nie są utrwalane podczas ponownego uruchamiania aplikacji ani w wielu wystąpieniach. Po włączeniu magazynu trwałego wszystkie operacje zapisu w C:\home katalogu są utrwalane i mogą być dostępne dla wszystkich wystąpień aplikacji skalowanej w poziomie. Ponadto każda zawartość w C:\home katalogu kontenera jest zastępowana przez wszystkie istniejące pliki już obecne w magazynie trwałym po uruchomieniu kontenera.

Jedynym wyjątkiem jest C:\home\LogFiles katalog, który jest używany do przechowywania dzienników kontenera i aplikacji. Ten folder zawsze będzie się powtarzać po ponownym uruchomieniu aplikacji, jeśli rejestrowanie aplikacji jest włączone z opcją System plików, niezależnie od włączonego lub wyłączonego magazynu trwałego. Innymi słowy włączenie lub wyłączenie magazynu trwałego nie ma wpływu na zachowanie rejestrowania aplikacji.

Domyślnie magazyn trwały jest wyłączony w kontenerach niestandardowych systemu Windows. Aby ją włączyć, ustaw WEBSITES_ENABLE_APP_SERVICE_STORAGE wartość ustawienia aplikacji na true za pośrednictwem usługi Cloud Shell. W powłoce Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

W programie PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=true}

Możesz użyć katalogu /home w niestandardowym systemie plików kontenera, aby utrwalać pliki między ponownymi uruchomieniami i udostępniać je między wystąpieniami. Katalog /home jest udostępniany w celu umożliwienia niestandardowemu kontenerowi uzyskiwania dostępu do magazynu trwałego. Zapisywanie danych w ramach programu /home przyczynia się do limitu przydziału miejsca do magazynowania uwzględnionego w planie usługi App Service.

Gdy magazyn trwały jest wyłączony, zapisy w /home katalogu nie są utrwalane podczas ponownego uruchamiania aplikacji ani w wielu wystąpieniach. Po włączeniu magazynu trwałego wszystkie operacje zapisu w /home katalogu są utrwalane i mogą być dostępne dla wszystkich wystąpień aplikacji skalowanej w poziomie. Ponadto każda zawartość w /home katalogu kontenera jest zastępowana przez wszystkie istniejące pliki już obecne w magazynie trwałym po uruchomieniu kontenera.

Jedynym wyjątkiem jest /home/LogFiles katalog, który jest używany do przechowywania dzienników kontenera i aplikacji. Ten folder zawsze będzie się powtarzać po ponownym uruchomieniu aplikacji, jeśli rejestrowanie aplikacji jest włączone z opcją System plików, niezależnie od włączonego lub wyłączonego magazynu trwałego. Innymi słowy włączenie lub wyłączenie magazynu trwałego nie ma wpływu na zachowanie rejestrowania aplikacji.

Zaleca się zapisywanie danych w /home ścieżce magazynu platformy Azure lub w zainstalowanej ścieżce magazynu platformy Azure. Dane zapisywane poza tymi ścieżkami nie są trwałe podczas ponownego uruchamiania i są zapisywane na dysku hosta zarządzanego przez platformę niezależnie od limitu przydziału magazynu plików planów usługi App Service.

Domyślnie magazyn trwały jest włączony w kontenerach niestandardowych systemu Linux. Aby ją wyłączyć, ustaw WEBSITES_ENABLE_APP_SERVICE_STORAGE wartość ustawienia aplikacji na false za pośrednictwem usługi Cloud Shell. W powłoce Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=false

W programie PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=false}

Uwaga

Możesz również skonfigurować własny magazyn trwały.

Wykrywanie sesji protokołu HTTPS

Usługa App Service kończy protokół TLS/SSL na frontonach. Oznacza to, że żądania TLS/SSL nigdy nie są wysyłane do aplikacji. Nie musisz i nie należy implementować żadnej obsługi protokołu TLS/SSL w aplikacji.

Frontony znajdują się w centrach danych platformy Azure. Jeśli używasz protokołu TLS/SSL z aplikacją, ruch przez Internet jest zawsze bezpiecznie szyfrowany.

Dostosowywanie iniekcji klucza maszyny ASP.NET

Podczas uruchamiania kontenera automatycznie generowane klucze są wstrzykiwane do kontenera jako klucze maszyny dla ASP.NET procedur kryptograficznych. Te klucze można znaleźć w kontenerze, wyszukując następujące zmienne środowiskowe: MACHINEKEY_Decryption, , MACHINEKEY_DecryptionKeyMACHINEKEY_ValidationKey, MACHINEKEY_Validation.

Nowe klucze przy każdym ponownym uruchomieniu mogą resetować ASP.NET uwierzytelnianie formularzy i stan wyświetlania, jeśli aplikacja jest od nich zależna. Aby zapobiec automatycznemu ponownemu generowaniu kluczy, ustaw je ręcznie jako ustawienia aplikacji usługi App Service.

Połączenie do kontenera

Możesz połączyć się z kontenerem systemu Windows bezpośrednio w celu wykonywania zadań diagnostycznych, przechodząc do https://<app-name>.scm.azurewebsites.net/ i wybierając opcję SSH. Ustanowiono bezpośrednią sesję SSH z kontenerem, w której można uruchamiać polecenia wewnątrz kontenera.

  • Działa on oddzielnie od przeglądarki graficznej powyżej, która pokazuje tylko pliki w magazynie udostępnionym.
  • W aplikacji skalowanej w poziomie sesja SSH jest połączona z jednym z wystąpień kontenera. Możesz wybrać inne wystąpienie z listy rozwijanej Wystąpienie w górnym menu Kudu.
  • Wszelkie zmiany wprowadzone w kontenerze z poziomu sesji SSH nie są utrwalane po ponownym uruchomieniu aplikacji (z wyjątkiem zmian w magazynie udostępnionym), ponieważ nie jest on częścią obrazu platformy Docker. Aby utrwały zmiany, takie jak ustawienia rejestru i instalacja oprogramowania, wprowadź je w pliku Dockerfile.

Uzyskiwanie dostępu do dzienników diagnostycznych

Usługa App Service rejestruje akcje hosta i działań platformy Docker z poziomu kontenera. Dzienniki z hosta platformy Docker (dzienniki platformy) są domyślnie dostarczane, ale dzienniki aplikacji lub dzienniki serwera internetowego z poziomu kontenera muszą być włączone ręcznie. Aby uzyskać więcej informacji, zobacz Włączanie rejestrowania aplikacji i Włączanie rejestrowania serwera internetowego.

Istnieje kilka sposobów uzyskiwania dostępu do dzienników platformy Docker:

W witrynie Azure Portal

Dzienniki platformy Docker są wyświetlane w portalu na stronie kontenera Ustawienia aplikacji. Dzienniki są obcięte, ale można pobrać wszystkie dzienniki wybierające pozycję Pobierz.

Z kudu

Przejdź do https://<app-name>.scm.azurewebsites.net/DebugConsole folderu LogFiles i wybierz go, aby wyświetlić poszczególne pliki dziennika. Aby pobrać cały katalog LogFiles , wybierz ikonę "Pobierz" po lewej stronie nazwy katalogu. Dostęp do tego folderu można również uzyskać przy użyciu klienta FTP.

W terminalu SSH domyślnie nie można uzyskać dostępu do C:\home\LogFiles folderu, ponieważ trwały magazyn udostępniony nie jest włączony. Aby włączyć to zachowanie w terminalu konsoli, włącz trwały magazyn udostępniony.

Jeśli spróbujesz pobrać dziennik platformy Docker, który jest obecnie używany przy użyciu klienta FTP, może wystąpić błąd z powodu blokady pliku.

Za pomocą interfejsu API Kudu

Przejdź bezpośrednio do witryny , aby wyświetlić https://<app-name>.scm.azurewebsites.net/api/logs/docker metadane dzienników platformy Docker. Może zostać wyświetlonych więcej niż jeden plik dziennika, a href właściwość umożliwia bezpośrednie pobranie pliku dziennika.

Aby pobrać wszystkie dzienniki razem w jednym pliku ZIP, uzyskaj dostęp do pliku https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip.

Dostosowywanie pamięci kontenera

Domyślnie wszystkie kontenery systemu Windows wdrożone w usłudze aplikacja systemu Azure service mają skonfigurowany limit pamięci. W poniższej tabeli wymieniono ustawienia domyślne dla jednostki SKU planu usługi App Service.

Jednostka SKU planu usługi App Service Domyślny limit pamięci na aplikację w MB
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

Tę wartość można zmienić, podając WEBSITE_MEMORY_LIMIT_MB ustawienie aplikacji za pośrednictwem usługi Cloud Shell. W powłoce Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_MEMORY_LIMIT_MB=2000

W programie PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_MEMORY_LIMIT_MB"=2000}

Wartość jest zdefiniowana w MB i musi być mniejsza i równa całkowitej pamięci fizycznej hosta. Na przykład w planie usługi App Service z 8 GB pamięci RAM łączna suma WEBSITE_MEMORY_LIMIT_MB dla wszystkich aplikacji nie może przekraczać 8 GB. Informacje na temat ilości dostępnej pamięci dla każdej warstwy cenowej można znaleźć w cenniku usługi App Service w sekcji Plan usługi Premium w wersji 3.

Dostosowywanie liczby rdzeni obliczeniowych

Domyślnie kontener systemu Windows jest uruchamiany ze wszystkimi dostępnymi rdzeniami dla wybranej warstwy cenowej. Możesz na przykład zmniejszyć liczbę rdzeni używanych przez miejsce przejściowe. Aby zmniejszyć liczbę rdzeni używanych przez kontener, ustaw WEBSITE_CPU_CORES_LIMIT ustawienie aplikacji na preferowaną liczbę rdzeni. Można go ustawić za pośrednictwem usługi Cloud Shell. W powłoce Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --slot staging --settings WEBSITE_CPU_CORES_LIMIT=1

W programie PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_CPU_CORES_LIMIT"=1}

Uwaga

Aktualizowanie ustawienia aplikacji powoduje automatyczne ponowne uruchomienie, co powoduje minimalny przestój. W przypadku aplikacji produkcyjnej rozważ zamianę jej na miejsce przejściowe, zmianę ustawienia aplikacji w miejscu przejściowym, a następnie zamianę go z powrotem na środowisko produkcyjne.

Zweryfikuj skorygowany numer, otwierając sesję SSH z portalu lub za pośrednictwem portalu Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host) i wpisując następujące polecenia przy użyciu programu PowerShell. Każde polecenie zwraca liczbę.

Get-ComputerInfo | ft CsNumberOfLogicalProcessors # Total number of enabled logical processors. Disabled processors are excluded.
Get-ComputerInfo | ft CsNumberOfProcessors # Number of physical processors.

Procesory mogą być procesorami wielordzeniowymi lub hiperwątkowymi. Informacje na temat liczby rdzeni dostępnych dla każdej warstwy cenowej można znaleźć w sekcji Cennik usługi App Service w sekcji Plan usługi Premium v3.

Dostosowywanie zachowania ping kondycji

Usługa App Service uważa, że kontener zostanie pomyślnie uruchomiony po uruchomieniu kontenera i odpowiada na polecenie ping HTTP. Żądanie ping kondycji zawiera nagłówek User-Agent= "App Service Hyper-V Container Availability Check". Jeśli kontener jest uruchamiany, ale nie odpowiada na polecenia ping po upływie określonego czasu, usługa App Service rejestruje zdarzenie w dzienniku platformy Docker, mówiąc, że kontener nie został uruchomiony.

Jeśli aplikacja intensywnie korzysta z zasobów, kontener może nie odpowiadać na polecenie ping HTTP w czasie. Aby kontrolować akcje, gdy polecenia ping HTTP kończą się niepowodzeniem, ustaw CONTAINER_AVAILABILITY_CHECK_MODE ustawienie aplikacji. Można go ustawić za pośrednictwem usługi Cloud Shell. W powłoce Bash:

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings CONTAINER_AVAILABILITY_CHECK_MODE="ReportOnly"

W programie PowerShell:

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"CONTAINER_AVAILABILITY_CHECK_MODE"="ReportOnly"}

W poniższej tabeli przedstawiono możliwe wartości:

Wartość Opisy
Naprawy Uruchom ponownie kontener po trzech kolejnych testach dostępności
RaportOnly Wartość domyślna. Nie uruchamiaj ponownie kontenera, ale raport w dziennikach platformy Docker dla kontenera po trzech kolejnych testach dostępności.
Wył. Nie sprawdzaj dostępności.

Obsługa kont usług zarządzanych przez grupę

Konta usług zarządzane przez grupę (gMSA) nie są obecnie obsługiwane w kontenerach systemu Windows w usłudze App Service.

Włączanie protokołu SSH

Protokół Secure Shell (SSH) jest często używany do wykonywania poleceń administracyjnych zdalnie z poziomu terminalu wiersza polecenia. Aby włączyć funkcję konsoli SSH w witrynie Azure Portal z kontenerami niestandardowymi, wymagane są następujące kroki:

  1. Utwórz standardowy sshd_config plik z następującą przykładową zawartością i umieść go w katalogu głównym projektu aplikacji:

    Port 			2222
ListenAddress 		0.0.0.0
LoginGraceTime 		180
X11Forwarding 		yes
Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1,hmac-sha1-96
StrictModes 		yes
SyslogFacility 		DAEMON
PasswordAuthentication 	yes
PermitEmptyPasswords 	no
PermitRootLogin 	yes
Subsystem sftp internal-sftp

    Uwaga

    Ten plik konfiguruje protokół OpenSSH i musi zawierać następujące elementy, aby zapewnić zgodność z funkcją SSH w witrynie Azure Portal:

    • Port musi mieć ustawioną wartość 2222.
    • Element Ciphers musi zawierać co najmniej jeden element z tej listy: aes128-cbc,3des-cbc,aes256-cbc.
    • Element MACs musi zawierać co najmniej jeden element z tej listy: hmac-sha1,hmac-sha1-96.

  2. Utwórz skrypt punktu wejścia o nazwie entrypoint.sh (lub zmień dowolny istniejący plik punktu wejścia) i dodaj polecenie , aby uruchomić usługę SSH, wraz z poleceniem uruchamiania aplikacji. W poniższym przykładzie pokazano uruchamianie aplikacji w języku Python. Zastąp ostatnie polecenie zgodnie z językiem/stosem projektu:

    #!/bin/sh
set -e
service ssh start
exec gunicorn -w 4 -b 0.0.0.0:8000 app:app

  3. Dodaj do pliku Dockerfile następujące instrukcje zgodnie z rozkładem obrazu podstawowego. Te instrukcje kopiują nowe pliki, instaluj serwer OpenSSH, ustawiają odpowiednie uprawnienia i konfigurują niestandardowy punkt wejścia oraz uwidaczniają porty wymagane odpowiednio przez aplikację i serwer SSH:

    COPY entrypoint.sh ./

# Start and enable SSH
RUN apt-get update \
    && apt-get install -y --no-install-recommends dialog \
    && apt-get install -y --no-install-recommends openssh-server \
    && echo "root:Docker!" | chpasswd \
    && chmod u+x ./entrypoint.sh
COPY sshd_config /etc/ssh/

EXPOSE 8000 2222

ENTRYPOINT [ "./entrypoint.sh" ]

    Uwaga

    Hasło główne musi być dokładnie tak Docker! samo, jak używane przez usługę App Service, aby umożliwić dostęp do sesji SSH z kontenerem. Ta konfiguracja nie zezwala na połączenia zewnętrzne z kontenerem. Port 2222 kontenera jest dostępny tylko w sieci mostka prywatnej sieci wirtualnej i nie jest dostępny dla osoby atakującej w Internecie.

  4. Ponownie skompiluj i wypchnij obraz platformy Docker do rejestru, a następnie przetestuj funkcję SSH aplikacji internetowej w witrynie Azure Portal.

Dalsze informacje dotyczące rozwiązywania problemów są dostępne na blogu usługi aplikacja systemu Azure: Włączanie protokołu SSH w usłudze Linux Web App for Containers

Uzyskiwanie dostępu do dzienników diagnostycznych

Dostęp do dzienników konsoli wygenerowanych z poziomu kontenera można uzyskać.

Najpierw włącz rejestrowanie kontenerów, uruchamiając następujące polecenie:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Zastąp <app-name> wartości i <resource-group-name> nazwami odpowiednimi dla aplikacji internetowej.

Po włączeniu rejestrowania kontenerów uruchom następujące polecenie, aby wyświetlić strumień dziennika:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Jeśli nie widzisz dzienników konsoli, sprawdź ponownie w ciągu 30 sekund.

Aby zatrzymać przesyłanie strumieniowe dzienników w dowolnym momencie, wpisz Ctrl+C.

Możesz również sprawdzić pliki dziennika w przeglądarce pod adresem https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Konfigurowanie aplikacji wielokontenerowych

Używanie magazynu trwałego w narzędziu Docker Compose

Aplikacje wielokontenerowe, takie jak WordPress, wymagają trwałego magazynu, aby działały prawidłowo. Aby ją włączyć, konfiguracja narzędzia Docker Compose musi wskazywać lokalizację magazynu poza kontenerem. Lokalizacje magazynu wewnątrz kontenera nie utrwalają zmian poza ponownym uruchomieniem aplikacji.

Włącz magazyn trwały, ustawiając WEBSITES_ENABLE_APP_SERVICE_STORAGE ustawienie aplikacji przy użyciu polecenia az webapp config appsettings set w usłudze Cloud Shell.

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE

W pliku docker-compose.yml zamapuj volumes opcję na ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME to zmienna środowiskowa w usłudze App Service mapowana na magazyn trwały aplikacji. Na przykład:

wordpress:
  image: <image name:tag>
  volumes:
  - "${WEBAPP_STORAGE_HOME}/site/wwwroot:/var/www/html"
  - "${WEBAPP_STORAGE_HOME}/phpmyadmin:/var/www/phpmyadmin"
  - "${WEBAPP_STORAGE_HOME}/LogFiles:/var/log"

Ograniczenia wersji zapoznawczej

Wiele kontenerów jest obecnie w wersji zapoznawczej. Następujące funkcje platformy usługi App Service nie są obsługiwane:

  • Uwierzytelnianie/autoryzacja
  • Tożsamości zarządzane
  • CORS
  • Integracja sieci wirtualnej nie jest obsługiwana w scenariuszach narzędzia Docker Compose
  • Docker Compose w usługach aplikacja systemu Azure obecnie ma limit 4000 znaków.

Opcje narzędzia Docker Compose

Na poniższych listach przedstawiono obsługiwane i nieobsługiwane opcje konfiguracji narzędzia Docker Compose:

Obsługiwane opcje

  • polecenie
  • entrypoint
  • Środowisko usługi
  • obraz
  • ports
  • restart
  • services
  • woluminy (mapowanie na usługę Azure Storage nie jest obsługiwane)

Nieobsługiwane opcje

  • build (niedozwolona)
  • depends_on (ignorowane)
  • networks (ignorowana)
  • secrets (ignorowana)
  • porty inne niż 80 i 8080 (ignorowane)
  • domyślne zmienne środowiskowe, takie jak $variable and ${variable} w przeciwieństwie do platformy Docker

Ograniczenia składni

  • "version x.x" zawsze musi być pierwszą instrukcją YAML w pliku
  • sekcja portów musi używać liczb cytowanych
  • Sekcja woluminu obrazu > musi być cytowana i nie może mieć definicji uprawnień
  • sekcja woluminów nie może mieć pustego nawiasu klamrowego po nazwie woluminu

Uwaga

Wszystkie inne opcje, które nie są jawnie wywoływane, są ignorowane w publicznej wersji zapoznawczej.

robots933456 w dziennikach

W dziennikach kontenera może zostać wyświetlony następujący komunikat:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Możesz bezpiecznie zignorować ten komunikat. /robots933456.txt jest fikcyjną ścieżką adresu URL, za pomocą której usługa App Service sprawdza, czy kontener jest w stanie obsługiwać żądania. Odpowiedź 404 oznacza po prostu, że ścieżka nie istnieje, ale pozwala usłudze App Service sprawdzić, czy kontener jest w dobrej kondycji i jest gotowy do reagowania na żądania.

Następne kroki

Samouczek: migrowanie oprogramowania niestandardowego do usługi aplikacja systemu Azure przy użyciu kontenera niestandardowego

Samouczek: aplikacja WordPress z wieloma kontenerami

Lub zobacz więcej zasobów: