Udostępnij za pośrednictwem

Konfigurowanie niestandardowego kontenera dla usługi Azure App Service

W tym artykule przedstawiono sposób konfigurowania niestandardowego kontenera na Azure App 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 Azure App Service powinni najpierw postępować zgodnie z przewodnikiem Szybki start kontenera niestandardowego i samouczkiem.

Ten przewodnik zawiera kluczowe pojęcia i instrukcje dotyczące konteneryzacji aplikacji systemu Linux w usłudze App Service. Jeśli dopiero zaczynasz korzystać z usługi Azure App Service, najpierw postępuj zgodnie z przewodnikiem Szybki start i samouczkiem dotyczącym kontenera niestandardowego. Aby zapoznać się z kontenerami dodatkowymi, sprawdź Samouczek: konfigurowanie kontenera dodatkowego dla kontenera niestandardowego w Azure App Service.

Uwaga

Podmiot usługi nie jest już obsługiwany w przypadku uwierzytelniania podczas pobierania obrazów kontenerów Windows. Zalecamy używanie 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 wybierz odpowiedni obraz nadrzędny (obraz podstawowy) dla frameworku, który chcesz używać:

  • Aby wdrożyć aplikacje .NET Framework, użyj obrazu nadrzędnego opartego na systemie Windows Server 2019 Core z wersją Long-Term Servicing Channel (LTSC).
  • Aby wdrożyć aplikacje platformy .NET Core, użyj obrazu nadrzędnego opartego na wersji systemu Windows Server 2019 Nano Annual Channel (AC).

Pobranie obrazu nadrzędnego może zająć trochę czasu podczas uruchamiania aplikacji. Czas uruchamiania można skrócić przy użyciu jednego z następujących obrazów nadrzędnych, które są już buforowane w usłudze Azure App Service:

Zmiana obrazu Docker niestandardowego kontenera

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żyj 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 < i > 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 pobierania z Azure Container Registry (ACR) przy użyciu tożsamości zarządzanej. W krokach jest używana tożsamość zarządzana przypisana przez system. Zamiast tego można 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 polecenia az webapp identity assign :

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

    Zastąp <app-name> nazwą używaną w poprzednim kroku. Dane wyjściowe polecenia, filtrowane według argumentów --query i --output, to identyfikator usługi głównej 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 przez argumenty --query 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 wykorzystaniem identyfikatora głównej usługi z az webapp identity assign polecenia
    • <registry-resource-id> z identyfikatorem twojego rejestru kontenerów z polecenia az acr show

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

  4. Skonfiguruj swoją aplikację, aby korzystała z zarządzanej tożsamości do pobierania z 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:

    • <nazwa aplikacji> twojej aplikacji internetowej.

    Wskazówka

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

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

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

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

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

Wszystko jest gotowe! Aplikacja internetowa używa teraz tożsamości zarządzanej do pobierania z rejestru Azure Container Registry.

Używanie obrazu z rejestru chronionego przez sieć

Aby nawiązać połączenie i ściągnąć rejestr w sieci wirtualnej lub w sieci lokalnej, aplikacja musi zostać zintegrowana z siecią wirtualną. Potrzebna jest również integracja sieci wirtualnej dla usługi Azure Container Registry z prywatnym punktem końcowym. Po skonfigurowaniu sieci i rozpoznawania nazw DNS, włącz routing pobierania obrazu przez sieć wirtualną, konfigurując ustawienie witryny 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 jest uruchamiana ponownie, usługa App Service wykonuje polecenie docker pull. Ściąga tylko zmienione warstwy. 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. Analogicznie jest w przypadku skalowania poziomego 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 twój 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 ją ustawić przy użyciu 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żna je przekazać przy użyciu 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_URL, DOCKER_REGISTRY_SERVER_USERNAMEi DOCKER_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 środowisku IIS lub .NET Framework (4.0 lub nowszych) poświadczenia są automatycznie wstrzykiwane przez usługę App Service do System.ConfigurationManager jako ustawienia aplikacji .NET oraz ciągi połączenia. Dla wszystkich innych języków lub struktur są one udostępniane jako zmienne środowiskowe dla procesu z jednym z następujących 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żyj trwałego współdzielonego magazynu

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, operacje zapisu w katalogu C:\home nie są utrwalane podczas ponownego uruchamiania aplikacji ani w wielu wystąpieniach. Po włączeniu magazynu trwałego wszystkie operacje zapisu w katalogu C:\home są utrwalane. Wszystkie wystąpienia skalowanej aplikacji horyzontalnie mogą uzyskiwać do nich dostęp. Istniejące pliki znajdujące się już w magazynie trwałym, gdy kontener się uruchamia, nadpisują wszelką zawartość w katalogu C:\home kontenera.

Jedynym wyjątkiem jest katalog C:\home\LogFiles . Ten katalog przechowuje dzienniki kontenera i aplikacji. Ten folder zawsze pozostaje po ponownym uruchomieniu aplikacji, jeśli rejestrowanie aplikacji jest włączone z opcją systemu plików, niezależnie od tego, czy magazyn trwały jest włączony. Innymi słowy, włączenie lub wyłączenie magazynu trwałego nie ma wpływu na prowadzenie logów aplikacji.

Domyślnie w systemie Windows magazyn trwały jest włączony w kontenerach niestandardowych. Aby ją wyłączyć, ustaw WEBSITES_ENABLE_APP_SERVICE_STORAGE wartość ustawienia aplikacji na false przy użyciu 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}

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, aby umożliwić dostęp kontenera niestandardowego do pamięci trwałej. Zapisywanie danych w /home przyczynia się do limitu przydziału miejsca do magazynowania uwzględnionego w planie usługi App Service.

Gdy pamięć trwała jest wyłączona, operacje zapisu w katalogu /home nie są zachowywane ani podczas ponownego uruchamiania aplikacji, ani między wieloma instancjami. Gdy magazyn trwały jest włączony, wszystkie operacje zapisu w katalogu /home są utrwalane. Wszystkie wystąpienia skalowanej aplikacji horyzontalnie mogą uzyskiwać do nich dostęp. Pliki, które już znajdują się w magazynie trwałym przy uruchomieniu kontenera, nadpisują wszelką zawartość w katalogu /home kontenera.

Jedynym wyjątkiem jest katalog /home/LogFiles . Ten katalog przechowuje dzienniki kontenera i aplikacji. Ten folder zawsze pozostaje po ponownym uruchomieniu aplikacji, jeśli rejestrowanie aplikacji jest włączone z opcją systemu plików, niezależnie od tego, czy magazyn trwały jest włączony. Innymi słowy, włączenie lub wyłączenie magazynu trwałego nie ma wpływu na prowadzenie logów aplikacji.

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

Domyślnie magazyn trwały jest wyłączony w kontenerach niestandardowych systemu Linux. Aby ją włączyć, ustaw WEBSITES_ENABLE_APP_SERVICE_STORAGE wartość ustawienia aplikacji na true przy użyciu 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}

Uwaga

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

Wykrywanie sesji protokołu HTTPS

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

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

Dostosowywanie iniekcji klucza maszyny ASP.NET

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

Przy każdym ponownym uruchomieniu nowe klucze mogą resetować uwierzytelnianie formularzy i stan widoku ASP.NET, 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.

Nawiązywanie połączenia z kontenerem

Aby połączyć się z kontenerem systemu Windows bezpośrednio w celu wykonywania zadań diagnostycznych, przejdź do https://<app-name>.scm.azurewebsites.net/ i wybierz opcję SSH. Ta opcja ustanawia bezpośrednią sesję SSH, 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 rozszerzonej aplikacji sesja SSH jest połączona z jednym z kontenerów. Możesz wybrać inne wystąpienie z listy rozwijanej Wystąpienie w górnym menu Kudu.
  • Z wyjątkiem zmian w magazynie udostępnionym wszelkie zmiany wprowadzone w kontenerze z poziomu sesji SSH nie są utrwalane po ponownym uruchomieniu aplikacji. Takie zmiany nie są częścią obrazu platformy Docker. Aby zapisać zmiany, takie jak ustawienia rejestru i instalację oprogramowania, umieść je w 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 włączone. Należy ręcznie włączyć dzienniki aplikacji lub dzienniki serwera internetowego z poziomu kontenera. 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 witrynie Azure Portal na stronie Ustawienia kontenera aplikacji. Dzienniki są skrócone. Aby pobrać wszystkie dzienniki, wybierz pozycję Pobierz.

Z kudu

Aby wyświetlić poszczególne pliki dziennika, przejdź do https://<app-name>.scm.azurewebsites.net/DebugConsole folderu LogFiles i wybierz go. 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 folderu C:\home\LogFiles , ponieważ trwały magazyn udostępniony nie jest włączony. Aby włączyć to zachowanie w terminalu konsoli, włącz trwały wspólny magazyn.

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 https://<app-name>.scm.azurewebsites.net/api/logs/docker, aby wyświetlić metadane dzienników platformy Docker. Może zostać wyświetlonych więcej niż jeden plik dziennika. Właściwość href 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 Azure App Service mają skonfigurowany limit pamięci. Poniższa tabela przedstawia domyślne ustawienia dla 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 przy użyciu 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. Aby uzyskać więcej informacji na temat ilości dostępnej pamięci, zobacz sekcję Plan usługi Premium w wersji 3 w cenniku usługi App Service.

Dostosowywanie liczby rdzeni obliczeniowych

Domyślnie kontener systemu Windows jest uruchamiany ze wszystkimi dostępnymi rdzeniami dla wybranej warstwy cenowej. Możesz chcieć zmniejszyć liczbę rdzeni używanych przez przestrzeń stagingową. Aby zmniejszyć liczbę rdzeni używanych przez kontener, ustaw WEBSITE_CPU_CORES_LIMIT ustawienie aplikacji na preferowaną liczbę rdzeni. Można ją ustawić przy użyciu 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}

Wskazówka

Aktualizowanie ustawienia aplikacji wyzwala automatyczne ponowne uruchamianie, co powoduje minimalny przestój. W przypadku aplikacji produkcyjnej rozważ zamienienie jej do gniazda przejściowego, zmianę ustawienia aplikacji w gnieździe przejściowym, a następnie przywrócenie jej do środowiska produkcyjnego.

Aby zweryfikować skorygowany numer, otwórz sesję SSH w witrynie Azure Portal lub użyj portalu Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host). Wprowadź 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 dostępnych rdzeni można znaleźć w sekcji Plan usługi Premium w wersji 3 w cenniku usługi App Service.

Dostosuj zachowanie pingu zdrowotnego

Usługa App Service uznaje kontener za pomyślnie uruchomiony, gdy kontener zostanie uruchomiony i odpowie na żądanie ping HTTP. Żądanie ping kondycji zawiera nagłówek User-Agent= "App Service Hyper-V Container Availability Check". Jeśli kontener zostanie uruchomiony, ale nie odpowiada na żądania ping po upływie określonego czasu, usługa App Service zapisuje zdarzenie w logu Dockera.

Jeśli aplikacja intensywnie zużywa zasoby, kontener może nie odpowiadać na ping HTTP w czasie. Aby kontrolować działania, gdy polecenia ping HTTP kończą się niepowodzeniem, skonfiguruj ustawienie aplikacji CONTAINER_AVAILABILITY_CHECK_MODE. Można ją ustawić przy użyciu 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
Naprawa Uruchom ponownie kontener po trzech kolejnych testach dostępności.
RaportOnly Wartość domyślna. Nie uruchamiaj ponownie kontenera, ale zapisz informacje w dzienniku Dockera po trzech kolejnych sprawdzeniach dostępności.
Wyłączone 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 zdalnego uruchamiania poleceń administracyjnych z poziomu terminalu wiersza polecenia. Aby włączyć funkcję konsoli SSH w portalu Azure dla kontenerów niestandardowych, wykonaj 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. 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 Docker!, ponieważ jest używane przez usługę App Service, aby umożliwić Ci 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. Odbuduj i wypchnij obraz Docker do rejestru, a następnie przetestuj funkcję SSH aplikacji internetowej w portalu Azure.

Aby uzyskać więcej informacji na temat rozwiązywania problemów, zobacz blog usługi Azure App Service: Włączanie protokołu SSH w usłudze Linux Web App for Containers

Uzyskiwanie dostępu do dzienników diagnostycznych

Można uzyskać dostęp do dzienników konsoli generowanych wewnątrz kontenera.

Aby włączyć rejestrowanie kontenerów, uruchom następujące polecenie:

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

Zastąp <app-name> i <resource-group-name> nazwami odpowiednimi dla swojej 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 dzienniki konsoli nie są wyświetlane natychmiast, sprawdź ponownie w ciągu 30 sekund.

Aby zatrzymać strumieniowanie logów w dowolnym momencie, naciśnij Ctrl+C.

Konfigurowanie aplikacji wielokontenerowych

Uwaga

Funkcja Docker Compose zostanie wycofana 31 marca 2027 r. Kontenery sidecar zastępują aplikacje wielokontenerowe w usłudze App Service. Dla nowych usług, odwołaj się do Samouczek: konfigurowanie kontenera bocznego dla kontenera niestandardowego w usłudze Azure App Service. W przypadku istniejących aplikacji wielokontenerowych w usłudze App Service zobacz Migrowanie aplikacji Docker Compose do funkcji sidecar.

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. Miejsca przechowywania wewnątrz kontenera nie utrwalają zmian po ponownym uruchomieniu aplikacji.

Aby włączyć magazyn trwały, skonfiguruj ustawienie aplikacji WEBSITES_ENABLE_APP_SERVICE_STORAGE. Użyj polecenia az webapp config appsettings set w 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, która jest mapowana na trwały magazyn danych dla 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 testowej. Następujące funkcje platformy usługi App Service nie są obsługiwane:

  • Uwierzytelnianie/autoryzacja
  • System zarządzania tożsamościami
  • CORS (Cross-Origin Resource Sharing)
  • Integracja sieci wirtualnej nie jest obsługiwana w scenariuszach narzędzia Docker Compose.
  • Docker Compose w usługach aplikacji Azure obecnie ma limit 4.000 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
  • punkt wejścia
  • Środowisko
  • obraz
  • porty
  • zrestartować
  • usługi
  • woluminy (mapowanie do Azure Storage nie jest obsługiwane)

Nieobsługiwane opcje

  • kompilacja (niedozwolona)
  • zależy_od (ignorowane)
  • sieci (zignorowane)
  • sekrety (ignorowana)
  • porty inne niż 80 i 8080 (ignorowane)
  • domyślne zmienne środowiskowe, takie jak $variable and ${variable}, w przeciwieństwie do dockera

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 powinna zawierać pustego nawiasu klamrowego za nazwą woluminu

Uwaga

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

Ignoruj komunikat robots933456 w logach

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 wskazuje, że ścieżka nie istnieje i sygnalizuje usłudze App Service, że kontener jest w dobrej kondycji i gotowy do odpowiadania na żądania.

Powiązana zawartość

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

Samouczek: konfigurowanie kontenera pomocniczego dla kontenera niestandardowego w usłudze App Service platformy Azure

Lub zobacz więcej zasobów: