Een aangepaste container configureren voor Azure App Service

  • Artikel

In dit artikel leest u hoe u een aangepaste container configureert die moet worden uitgevoerd op Azure-app Service.

Deze handleiding bevat belangrijke concepten en instructies voor containerisatie van Windows-apps in App Service. Nieuwe Azure-app Service-gebruikers moeten eerst de quickstart en zelfstudie voor aangepaste containers volgen.

Deze handleiding bevat belangrijke concepten en instructies voor containerisatie van Linux-apps in App Service. Als Azure-app Service nieuw is, volgt u eerst de quickstart en zelfstudie voor aangepaste containers. Er is ook een quickstart voor apps met meerdere containers en zelfstudies. Zie zelfstudie: Een sidecarcontainer configureren voor aangepaste container in Azure-app Service (preview) voor sidecar-containers (preview).

Notitie

Service-principal wordt niet meer ondersteund voor pull-verificatie voor Windows-containerinstallatiekopieën. De aanbevolen manier is om Beheerde identiteit te gebruiken voor zowel Windows- als Linux-containers

Ondersteunde bovenliggende installatiekopieën

Voor uw aangepaste Windows-installatiekopieën moet u de juiste bovenliggende installatiekopieën (basisinstallatiekopieën) kiezen voor het gewenste framework:

  • Als u .NET Framework-apps wilt implementeren, gebruikt u een bovenliggende installatiekopieën op basis van de release windows Server 2019 Core Long-Term Servicing Channel (LTSC).
  • Als u .NET Core-apps wilt implementeren, gebruikt u een bovenliggende installatiekopie op basis van de release van Windows Server 2019 Nano Semi-Annual Servicing Channel (SAC).

Het duurt enige tijd om een bovenliggende installatiekopie te downloaden tijdens het opstarten van de app. U kunt deze opstarttijd echter verminderen door een van de volgende bovenliggende installatiekopieën te gebruiken die al in cache zijn opgeslagen in 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

De Docker-installatiekopieën van een aangepaste container wijzigen

Als u een bestaande aangepaste container wilt wijzigen van de huidige Docker-installatiekopieën in een nieuwe installatiekopieën, gebruikt u de volgende opdracht:

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

Een installatiekopieën uit een privéregister gebruiken

Als u een installatiekopieën uit een privéregister wilt gebruiken, zoals Azure Container Registry, voert u de volgende opdracht uit:

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>

Geef voor gebruikersnaam> en< wachtwoord> de aanmeldingsreferenties op voor uw persoonlijke registeraccount.<

Beheerde identiteit gebruiken om een installatiekopie op te halen uit Azure Container Registry

Gebruik de volgende stappen om uw web-app te configureren voor het ophalen uit Azure Container Registry (ACR) met behulp van een beheerde identiteit. In de stappen wordt gebruikgemaakt van door het systeem toegewezen beheerde identiteit, maar u kunt ook door de gebruiker toegewezen beheerde identiteit gebruiken.

  1. Schakel de door het systeem toegewezen beheerde identiteit voor de web-app in met behulp van de az webapp identity assign opdracht:

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

    Vervang <app-name> door de naam die u in de vorige stap hebt gebruikt. De uitvoer van de opdracht (gefilterd op de --query en --output argumenten) is de service-principal-id van de toegewezen identiteit.

  2. Haal de resource-id van uw Azure Container Registry op:

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

    Vervang <registry-name> door de naam van uw register. De uitvoer van de opdracht (gefilterd op de --query en --output argumenten) is de resource-id van azure Container Registry.

  3. De beheerde identiteit toegang verlenen tot het containerregister:

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

    Vervang de volgende waarden:

    • <principal-id> door de service-principal-id uit de opdracht az webapp identity assign
    • <registry-resource-id> met de id van uw containerregister vanuit de az acr show opdracht

    Zie Wat is op rollen gebaseerd toegangsbeheer van Azure voor meer informatie over deze machtigingen.

  4. Configureer uw app voor het gebruik van de beheerde identiteit om uit Azure Container Registry te halen.

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

    Vervang de volgende waarden:

    • <app-name> met de naam van uw web-app.

    Tip

    Als u de PowerShell-console gebruikt om de opdrachten uit te voeren, moet u de tekenreeksen in het --generic-configurations argument in deze en de volgende stap escapen. Bijvoorbeeld: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (Optioneel) Als uw app gebruikmaakt van een door de gebruiker toegewezen beheerde identiteit, controleert u of de identiteit is geconfigureerd in de web-app en stelt u vervolgens de eigenschap in om de acrUserManagedIdentityID client-id op te geven:

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

    Vervang de door de <identity-name> gebruiker toegewezen beheerde identiteit en gebruik de uitvoer <client-id> om de door de gebruiker toegewezen beheerde identiteit-id te configureren.

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

U bent klaar en de web-app maakt nu gebruik van beheerde identiteit om azure Container Registry op te halen.

Een installatiekopieën uit een netwerkbeveiligingsregister gebruiken

Als u verbinding wilt maken met een register in een virtueel netwerk of on-premises, moet uw app worden geïntegreerd met een virtueel netwerk (VNET). VNET-integratie is ook nodig voor Azure Container Registry met een privé-eindpunt. Wanneer uw netwerk- en DNS-omzetting is geconfigureerd, schakelt u de routering van de installatiekopie in door het virtuele netwerk te configureren door de vnetImagePullEnabled site-instelling te configureren:

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

Ik zie de bijgewerkte container niet

Als u de Docker-containerinstellingen zo wijzigt dat deze verwijst naar een nieuwe container, kan het enkele minuten duren voordat de app HTTP-aanvragen van de nieuwe container verwerkt. Terwijl de nieuwe container wordt opgehaald en gestart, blijft App Service aanvragen van de oude container verwerken. Alleen wanneer de nieuwe container is gestart en klaar is voor het ontvangen van aanvragen, begint App Service met het verzenden van aanvragen naar de container.

Hoe containerinstallatiekopieën worden opgeslagen

De eerste keer dat u een aangepaste Docker-installatiekopie uitvoert in App Service, voert docker pull App Service alle afbeeldingslagen uit en haalt deze op. Deze lagen worden opgeslagen op schijf, bijvoorbeeld als u Docker on-premises gebruikt. Telkens wanneer de app opnieuw wordt opgestart, voert App Service een docker pull, maar haalt alleen lagen op die zijn gewijzigd. Als er geen wijzigingen zijn, gebruikt App Service bestaande lagen op de lokale schijf.

Als de app rekenprocessen om welke reden dan ook wijzigt, zoals omhoog en omlaag schalen van de prijscategorieën, moet App Service alle lagen opnieuw omlaag halen. Hetzelfde geldt als u uitschaalt om meer exemplaren toe te voegen. Er zijn ook zeldzame gevallen waarin de app-exemplaren kunnen veranderen zonder een schaalbewerking.

Poortnummer configureren

Standaard gaat App Service ervan uit dat uw aangepaste container luistert op poort 80. Als uw container naar een andere poort luistert, stelt u de WEBSITES_PORT app-instelling in uw App Service-app in. U kunt deze instellen via Cloud Shell. In Bash:

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

In PowerShell:

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

Met App Service kan uw container momenteel slechts één poort beschikbaar maken voor HTTP-aanvragen.

Omgevingsvariabelen configureren

Uw aangepaste container kan omgevingsvariabelen gebruiken die extern moeten worden opgegeven. U kunt ze doorgeven via Cloud Shell. In Bash:

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

In PowerShell:

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

Wanneer uw app wordt uitgevoerd, worden de App Service-app-instellingen automatisch in het proces opgenomen als omgevingsvariabelen. U kunt variabelen voor de containeromgeving controleren met de URL https://<app-name>.scm.azurewebsites.net/Env.

Als uw app gebruikmaakt van installatiekopieën uit een privéregister of vanuit Docker Hub, worden referenties voor toegang tot de opslagplaats opgeslagen in omgevingsvariabelen: DOCKER_REGISTRY_SERVER_URLen DOCKER_REGISTRY_SERVER_USERNAMEDOCKER_REGISTRY_SERVER_PASSWORD. Vanwege beveiligingsrisico's worden geen van deze gereserveerde variabelenamen blootgesteld aan de toepassing.

Voor iis- of .NET Framework-containers (4.0 of hoger) worden ze automatisch door App Service ingevoegd in System.ConfigurationManager .NET-app-instellingen en verbindingsreeks s. Voor alle andere talen of frameworks worden ze geleverd als omgevingsvariabelen voor het proces, met een van de volgende bijbehorende voorvoegsels:

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

Deze methode werkt zowel voor apps met één container of voor apps met meerdere containers, waarbij de omgevingsvariabelen worden opgegeven in het docker-compose.yml-bestand .

Permanente gedeelde opslag gebruiken

U kunt de map C:\home in uw aangepaste containerbestandssysteem gebruiken om bestanden op te slaan tijdens het opnieuw opstarten en deze te delen tussen exemplaren. De C:\home map is beschikbaar om uw aangepaste container toegang te geven tot permanente opslag.

Wanneer permanente opslag is uitgeschakeld, worden schrijfbewerkingen naar de C:\home map niet behouden tijdens het opnieuw opstarten van de app of in meerdere exemplaren. Wanneer permanente opslag is ingeschakeld, blijven alle schrijfbewerkingen naar de C:\home map behouden en kunnen ze worden geopend door alle exemplaren van een uitgeschaalde app. Bovendien worden alle inhoud in de C:\home map van de container overschreven door bestaande bestanden die al aanwezig zijn in de permanente opslag wanneer de container wordt gestart.

De enige uitzondering hierop is de C:\home\LogFiles map, die wordt gebruikt voor het opslaan van de container- en toepassingslogboeken. Deze map blijft altijd behouden wanneer de app opnieuw wordt opgestart als toepassingslogboek is ingeschakeld met de optie Bestandssysteem , onafhankelijk van de permanente opslag die wordt ingeschakeld of uitgeschakeld. Met andere woorden, het in- of uitschakelen van de permanente opslag heeft geen invloed op het gedrag van toepassingslogboekregistratie.

Permanente opslag is standaard uitgeschakeld in aangepaste Windows-containers. Als u dit wilt inschakelen, stelt u de waarde true van de WEBSITES_ENABLE_APP_SERVICE_STORAGE app-instelling in op via Cloud Shell. In Bash:

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

In PowerShell:

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

U kunt de /home directory in uw aangepaste containerbestandssysteem gebruiken om bestanden op te slaan tijdens het opnieuw opstarten en deze te delen tussen exemplaren. De /home map is beschikbaar om uw aangepaste container toegang te geven tot permanente opslag. Het opslaan van gegevens binnen /home draagt bij aan het quotum voor opslagruimte dat is opgenomen in uw App Service-plan.

Wanneer permanente opslag is uitgeschakeld, worden schrijfbewerkingen naar de /home map niet behouden tijdens het opnieuw opstarten van de app of in meerdere exemplaren. Wanneer permanente opslag is ingeschakeld, blijven alle schrijfbewerkingen naar de /home map behouden en kunnen ze worden geopend door alle exemplaren van een uitgeschaalde app. Bovendien worden alle inhoud in de /home map van de container overschreven door bestaande bestanden die al aanwezig zijn in de permanente opslag wanneer de container wordt gestart.

De enige uitzondering hierop is de /home/LogFiles map, die wordt gebruikt voor het opslaan van de container- en toepassingslogboeken. Deze map blijft altijd behouden wanneer de app opnieuw wordt opgestart als toepassingslogboek is ingeschakeld met de optie Bestandssysteem , onafhankelijk van de permanente opslag die wordt ingeschakeld of uitgeschakeld. Met andere woorden, het in- of uitschakelen van de permanente opslag heeft geen invloed op het gedrag van toepassingslogboekregistratie.

Het is raadzaam om gegevens naar of een gekoppeld Azure-opslagpad te /home schrijven. Gegevens die buiten deze paden worden geschreven, zijn niet permanent tijdens het opnieuw opstarten en worden opgeslagen in door het platform beheerde hostschijfruimte, gescheiden van het quotum voor bestandsopslag van App Service Plans.

Permanente opslag is standaard ingeschakeld voor aangepaste Linux-containers. Als u dit wilt uitschakelen, stelt u de waarde false van de WEBSITES_ENABLE_APP_SERVICE_STORAGE app-instelling in op via Cloud Shell. In Bash:

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

In PowerShell:

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

Notitie

U kunt ook uw eigen permanente opslag configureren.

HTTPS-sessie detecteren

App Service beëindigt TLS/SSL aan de front-ends. Dat betekent dat TLS/SSL-aanvragen nooit bij uw app komen. U hoeft dit niet te doen en moet geen ondersteuning voor TLS/SSL implementeren in uw app.

De front-ends bevinden zich in Azure-datacenters. Als u TLS/SSL gebruikt met uw app, wordt uw verkeer via internet altijd veilig versleuteld.

ASP.NET machinesleutelinjectie aanpassen

Tijdens het starten van de container worden automatisch gegenereerde sleutels in de container opgenomen als de computersleutels voor ASP.NET cryptografische routines. U vindt deze sleutels in uw container door te zoeken naar de volgende omgevingsvariabelen: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, . MACHINEKEY_Validation

De nieuwe sleutels bij elke herstart kunnen ASP.NET formulierverificatie opnieuw instellen en de status weergeven, als uw app hiervan afhankelijk is. Als u wilt voorkomen dat sleutels automatisch worden gegenereerd, stelt u deze handmatig in als App Service-app-instellingen.

Verbinding maken naar de container

U kunt rechtstreeks verbinding maken met uw Windows-container voor diagnostische taken door naar de SSH-optie te https://<app-name>.scm.azurewebsites.net/ navigeren en te kiezen. Er wordt een directe SSH-sessie met uw container tot stand gebracht waarin u opdrachten in uw container kunt uitvoeren.

  • Het werkt afzonderlijk van de grafische browser erboven, waarbij alleen de bestanden in uw gedeelde opslag worden weergegeven.
  • In een uitgeschaalde app is de SSH-sessie verbonden met een van de containerinstanties. U kunt een ander exemplaar selecteren in de vervolgkeuzelijst Exemplaar in het bovenste Kudu-menu.
  • Wijzigingen die u aanbrengt in de container vanuit de SSH-sessie , blijven niet behouden wanneer uw app opnieuw wordt opgestart (met uitzondering van wijzigingen in de gedeelde opslag), omdat deze geen deel uitmaakt van de Docker-installatiekopieën. Als u uw wijzigingen wilt behouden, zoals registerinstellingen en software-installatie, maakt u deze deel uit van het Dockerfile.

Toegang tot diagnostische logboeken

App Service registreert acties van de Docker-host en -activiteiten vanuit de container. Logboeken van de Docker-host (platformlogboeken) worden standaard verzonden, maar toepassingslogboeken of webserverlogboeken vanuit de container moeten handmatig worden ingeschakeld. Zie Logboekregistratie van toepassingen inschakelen en webserverlogboeken inschakelen voor meer informatie.

Er zijn verschillende manieren om toegang te krijgen tot Docker-logboeken:

In Azure Portal

Docker-logboeken worden weergegeven in de portal, op de pagina Container Instellingen van uw app. De logboeken worden afgekapt, maar u kunt alle logboeken downloaden die Downloaden selecteren.

Van Kudu

Navigeer naar https://<app-name>.scm.azurewebsites.net/DebugConsole de map LogFiles en selecteer deze om de afzonderlijke logboekbestanden weer te geven. Als u de volledige LogFiles-map wilt downloaden, selecteert u het pictogram Downloaden links van de mapnaam. U kunt deze map ook openen met behulp van een FTP-client.

In de SSH-terminal hebt u standaard geen toegang tot de C:\home\LogFiles map omdat permanente gedeelde opslag niet is ingeschakeld. Schakel permanente gedeelde opslag in om dit gedrag in te schakelen in de consoleterminal.

Als u probeert het Docker-logboek te downloaden dat momenteel wordt gebruikt met behulp van een FTP-client, krijgt u mogelijk een foutmelding vanwege een bestandsvergrendeling.

Met de Kudu-API

Navigeer rechtstreeks om metagegevens voor de Docker-logboeken te https://<app-name>.scm.azurewebsites.net/api/logs/docker bekijken. Mogelijk ziet u meer dan één logboekbestand in de lijst en kunt u met de href eigenschap het logboekbestand rechtstreeks downloaden.

Als u alle logboeken samen in één ZIP-bestand wilt downloaden, opent u .https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip

Containergeheugen aanpassen

Standaard zijn voor alle Windows-containers die zijn geïmplementeerd in Azure-app Service een geheugenlimiet geconfigureerd. De volgende tabel bevat de standaardinstellingen per App Service Plan SKU.

App Service Plan SKU Standaardgeheugenlimiet per app in MB
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

U kunt deze waarde wijzigen door de app-instelling WEBSITE_MEMORY_LIMIT_MB op te geven via Cloud Shell. In Bash:

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

In PowerShell:

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

De waarde is gedefinieerd in MB en moet kleiner en gelijk zijn aan het totale fysieke geheugen van de host. In een App Service-plan met 8 GB RAM mag het cumulatieve totaal voor WEBSITE_MEMORY_LIMIT_MB alle apps bijvoorbeeld niet groter zijn dan 8 GB. In de sectie Premium v3-serviceabonnementen vindt u informatie over hoeveel geheugen beschikbaar is voor elke prijscategorie.

Het aantal rekenkernen aanpassen

Standaard wordt een Windows-container uitgevoerd met alle beschikbare kernen voor de gekozen prijscategorie. Mogelijk wilt u het aantal kernen verminderen dat uw staging-site gebruikt, bijvoorbeeld. Als u het aantal kernen wilt verminderen dat door een container wordt gebruikt, stelt u de WEBSITE_CPU_CORES_LIMIT app-instelling in op het voorkeursaantal kernen. U kunt deze instellen via Cloud Shell. In Bash:

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

In PowerShell:

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

Notitie

Het bijwerken van de app-instelling activeert automatisch opnieuw opstarten, wat minimale downtime veroorzaakt. Voor een productie-app kunt u overwegen deze om te wisselen in een staging-site, de app-instelling in de staging-site te wijzigen en deze vervolgens weer in productie te zetten.

Controleer uw aangepaste nummer door een SSH-sessie te openen vanuit de portal of via de Kudu-portal (https://<app-name>.scm.azurewebsites.net/webssh/host) en de volgende opdrachten te typen met behulp van PowerShell. Elke opdracht voert een getal uit.

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

De processors kunnen multicore- of hyperthreading-processors zijn. Informatie over hoeveel kernen er beschikbaar zijn voor elke prijscategorie vindt u in app serviceprijzen in de sectie Premium v3-serviceabonnementen .

Gedrag van status ping aanpassen

App Service beschouwt een container om te worden gestart wanneer de container wordt gestart en reageert op een HTTP-ping. De aanvraag voor status ping bevat de header User-Agent= "App Service Hyper-V Container Availability Check". Als de container wordt gestart maar na een bepaalde tijd geen pings reageert, registreert App Service een gebeurtenis in het Docker-logboek, waarin staat dat de container niet is gestart.

Als uw toepassing resource-intensief is, reageert de container mogelijk niet tijdig op de HTTP-ping. Als u de acties wilt beheren wanneer HTTP-pings mislukken, stelt u de CONTAINER_AVAILABILITY_CHECK_MODE app-instelling in. U kunt deze instellen via Cloud Shell. In Bash:

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

In PowerShell:

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

In de volgende tabel ziet u de mogelijke waarden:

Weergegeven als Omschrijvingen
Reparatie Start de container opnieuw op na drie opeenvolgende beschikbaarheidscontroles
ReportOnly De standaardwaarde. Start de container niet opnieuw, maar rapporteer in de Docker-logboeken voor de container na drie opeenvolgende beschikbaarheidscontroles.
Uit Controleer niet op beschikbaarheid.

Ondersteuning voor door groepen beheerde serviceaccounts

Groep beheerde serviceaccounts (gMSA's) worden momenteel niet ondersteund in Windows-containers in App Service.

SSH inschakelen

Secure Shell (SSH) wordt vaak gebruikt om beheeropdrachten op afstand uit te voeren vanuit een opdrachtregelterminal. Als u de SSH-consolefunctie van Azure Portal wilt inschakelen met aangepaste containers, zijn de volgende stappen vereist:

  1. Maak een standaardbestand sshd_config met de volgende voorbeeldinhoud en plaats het in de hoofdmap van het toepassingsproject:

    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

    Notitie

    Dit bestand configureert OpenSSH en moet de volgende items bevatten om te voldoen aan de SSH-functie van Azure Portal:

    • Port moet worden ingesteld op 2222.
    • Ciphersmoet ten minste één item in deze lijst bevatten: aes128-cbc,3des-cbc,aes256-cbc.
    • MACsmoet ten minste één item in deze lijst bevatten: hmac-sha1,hmac-sha1-96.

  2. Maak een invoerpuntscript met de naam entrypoint.sh (of wijzig een bestaand invoerpuntbestand) en voeg de opdracht toe om de SSH-service te starten, samen met de opdracht voor het opstarten van de toepassing. In het volgende voorbeeld ziet u hoe u een Python-toepassing start. Vervang de laatste opdracht volgens de projecttaal/stack:

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

  3. Voeg de volgende instructies toe aan het Dockerfile volgens de distributie van de basisinstallatiekopieën. Met deze instructies kopieert u de nieuwe bestanden, installeert u de OpenSSH-server, stelt u de juiste machtigingen in en configureert u het aangepaste invoerpunt en stelt u de poorten beschikbaar die zijn vereist voor de toepassing en de SSH-server, respectievelijk:

    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" ]

    Notitie

    Het hoofdwachtwoord moet precies Docker! zo zijn als het wordt gebruikt door App Service om u toegang te geven tot de SSH-sessie met de container. Deze configuratie staat geen externe verbindingen naar de container toe. Poort 2222 van de container is alleen toegankelijk binnen het brugnetwerk van een particulier virtueel netwerk en is niet toegankelijk voor een aanvaller op internet.

  4. Bouw de Docker-installatiekopieën opnieuw en push deze naar het register en test vervolgens de functie Web App SSH in Azure Portal.

Meer informatie over probleemoplossing vindt u in de Azure-app Service-blog: SSH inschakelen in Linux Web App for Containers

Toegang tot diagnostische logboeken

U hebt vanuit de container toegang tot de consolelogboeken.

Schakel eerst logboekregistratie voor containers in door de volgende opdracht uit te voeren:

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

Vervang <app-name> en <resource-group-name> door de namen die van toepassing zijn op uw web-app.

Zodra logboekregistratie is ingeschakeld, voert u de volgende opdracht uit om de logboekstream te zien:

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

Als u de consolelogboeken niet meteen ziet, probeert u het opnieuw na 30 seconden.

U kunt op elk gewenst moment stoppen met logboekstreaming door Ctrl+C te typen.

U kunt ook de logboekbestanden in een browser inspecteren op https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Apps met meerdere containers configureren

Permanente opslag gebruiken in Docker Compose

Apps met meerdere containers, zoals WordPress, hebben permanente opslag nodig om goed te kunnen functioneren. Als u dit wilt inschakelen, moet uw Docker Compose-configuratie verwijzen naar een opslaglocatie buiten uw container. Opslaglocaties in uw container behouden geen wijzigingen na het opnieuw opstarten van de app.

Schakel permanente opslag in door de WEBSITES_ENABLE_APP_SERVICE_STORAGE app-instelling in te stellen met behulp van de opdracht az webapp config appsettings set in Cloud Shell.

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

Wijs in uw docker-compose.yml bestand de volumes optie toe aan ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME is een omgevingsvariabele in App Service die is toegewezen aan de permanente opslag voor uw app. Voorbeeld:

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"

Preview-beperkingen

Meerdere containers zijn momenteel beschikbaar als preview-versie. De volgende App Service-platformfuncties worden niet ondersteund:

  • Verificatie/autorisatie
  • Beheerde identiteiten
  • CORS
  • Integratie van virtuele netwerken wordt niet ondersteund voor Docker Compose-scenario's
  • Docker Compose op Azure App Services heeft momenteel een limiet van 4.000 tekens.

Docker Compose-opties

In de volgende lijsten worden ondersteunde en niet-ondersteunde configuratieopties voor Docker Compose weergegeven:

Ondersteunde opties

Niet-ondersteunde opties

  • build (niet toegestaan)
  • depends_on (genegeerd)
  • networks (genegeerd)
  • secrets (genegeerd)
  • andere poorten dan 80 en 8080 (genegeerd)
  • standaardomgevingsvariabelen, zoals $variable and ${variable} in tegenstelling tot docker

Syntaxisbeperkingen

  • 'versie x.x' moet altijd de eerste YAML-instructie in het bestand zijn
  • sectie poorten moet getallen tussen aanhaalnummers gebruiken
  • > sectie afbeeldingsvolume moet worden aanhaling gebracht en mag geen machtigingsdefinities hebben
  • sectie volumes mag geen lege accolade achter de volumenaam hebben

Notitie

Alle andere opties die niet expliciet worden genoemd, worden genegeerd in openbare preview.

robots933456 in logboeken

U ziet mogelijk het volgende bericht in de containerlogboeken:

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

U kunt dit bericht veilig negeren. /robots933456.txt is een dummy-URL-pad dat App Service gebruikt om te controleren of de container aanvragen kan verwerken. Een 404-antwoord geeft alleen aan dat het pad niet bestaat, maar laat App Service wel weten dat de container in orde is en klaar is om te reageren op aanvragen.

Volgende stappen

Zelfstudie: Aangepaste software migreren naar Azure-app Service met behulp van een aangepaste container

Zelfstudie: WordPress-app met meerdere containers

Of bekijk meer resources: