Een aangepaste container configureren voor Azure App Service
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 u nieuw bent bij Azure App Service, volg dan eerst de quickstart voor aangepaste containers en de zelfstudie. Voor sidecarcontainers, zie Zelfstudie: Een sidecarcontainer configureren voor een aangepaste container in Azure App Service.
Notitie
Service Principal wordt niet meer ondersteund voor pull-verificatie voor Windows-container-images. U wordt aangeraden Beheerde identiteit te gebruiken voor zowel Windows- als Linux-containers
Ondersteunde basisafbeeldingen
Kies voor uw aangepaste Windows-images de juiste ouderimage (basisimage) voor het gewenste framework:
- Als u .NET Framework-apps wilt implementeren, gebruikt u een bovenliggende installatiekopie gebaseerd op Windows Server 2019 Core Long-Term Servicing Channel (LTSC).
- Als u .NET Core-apps wilt implementeren, gebruikt u een bovenliggende image op basis van de release van de Nano jaarlijkse kanaal (AC) van Windows Server 2019.
Het duurt wat tijd om bovenliggende images te downloaden bij het opstarten van de app. U kunt de opstarttijd verminderen door gebruik te maken van een van de volgende basisafbeeldingen die al in de 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-image van een aangepaste container wijzigen
Als u een bestaande aangepaste container wilt wijzigen van de huidige Docker-afbeelding naar een nieuwe afbeelding, 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 afbeelding uit een privéregister gebruiken
Als u een afbeelding 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>
Voor <gebruikersnaam> en <wachtwoord>, geef de inloggegevens op voor uw persoonlijke registeraccount.
Beheerde identiteit gebruiken om een containerafbeelding 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 een door het systeem toegewezen beheerde identiteit gebruikt. U kunt in plaats daarvan een door de gebruiker toegewezen beheerde identiteit gebruiken.
Schakel de door het systeem toegewezen beheerde identiteit voor de web-app in met behulp van de opdracht az webapp identity assign :
az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv
Vervang <de app-naam> 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.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 <de registernaam> door de naam van het register. De uitvoer van de opdracht, gefilterd op de
--query
en--output
argumenten, is de resource-id van azure Container Registry.Verleen de beheerde identiteit toegang tot het containerregister.
az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"
Vervang de volgende waarden:
-
<principal-id met de service-principal-id> uit het
az webapp identity assign
commando -
<register-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.
-
<principal-id met de service-principal-id> uit het
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-naam> met de naam van uw web-app.
Tip
Als u de PowerShell-console gebruikt om de opdrachten uit te voeren, escapet u de tekenreeksen in het
--generic-configurations
argument in deze stap en de volgende stap. Bijvoorbeeld:--generic-configurations '{\"acrUseManagedIdentityCreds\": true'
(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
<identity-name>
van uw gebruikertoegewezen beheerde identiteit en gebruik het resultaat<client-id>
om de gebruikertoegewezen beheerde identiteit-id te configureren.az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'
Je bent klaar! De web-app maakt nu gebruik van een beheerde identiteit om uit Azure Container Registry te halen.
Een afbeelding uit een netwerkbeveiligd register 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. U hebt ook virtuele netwerkintegratie nodig voor Azure Container Registry met een privé-eindpunt. Nadat u uw netwerk en DNS-resolutie hebt geconfigureerd, stelt u de routering van de afbeeldingpull via het virtuele netwerk in 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 containerafbeeldingen 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
. Het haalt alleen gewijzigde lagen op. 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 met behulp van 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 met behulp van 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_URL
, DOCKER_REGISTRY_SERVER_USERNAME
en DOCKER_REGISTRY_SERVER_PASSWORD
. Vanwege beveiligingsrisico's worden geen van deze gereserveerde variabelenamen blootgesteld aan de toepassing.
Voor containers op basis van IIS of .NET Framework (4.0 of hoger) worden referenties automatisch door App Service opgenomen in System.ConfigurationManager
.NET-app-instellingen en verbindingsreeksen. Voor alle andere talen of frameworks worden ze geleverd als omgevingsvariabelen voor het proces, met een van de volgende 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 directory C:\home wordt verstrekt om uw aangepaste container toegang te geven tot permanente opslag.
Wanneer permanente opslag is uitgeschakeld, worden schrijfbewerkingen naar de map C:\home niet behouden tijdens het opnieuw opstarten van de app of in meerdere exemplaren. Wanneer permanente opslag is ingeschakeld, blijven alle schrijfbewerkingen naar de map C:\home behouden. Alle exemplaren van een geschaalde app hebben toegang ertoe. Bestaande bestanden die al aanwezig zijn in de permanente opslag wanneer de container wordt gestart, overschrijft alle inhoud in de map C:\home van de container.
De enige uitzondering hierop is de map C:\home\LogFiles . In deze map worden de container- en toepassingslogboeken opgeslagen. Deze map blijft altijd behouden wanneer de app opnieuw wordt opgestart als de toepassingslogboekregistratie is ingeschakeld met de optie Bestandssysteem , of permanente opslag al dan niet is ingeschakeld. Met andere woorden, het in- of uitschakelen van de permanente opslag heeft geen invloed op het gedrag van toepassingslogboekregistratie.
Permanente opslag is standaard ingeschakeld voor aangepaste Windows-containers. Als u dit wilt uitschakelen, stelt u de waarde false
van de WEBSITES_ENABLE_APP_SERVICE_STORAGE
app-instelling in op met behulp van 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}
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 directory is beschikbaar om uw aangepaste container toegang te geven tot permanente opslag. Het opslaan van gegevens in /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 map C:\home niet behouden tijdens het opnieuw opstarten van de app of in meerdere exemplaren. Wanneer permanente opslag is ingeschakeld, blijven alle schrijfbewerkingen naar de \home directory behouden. Alle exemplaren van een opgeschaalde app hebben toegang tot deze bronnen. Eventuele bestaande bestanden die al aanwezig zijn in de permanente opslag wanneer de container wordt gestart, overschrijft alle inhoud in de map \home van de container.
De enige uitzondering hierop is de map \home\LogFiles . In deze map worden de container- en toepassingslogboeken opgeslagen. Deze map blijft altijd behouden wanneer de app opnieuw wordt opgestart als de toepassingslogboekregistratie is ingeschakeld met de optie Bestandssysteem , of permanente opslag al dan niet is ingeschakeld. Met andere woorden, het in- of uitschakelen van de permanente opslag heeft geen invloed op het gedrag van toepassingslogboekregistratie.
U wordt aangeraden gegevens naar /home of een gekoppeld Azure-opslagpad te schrijven. Gegevens die buiten deze paden worden geschreven, zijn niet permanent tijdens het opnieuw opstarten. De gegevens worden opgeslagen in door het platform beheerde hostschijfruimte, gescheiden van het quotum voor bestandsopslag van App Service Plans.
Permanente opslag is standaard uitgeschakeld voor aangepaste Linux-containers. Als u dit wilt inschakelen, stelt u de waarde true
van de WEBSITES_ENABLE_APP_SERVICE_STORAGE
app-instelling in op met behulp van 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}
Notitie
U kunt ook uw eigen permanente opslag configureren.
HTTPS-sessie detecteren
App Service beëindigt TLS aan de front-ends. Dat betekent dat TLS-aanvragen nooit bij uw app komen. U hoeft geen ondersteuning voor TLS in uw app te implementeren.
De front-ends bevinden zich in Azure-datacenters. Als u TLS 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 met de container
Als u rechtstreeks verbinding wilt maken met uw Windows-container voor diagnostische taken, gaat u naar https://<app-name>.scm.azurewebsites.net/
en kiest u de SSH-optie. Met deze optie maakt u een directe SSH-sessie 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 andere instantie selecteren in de vervolgkeuzelijst Exemplaar in het bovenste Kudu-menu.
- Met uitzondering van wijzigingen in de gedeelde opslag blijft elke wijziging die u aanbrengt in de container vanuit de SSH-sessie , niet behouden wanneer uw app opnieuw wordt opgestart. Dergelijke wijzigingen maken geen deel uit van de Docker-image. 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) zijn standaard ingeschakeld. U moet toepassingslogboeken of webserverlogboeken handmatig inschakelen vanuit de container. Zie Logboekregistratie van toepassingen inschakelen en webserverlogboeken inschakelen voor meer informatie.
Er zijn verschillende manieren om toegang te krijgen tot Docker-logboeken:
In het Azure-portaal
Docker-logboeken worden weergegeven in Azure Portal, op de pagina Containerinstellingen van uw app. De logboeken worden ingekort. Als u alle logboeken wilt downloaden, selecteert u Downloaden.
Van Kudu
Als u de afzonderlijke logboekbestanden wilt zien, gaat u naar https://<app-name>.scm.azurewebsites.net/DebugConsole
de map LogFiles en selecteert u deze. 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 map C:\home\LogFiles 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 naar https://<app-name>.scm.azurewebsites.net/api/logs/docker
om metagegevens voor de Docker-logboeken te bekijken. Mogelijk ziet u meer dan één logboekbestand. Met de href
eigenschap kunt u 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 is 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 WEBSITE_MEMORY_LIMIT_MB
app-instelling op te geven met behulp van 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. Zie de sectie Premium v3-serviceabonnementen van App Service voor meer informatie over hoeveel geheugen er beschikbaar is.
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 door uw staging-site wordt gebruikt. 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 met behulp van 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}
Tip
Het bijwerken van de app-instelling activeert automatisch opnieuw opstarten, wat minimale downtime veroorzaakt. Voor een productie-app kunt u overwegen deze te wisselen naar een staging-slot, de app-instelling in de staging-slot te wijzigen en deze vervolgens weer in productie te zetten.
Als u uw aangepaste nummer wilt controleren, opent u een SSH-sessie vanuit Azure Portal of gebruikt u de Kudu-portal (https://<app-name>.scm.azurewebsites.net/webssh/host
). Voer de volgende opdrachten in met behulp van PowerShell. Elke opdracht retourneert een getal.
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 het aantal kernen dat beschikbaar is, raadpleegt u de sectie Premium v3-serviceabonnementen van App Service-prijzen.
Gedrag van status ping aanpassen
App Service beschouwt een container als succesvol gestart wanneer de container start 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 niet reageert op pings, registreert App Service een gebeurtenis in het Docker-logboek.
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 met behulp van 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:
Waarde | Omschrijvingen |
---|---|
Repareren | 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 vanaf een opdrachtregelterminal. Voer de volgende stappen uit om de SSH-consolefunctie van Azure Portal in te schakelen met aangepaste containers:
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. -
Ciphers
moet ten minste één item in deze lijst bevatten:aes128-cbc,3des-cbc,aes256-cbc
. -
MACs
moet ten minste één item in deze lijst bevatten:hmac-sha1,hmac-sha1-96
.
-
Maak een invoerpuntscript met de naam entrypoint.sh of wijzig een bestaand invoerpuntbestand. Voeg de opdracht toe om de SSH-service te starten, samen met de opstartopdracht van de toepassing. In het volgende voorbeeld ziet u hoe u een Python-toepassing start. Vervang de laatste opdracht volgens de projecttaal/stack:
Voeg de volgende instructies toe aan de Dockerfile op basis van de distributie van de basisimage. 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!
zijn omdat het door App Service wordt gebruikt 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.Bouw de Docker-installatiekopieën opnieuw en push deze naar het register en test vervolgens de functie Web App SSH in Azure Portal.
Zie voor meer informatie over het oplossen van problemen de Azure App Service-blog: Enabling SSH on Linux Web App for Containers
Toegang tot diagnostische logboeken
U hebt vanuit de container toegang tot de consolelogboeken.
Voer de volgende opdracht uit om containerlogboekregistratie in te schakelen:
az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem
Vervang #D0 en #D1 door namen die geschikt zijn voor uw web-app.
Nadat u containerlogboekregistratie hebt 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 consolelogboeken niet onmiddellijk worden weergegeven, controleert u het na 30 seconden opnieuw.
Als u het streamen van logboeken wilt stoppen, selecteert u Ctrl+C.
U kunt ook de logboekbestanden in een browser inspecteren op https://<app-name>.scm.azurewebsites.net/api/logs/docker
.
Apps met meerdere containers configureren
Notitie
Sidecar-containers vervangen apps met meerdere containers in App Service. Om aan de slag te gaan, zie Handleiding: Een sidecarcontainer configureren voor aangepaste container in Azure App Service.
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.
Als u permanente opslag wilt inschakelen, stelt u de WEBSITES_ENABLE_APP_SERVICE_STORAGE
app-instelling in. Gebruik 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 ${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
De multi-container functie is momenteel in preview. 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
- opdracht
- invoerpunt
- omgeving
- afbeelding
- poorten
- herstarten
- diensten
- volumes (toewijzing aan Azure Storage wordt niet ondersteund)
Niet-ondersteunde opties
- build (niet toegestaan)
- depends_on (genegeerd)
- netwerken (genegeerd)
- geheimen (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
- De sectie poorten moet aangehaalde nummers gebruiken.
- De afbeelding volumesectie moet tussen aanhalingstekens staan en mag geen machtigingsdefinities hebben.
- De volumes-sectie mag geen lege accolades achter de volumenaam hebben.
Notitie
Alle andere opties die niet expliciet worden genoemd, worden genegeerd in openbare preview.
Het robots933456-bericht negeren in logboeken
Mogelijk ziet u 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 aan dat het pad niet bestaat en geeft aan App Service aan dat de container in orde is en klaar is om te reageren op aanvragen.
Verwante inhoud
Of bekijk meer resources: