Sdílet prostřednictvím

Konfigurace vlastního kontejneru pro službu Azure App Service

  • Článek

V tomto článku se dozvíte, jak nakonfigurovat vlastní kontejner pro spuštění ve službě Aplikace Azure Service.

Tato příručka obsahuje klíčové koncepty a pokyny pro kontejnerizaci aplikací pro Windows ve službě App Service. Uživatelé nové služby Aplikace Azure by měli nejprve postupovat podle vlastního rychlého startu a kurzu kontejneru.

Tato příručka obsahuje klíčové koncepty a pokyny pro kontejnerizaci linuxových aplikací ve službě App Service. Pokud s Aplikace Azure Service teprve začínáte, nejprve postupujte podle vlastního rychlého startu a kurzu kontejneru. Informace o kontejnerech sajdkár (Preview) najdete v tématu Kurz: Konfigurace kontejneru sajdkáře pro vlastní kontejner ve službě Aplikace Azure Service (Preview).

Poznámka:

Instanční objekt se už nepodporuje pro ověřování vyžádání image kontejneru Windows. Doporučeným způsobem je použít spravovanou identitu pro kontejnery Windows i Linux.

Podporované nadřazené obrázky

Pro vlastní image Windows musíte zvolit správnou nadřazenou image (základní image) pro požadovanou architekturu:

  • Pokud chcete nasadit aplikace rozhraní .NET Framework, použijte nadřazenou image založenou na vydání kanálu dlouhodobé údržby jádra Windows Serveru 2019 (LTSC).
  • Pokud chcete nasadit aplikace .NET Core, použijte nadřazenou image založenou na verzi půlročního kanálu údržby Windows Serveru 2019 Nano (SAC).

Stažení nadřazené image při spuštění aplikace nějakou dobu trvá. Čas spuštění však můžete zkrátit použitím některé z následujících nadřazených imagí, které jsou již uložené v mezipaměti ve službě 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

Změna image Dockeru vlastního kontejneru

Pokud chcete změnit existující vlastní kontejner z aktuální image Dockeru na novou image, použijte následující příkaz:

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

Použití image z privátního registru

Pokud chcete použít image z privátního registru, jako je Azure Container Registry, spusťte následující příkaz:

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>

Pro uživatelské jméno> a< heslo> zadejte přihlašovací údaje pro váš privátní účet registru.<

Použití spravované identity k načtení image ze služby Azure Container Registry

Pomocí následujících kroků nakonfigurujte webovou aplikaci tak, aby načítá data ze služby Azure Container Registry (ACR) pomocí spravované identity. Kroky používají spravovanou identitu přiřazenou systémem, ale můžete také použít spravovanou identitu přiřazenou uživatelem.

  1. Pomocí příkazu povolte spravovanou identitu přiřazenou systémem pro webovou aplikaci az webapp identity assign :

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

    Nahraďte <app-name> názvem, který jste použili v předchozím kroku. Výstupem příkazu (filtrovaného podle --query argumentů a --output argumentů) je ID instančního objektu přiřazené identity.

  2. Získejte ID prostředku služby Azure Container Registry:

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

    <registry-name> nahraďte názvem vašeho registru. Výstupem příkazu (filtrovaného podle --query argumentů a --output argumentů) je ID prostředku služby Azure Container Registry.

  3. Udělte spravované identitě oprávnění pro přístup k registru kontejneru:

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

    Nahraďte následující hodnoty:

    • <principal-id> s ID instančního objektu az webapp identity assign z příkazu
    • <registry-resource-id> s ID vašeho registru kontejneru az acr show z příkazu

    Další informace o těchto oprávněních najdete v tématu Co je řízení přístupu na základě role v Azure.

  4. Nakonfigurujte aplikaci tak, aby používala spravovanou identitu k načtení ze služby Azure Container Registry.

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

    Nahraďte následující hodnoty:

    • <app-name> s názvem vaší webové aplikace.

    Tip

    Pokud ke spuštění příkazů používáte konzolu PowerShellu, musíte utéct řetězce v argumentu --generic-configurations v tomto a dalším kroku. Příklad: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (Volitelné) Pokud vaše aplikace používá spravovanou identitu přiřazenou uživatelem, ujistěte se, že je ve webové aplikaci nakonfigurovaná identita, a pak nastavte acrUserManagedIdentityID vlastnost tak, aby určila ID klienta:

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

    <identity-name> Nahraďte spravovanou identitu přiřazenou uživatelem a pomocí výstupu <client-id> nakonfigurujte ID spravované identity přiřazené uživatelem.

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

Všechno je nastavené a webová aplikace teď používá spravovanou identitu k načtení ze služby Azure Container Registry.

Použití image z registru chráněného sítí

Pokud se chcete připojit a načíst z registru uvnitř virtuální sítě nebo v místním prostředí, musí se vaše aplikace integrovat s virtuální sítí. Integrace virtuální sítě je nutná také pro Službu Azure Container Registry s privátním koncovým bodem. Po nakonfigurování sítě a překladu DNS povolíte směrování image vyžádané replikace virtuální sítí tak, že nakonfigurujete vnetImagePullEnabled nastavení lokality:

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

Aktualizovaný kontejner se nezobrazuje

Pokud změníte nastavení kontejneru Dockeru tak, aby odkazovali na nový kontejner, může to trvat několik minut, než aplikace obsluhuje požadavky HTTP z nového kontejneru. Zatímco se nový kontejner načítá a spouští, služba App Service nadále obsluhuje požadavky ze starého kontejneru. Až se nový kontejner spustí a připraví k příjmu požadavků, služba App Service do něj začne odesílat žádosti.

Způsob ukládání imagí kontejnerů

Při prvním spuštění vlastní image Dockeru ve službě App Service služba App Service provede docker pull a načte všechny vrstvy imagí. Tyto vrstvy se ukládají na disk, jako kdybyste používali Docker v místním prostředí. Pokaždé, když se aplikace restartuje, app Service provede , docker pullale načte pouze vrstvy, které se změnily. Pokud nedojde k žádným změnám, služba App Service používá existující vrstvy na místním disku.

Pokud aplikace z nějakého důvodu změní výpočetní instance, jako je vertikální navýšení nebo snížení cenových úrovní, služba App Service musí znovu stáhnout všechny vrstvy. Totéž platí i v případě, že horizontální navýšení kapacity na více instancí přidáte. Existují také vzácné případy, kdy se instance aplikací můžou změnit bez operace škálování.

Konfigurace čísla portu

Služba App Service ve výchozím nastavení předpokládá, že váš vlastní kontejner naslouchá na portu 80. Pokud váš kontejner naslouchá jinému portu, nastavte WEBSITES_PORT v aplikaci App Service nastavení aplikace. Můžete ho nastavit přes Cloud Shell. V Bash:

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

V PowerShellu:

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

App Service v současné době umožňuje kontejneru zveřejnit pouze jeden port pro požadavky HTTP.

Konfigurace proměnných prostředí

Váš vlastní kontejner může používat proměnné prostředí, které je potřeba zadat externě. Můžete je předat přes Cloud Shell. V Bash:

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

V PowerShellu:

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

Po spuštění aplikace se nastavení aplikace služby App Service vloží do procesu jako proměnné prostředí automaticky. Proměnné prostředí kontejneru můžete ověřit pomocí adresy URL https://<app-name>.scm.azurewebsites.net/Env.

Pokud vaše aplikace používá image z privátního registru nebo z Docker Hubu, přihlašovací údaje pro přístup k úložišti se ukládají do proměnných prostředí: DOCKER_REGISTRY_SERVER_URLDOCKER_REGISTRY_SERVER_USERNAME a DOCKER_REGISTRY_SERVER_PASSWORD. Kvůli rizikům zabezpečení se žádné z těchto názvů rezervovaných proměnných nedají aplikaci vystavit.

Pro kontejnery založené na službě IIS nebo .NET Framework (4.0 nebo novější) se vloží jako System.ConfigurationManager nastavení aplikace .NET a připojovací řetězec automaticky službou App Service. Pro všechny ostatní jazyky nebo architekturu jsou pro tento proces poskytovány jako proměnné prostředí s jednou z následujících odpovídajících předpon:

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

Tato metoda funguje jak pro jednokontejnerové aplikace, tak pro vícekontejnerové aplikace, kde jsou proměnné prostředí zadané v souboru docker-compose.yml .

Použití trvalého sdíleného úložiště

Pomocí adresáře C:\home v systému souborů vlastního kontejneru můžete zachovat soubory napříč restartováními a sdílet je napříč instancemi. Adresář C:\home je k dispozici, aby váš vlastní kontejner mohl přistupovat k trvalému úložišti.

Pokud je trvalé úložiště zakázané, nebudou C:\home se zápisy do adresáře uchovávat napříč restartováními aplikace nebo napříč několika instancemi. Pokud je povolené trvalé úložiště, všechny zápisy do C:\home adresáře se zachovají a můžou k němu přistupovat všechny instance aplikace se škálováním na více systémů. Kromě toho se veškerý obsah v C:\home adresáři kontejneru přepíše všemi existujícími soubory, které již existují v trvalém úložišti při spuštění kontejneru.

Jedinou výjimkou je C:\home\LogFiles adresář, který slouží k ukládání protokolů kontejneru a aplikace. Tato složka se vždy zachová při restartování aplikace, pokud je povolené protokolování aplikace s možností Systém souborů, nezávisle na povoleném nebo zakázaném trvalém úložišti. Jinými slovy, povolení nebo zakázání trvalého úložiště nemá vliv na chování protokolování aplikace.

Ve výchozím nastavení je pro vlastní kontejnery Windows povolené trvalé úložiště. Pokud ho WEBSITES_ENABLE_APP_SERVICE_STORAGE chcete zakázat, nastavte hodnotu nastavení aplikace přes false Cloud Shell. V Bash:

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

V PowerShellu:

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

Pomocí adresáře /home ve vlastním systému souborů kontejneru můžete zachovat soubory po restartování a sdílet je mezi instancemi. Adresář /home je k dispozici, aby váš vlastní kontejner mohl přistupovat k trvalému úložišti. Ukládání dat v rámci /home přispívá k kvótě prostoru úložiště zahrnuté v plánu služby App Service.

Pokud je trvalé úložiště zakázané, nebudou /home se zápisy do adresáře uchovávat napříč restartováními aplikace nebo napříč několika instancemi. Pokud je povolené trvalé úložiště, všechny zápisy do /home adresáře se zachovají a můžou k němu přistupovat všechny instance aplikace se škálováním na více systémů. Kromě toho se veškerý obsah v /home adresáři kontejneru přepíše všemi existujícími soubory, které již existují v trvalém úložišti při spuštění kontejneru.

Jedinou výjimkou je /home/LogFiles adresář, který slouží k ukládání protokolů kontejneru a aplikace. Tato složka se vždy zachová při restartování aplikace, pokud je povolené protokolování aplikace s možností Systém souborů, nezávisle na povoleném nebo zakázaném trvalém úložišti. Jinými slovy, povolení nebo zakázání trvalého úložiště nemá vliv na chování protokolování aplikace.

Doporučuje se zapisovat data do připojené cesty úložiště Azure nebo do /home ní. Data zapsaná mimo tyto cesty nejsou během restartování trvalá a ukládají se do místa na disku hostitele spravovaném platformou odděleně od kvóty úložiště souborů Plánů služby App Service.

Ve výchozím nastavení je trvalé úložiště ve vlastních kontejnerech Linuxu zakázané . Pokud ji chcete povolit, nastavte WEBSITES_ENABLE_APP_SERVICE_STORAGE hodnotu nastavení aplikace přes true Cloud Shell. V Bash:

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

V PowerShellu:

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

Poznámka:

Můžete také nakonfigurovat vlastní trvalé úložiště.

Zjištění relace HTTPS

Služba App Service ukončí protokol TLS/SSL na front-endech. To znamená, že se požadavky TLS/SSL nikdy nedostanou do vaší aplikace. Nemusíte a neměli byste do aplikace implementovat žádnou podporu protokolu TLS/SSL.

Front-endy se nacházejí uvnitř datových center Azure. Pokud ve své aplikaci používáte protokol TLS/SSL, provoz přes internet se vždy bezpečně zašifruje.

Přizpůsobení injektáže klíče počítače ASP.NET

Během spuštění kontejneru se automaticky vygenerované klíče vloží do kontejneru jako klíče počítače pro ASP.NET kryptografických rutin. Tyto klíče najdete v kontejneru vyhledáním následujících proměnných prostředí: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey. MACHINEKEY_Validation

Nové klíče v každém restartování můžou resetovat ASP.NET ověřování pomocí formulářů a zobrazit stav, pokud na nich vaše aplikace závisí. Pokud chcete zabránit automatickému regeneraci klíčů, nastavte je ručně jako nastavení aplikace služby App Service.

Připojení ke kontejneru

Ke svému kontejneru Windows se můžete připojit přímo pro diagnostické úlohy tak, že přejdete na https://<app-name>.scm.azurewebsites.net/ možnost SSH a zvolíte ji. Navazuje se přímá relace SSH s kontejnerem, ve které můžete spouštět příkazy uvnitř kontejneru.

  • Funguje odděleně od grafického prohlížeče nad ním, který zobrazuje jenom soubory ve sdíleném úložišti.
  • V aplikaci se škálováním na více instancí je relace SSH připojená k jedné z instancí kontejneru. V horní nabídce Kudu můžete vybrat jinou instanci z rozevíracího seznamu Instance .
  • Všechny změny provedené v kontejneru z relace SSH se při restartování aplikace neuchovávají (s výjimkou změn ve sdíleném úložišti), protože není součástí image Dockeru. Pokud chcete zachovat změny, jako je nastavení registru a instalace softwaru, proveďte je jako součást souboru Dockerfile.

Přístup k diagnostickým protokolům

App Service protokoluje akce hostitele a aktivit Dockeru z kontejneru. Protokoly z hostitele Dockeru (protokoly platformy) se ve výchozím nastavení dodávají, ale protokoly aplikací nebo protokoly webového serveru z kontejneru je potřeba povolit ručně. Další informace naleznete v tématu Povolení protokolování aplikace a Povolení protokolování webového serveru.

Přístup k protokolům Dockeru je několik způsobů:

Na webu Azure Portal

Protokoly Dockeru se zobrazují na portálu na stránce Nastavení kontejneru vaší aplikace. Protokoly jsou zkrácené, ale můžete stáhnout všechny protokoly, které vyberete Stáhnout.

Pochází z Kudu

Přejděte do https://<app-name>.scm.azurewebsites.net/DebugConsole složky LogFiles a vyberte ji, abyste viděli jednotlivé soubory protokolů. Pokud chcete stáhnout celý adresář LogFiles , vyberte nalevo od názvu adresáře ikonu Stáhnout . K této složce můžete přistupovat také pomocí klienta FTP.

V terminálu SSH nemáte ve výchozím nastavení přístup ke C:\home\LogFiles složce, protože trvalé sdílené úložiště není povolené. Pokud chcete toto chování povolit v terminálu konzoly, povolte trvalé sdílené úložiště.

Pokud se pokusíte stáhnout protokol Dockeru, který se právě používá pomocí klienta FTP, může se zobrazit chyba kvůli zámku souboru.

S rozhraním Kudu API

Přejděte přímo k https://<app-name>.scm.azurewebsites.net/api/logs/docker zobrazení metadat protokolů Dockeru. Může se zobrazit více než jeden soubor protokolu a href vlastnost umožňuje stáhnout soubor protokolu přímo.

Pokud chcete stáhnout všechny protokoly společně v jednom souboru ZIP, přejděte k https://<app-name>.scm.azurewebsites.net/api/logs/docker/zipsouboru .

Přizpůsobení paměti kontejneru

Ve výchozím nastavení mají všechny kontejnery Windows nasazené ve službě Aplikace Azure Nakonfigurovaný limit paměti. Následující tabulka uvádí výchozí nastavení podle skladové položky plánu služby App Service.

Skladová položka plánu služby App Service Výchozí limit paměti na aplikaci v MB
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

Tuto hodnotu můžete změnit zadáním WEBSITE_MEMORY_LIMIT_MB nastavení aplikace přes Cloud Shell. V Bash:

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

V PowerShellu:

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

Hodnota je definována v MB a musí být menší a rovna celkové fyzické paměti hostitele. Například v plánu služby App Service s 8 GB paměti RAM nesmí kumulativní součet WEBSITE_MEMORY_LIMIT_MB všech aplikací překročit 8 GB. Informace o tom, kolik paměti je k dispozici pro každou cenovou úroveň, najdete v cenách služby App Service v části Plán služby Premium v3.

Přizpůsobení počtu výpočetních jader

Ve výchozím nastavení se kontejner Windows spouští se všemi dostupnými jádry pro zvolenou cenovou úroveň. Můžete například snížit počet jader, které používá přípravný slot. Pokud chcete snížit počet jader používaných kontejnerem, nastavte WEBSITE_CPU_CORES_LIMIT nastavení aplikace na upřednostňovaný počet jader. Můžete ho nastavit přes Cloud Shell. V Bash:

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

V PowerShellu:

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

Poznámka:

Aktualizace nastavení aplikace aktivuje automatické restartování, což způsobuje minimální prostoje. U produkční aplikace zvažte prohození do přípravného slotu, změňte nastavení aplikace v přípravném slotu a pak ho prohoďte zpět do produkčního prostředí.

Ověřte upravené číslo tak, že otevřete relaci SSH z portálu nebo přes portál Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host) a pomocí PowerShellu zadáte následující příkazy. Každý příkaz vypíše číslo.

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

Procesory můžou být vícejádrový nebo hyperthreadingové procesory. Informace o tom, kolik jader je k dispozici pro každou cenovou úroveň, najdete v části s plánem služby Premium v3.

Přizpůsobení chování příkazu ping stavu

Služba App Service považuje kontejner za úspěšně spuštěný při spuštění kontejneru a odpovídá na příkaz ping protokolu HTTP. Požadavek ping na stav obsahuje hlavičku User-Agent= "App Service Hyper-V Container Availability Check". Pokud se kontejner spustí, ale po určité době neodpoví příkazem ping, služba App Service zaznamená událost do protokolu Dockeru a říká, že se kontejner nespusil.

Pokud je vaše aplikace náročná na prostředky, kontejner nemusí včas reagovat na příkaz ping PROTOKOLU HTTP. Pokud chcete řídit akce, když příkazy PING HTTP selžou, nastavte CONTAINER_AVAILABILITY_CHECK_MODE nastavení aplikace. Můžete ho nastavit přes Cloud Shell. V Bash:

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

V PowerShellu:

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

V následující tabulce jsou uvedeny možné hodnoty:

Hodnota Popisy
Opravit Restartujte kontejner po třech po sobě jdoucích kontrolách dostupnosti.
ReportOnly Výchozí hodnota Nerestartujte kontejner, ale po třech po sobě jdoucích kontrolách dostupnosti v protokolech Dockeru pro kontejner.
Vypnuto Nekontrolujte dostupnost.

Podpora skupinových účtů spravované služby

Skupinové účty spravované služby (gMSA) se v současné době nepodporují v kontejnerech Windows ve službě App Service.

Povolení SSH

Secure Shell (SSH) se běžně používá ke vzdálenému spouštění příkazů pro správu z terminálu příkazového řádku. Pokud chcete povolit funkci konzoly SSH webu Azure Portal s vlastními kontejnery, je potřeba provést následující kroky:

  1. Vytvořte standardní sshd_config soubor s následujícím ukázkovým obsahem a umístěte ho do kořenového adresáře projektu aplikace:

    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

    Poznámka:

    Tento soubor konfiguruje OpenSSH a musí obsahovat následující položky, aby vyhovoval funkci SSH webu Azure Portal:

    • Port musí být nastavena na hodnotu 2222.
    • Ciphers musí obsahovat alespoň jednu položku v tomto seznamu: aes128-cbc,3des-cbc,aes256-cbc.
    • MACs musí obsahovat alespoň jednu položku v tomto seznamu: hmac-sha1,hmac-sha1-96.

  2. Vytvořte skript vstupního bodu s názvem entrypoint.sh (nebo změňte jakýkoli existující soubor vstupního bodu) a přidejte příkaz pro spuštění služby SSH spolu s spouštěcím příkazem aplikace. Následující příklad ukazuje spuštění aplikace v Pythonu. Nahraďte poslední příkaz podle jazyka nebo zásobníku projektu:

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

  3. Do souboru Dockerfile přidejte následující pokyny podle distribuce základní image. Tyto pokyny zkopírují nové soubory, nainstalují server OpenSSH, nastaví správná oprávnění a nakonfigurují vlastní vstupní bod a zpřístupní porty vyžadované aplikací a serverem 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" ]

    Poznámka:

    Kořenové heslo musí být přesně Docker! tak, jak ho služba App Service používá, abyste měli přístup k relaci SSH s kontejnerem. Tato konfigurace neumožňuje externí připojení ke kontejneru. Port 2222 kontejneru je přístupný pouze v síti mostu privátní virtuální sítě a není přístupný útočníkovi na internetu.

  4. Znovu sestavte a nasdílejte image Dockeru do registru a pak otestujte funkci SSH webové aplikace na webu Azure Portal.

Další informace o řešení potíží najdete na blogu služby Aplikace Azure: Povolení SSH ve službě Linux Web App for Containers

Přístup k diagnostickým protokolům

Přístup k protokolům konzoly vygenerovaným z kontejneru.

Nejprve zapněte protokolování kontejneru spuštěním následujícího příkazu:

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

Nahraďte <app-name> názvy vhodné pro vaši webovou aplikaci a <resource-group-name> nahraďte je názvy.

Jakmile je protokolování kontejneru zapnuté, spuštěním následujícího příkazu zobrazte stream protokolu:

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

Pokud nevidíte protokoly konzoly okamžitě, podívejte se znovu za 30 sekund.

Pokud chcete streamování protokolů kdykoli zastavit, zadejte Ctrl+C.

Soubory protokolu můžete také zkontrolovat v prohlížeči na adrese https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Konfigurace vícekontenerových aplikací

Poznámka:

Kontejnery sajdkáře (Preview) budou ve službě App Service úspěšné pro vícekontenerové aplikace. Pokud chcete začít, přečtěte si kurz: Konfigurace kontejneru sajdkáře pro vlastní kontejner ve službě Aplikace Azure Service (Preview).

Použití trvalého úložiště v Docker Compose

Vícekontenerové aplikace, jako je WordPress, potřebují k správnému fungování trvalé úložiště. Pokud ji chcete povolit, musí konfigurace Docker Compose odkazovat na umístění úložiště mimo kontejner. Umístění úložiště v kontejneru neuchovávají změny po restartování aplikace.

Povolte trvalé úložiště nastavením WEBSITES_ENABLE_APP_SERVICE_STORAGE nastavení aplikace pomocí příkazu az webapp config appsettings set v Cloud Shellu.

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

V souboru docker-compose.yml namapujte volumes možnost na ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME je proměnná prostředí ve službě App Service, která je namapovaná na trvalé úložiště vaší aplikace. Příklad:

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"

Omezení verze Preview

Vícekontener je aktuálně ve verzi Preview. Následující funkce platformy App Service se nepodporují:

  • Ověřování/autorizace
  • Spravované identity
  • CORS
  • Integrace virtuální sítě není pro scénáře Docker Compose podporovaná.
  • Docker Compose ve službě Aplikace Azure Services v současné době má limit 4 000 znaků.

Možnosti docker Compose

Následující seznamy ukazují podporované a nepodporované možnosti konfigurace Docker Compose:

Podporované možnosti

Nepodporované možnosti

  • build (nepovoleno)
  • depends_on (ignorováno)
  • networks (ignorováno)
  • secrets (ignorováno)
  • jiné porty než 80 a 8080 (ignorováno)
  • výchozí proměnné prostředí jako $variable and ${variable} na rozdíl od dockeru

Omezení syntaxe

  • "version x.x" vždy musí být prvním příkazem YAML v souboru.
  • Oddíl portů musí používat čísla v uvozových číslech.
  • Oddíl svazku obrázku > musí být citovaný a nemůže mít definice oprávnění.
  • Oddíl svazků nesmí mít za názvem svazku prázdnou složenou složenou závorku.

Poznámka:

Všechny další možnosti, které nejsou explicitně volána, se ve verzi Public Preview ignorují.

robots933456 v protokolech

V protokolech kontejneru se může zobrazit následující zpráva:

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

Tuto zprávu klidně ignorujte. /robots933456.txt je fiktivní cesta URL, kterou App Service používá ke kontrole, jestli kontejner dokáže obsloužit požadavky. Odpověď 404 jednoduše indikuje, že příslušná cesta neexistuje, ale dá službě App Service vědět, že kontejner je v pořádku a je připravený reagovat na požadavky.

Další kroky

Kurz: Migrace vlastního softwaru do služby Aplikace Azure Service pomocí vlastního kontejneru

Kurz: Konfigurace kontejneru sajdkáře pro vlastní kontejner ve službě Aplikace Azure Service (Preview)

Nebo se podívejte na další zdroje informací: