Dela via

Konfigurera en anpassad container för Azure App Service

  • Artikel

Den här artikeln visar hur du konfigurerar en anpassad container som ska köras på Azure App Service.

Den här guiden innehåller viktiga begrepp och instruktioner för containerisering av Windows-appar i App Service. Nya Azure App Service-användare bör först följa snabbstarten och självstudien för anpassade containrar och samt .

Den här guiden innehåller viktiga begrepp och instruktioner för containerisering av Linux-appar i App Service. Om du är ny till Azure App Service, följ först snabbstartsguiden för anpassad container och handledning. För sidovagnscontainrar, se Självstudie: Konfigurera en sidovagnscontainer för anpassad container i Azure App Service.

Kommentar

Tjänsthuvudkonto stöds inte längre för autentisering vid hämtning av Windows-containeravbildningar. Vi rekommenderar att du använder hanterad identitet för både Windows- och Linux-containrar

Överordnade avbildningar som stöds

För din anpassade Windows-avbildning väljer du rätt föräldraavbildning (basavbildning) för ramverket du önskar:

  • Om du vill distribuera .NET Framework-tillämpningar använder du en överordnad avbildning baserat på Windows Server 2019 Core-versionen Long-Term Servicing Channel (LTSC).
  • Om du vill distribuera .NET Core-appar använder du en förälderavbildning baserad på Windows Server 2019 Nano Annual Channel (AC) utgåva.

Det tar en viss tid att ladda ned en moderavbild under appstarten. Du kan minska starttiden genom att använda någon av följande överordnade avbildningar som redan är cachelagrade i Azure App Service:

Ändra Docker-avbildningen av en anpassad container

Om du vill ändra en befintlig anpassad container från den aktuella Docker-avbildningen till en ny avbildning använder du följande kommando:

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

Använda en avbildning från ett privat register

Om du vill använda en avbildning från ett privat register, till exempel Azure Container Registry, kör du följande kommando:

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>

Ange > och >.

Använda hanterad identitet för att hämta avbildning från Azure Container Registry

Använd följande steg för att konfigurera webbappen att hämta från Azure Container Registry (ACR) med hjälp av hanterad identitet. Stegen använder systemtilldelad hanterad identitet. Du kan använda användartilldelad hanterad identitet i stället.

  1. Aktivera den systemtilldelade hanterade identiteten för webbappen med hjälp av kommandot az webapp identity assign:

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

    Ersätt <appnamn> med namnet du använde i föregående steg. Utdata från kommandot, filtrerat efter argumenten --query och --output, är tjänstens huvudnamns-ID för den tilldelade identiteten.

  2. Hämta resurs-ID:t för Azure Container Registry:

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

    Ersätt <registernamn> med namnet på registret. Utdata från kommandot, filtrerat efter argumenten --query och --output, är resurs-ID för Azure Container Registry.

  3. Ge den hanterade identiteten behörighet att komma åt containerregistret:

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

    Ersätt följande variabelvärden:

    • <principal-id> med tjänstens huvudnamns-ID från kommandot az webapp identity assign
    • <registry-resource-id> med ID:t för containerregistret från kommandot az acr show

    Mer information om dessa behörigheter finns i Vad är rollbaserad åtkomstkontroll i Azure.

  4. Konfigurera din app så att den använder den hanterade identiteten för att hämta från Azure Container Registry.

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

    Ersätt följande variabelvärden:

    • <appnamn> med namnet på din webbapp.

    Tips

    Om du använder PowerShell-konsolen för att köra kommandona kan du fly från strängarna i argumentet --generic-configurations i det här steget och nästa steg. Till exempel: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (Valfritt) Om din app använder en användartilldelad hanterad identitet kontrollerar du att identiteten har konfigurerats i webbappen och anger acrUserManagedIdentityID sedan egenskapen för att ange dess klient-ID:

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

    Ersätt <identity-name> för din användartilldelade hanterade identitet och använd utdata <client-id> för att konfigurera ID:t för den användartilldelade hanterade identiteten.

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

Ni är klara! Webbappen använder nu hanterad identitet för att hämta från Azure Container Registry.

Använda en avbildning från ett nätverksskyddat register

Om du vill ansluta och hämta från ett register i ett virtuellt nätverk eller lokalt måste din app integreras med ett virtuellt nätverk. Du behöver också integrering av virtuella nätverk för Azure Container Registry med en privat slutpunkt. När du har konfigurerat nätverks- och DNS-upplösningen aktiverar du routningen av avbildningsöverföringen genom det virtuella nätverket genom att konfigurera platsinställningen vnetImagePullEnabled.

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

Jag ser inte den uppdaterade containern

Om du ändrar inställningarna för Docker-containern så att de pekar på en ny container kan det ta några minuter innan appen hanterar HTTP-begäranden från den nya containern. Medan den nya containern hämtas och startas fortsätter App Service att hantera begäranden från den gamla containern. Först när den nya containern har startats och är redo att ta emot begäranden börjar App Service skicka begäranden till den.

Hur containeravbildningar lagras

Första gången du kör en anpassad Docker-avbildning i App Service gör App Service en docker pull och hämtar alla bildskikt. De här lagren lagras på disken, till exempel om du använder Docker lokalt. Varje gång appen startas om gör app-tjänsten en docker pull. Den hämtar bara de lager som har ändrats. Om inga ändringar görs använder App Service befintliga lager på den lokala disken.

Om appen ändrar beräkningsinstanser av någon anledning, till exempel att skala upp och ned prisnivåerna, måste App Service dra ned alla lager igen. Detsamma gäller om du skalar ut för att lägga till fler instanser. Det finns också sällsynta fall då appinstanser kan ändras utan att en skalningsåtgärd sker.

Konfigurera portnummer

Som standard förutsätter App Service att din anpassade container lyssnar på port 80. Om containern lyssnar på en annan port anger du appinställningen WEBSITES_PORT i App Service-appen. Du kan ange det med hjälp av Cloud Shell-. I Bash-kommandoraden:

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

I PowerShell:

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

Med App Service kan din container för närvarande endast exponera en port för HTTP-begäranden.

Konfigurera miljövariabler

Din anpassade container kan använda miljövariabler som måste anges externt. Du kan använda Cloud Shellför att skicka in dem. I Bash:

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

I PowerShell-verktyg:

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

När appen körs matas App Service-appinställningarna in i processen som miljövariabler automatiskt. Du kan verifiera miljövariabler för containrar med URL:en https://<app-name>.scm.azurewebsites.net/Env.

Om appen använder avbildningar från ett privat register eller från Docker Hub sparas autentiseringsuppgifter för åtkomst till lagringsplatsen i miljövariabler: DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAMEoch DOCKER_REGISTRY_SERVER_PASSWORD. På grund av säkerhetsrisker exponeras inget av dessa reserverade variabelnamn för programmet.

För IIS- eller .NET Framework-baserade containrar (4.0 eller senare) matas autentiseringsuppgifterna in i System.ConfigurationManager som .NET-appinställningar och anslutningssträngar automatiskt av App Service. För alla andra språk eller ramverk tillhandahålls de som miljövariabler för processen, med något av följande prefix:

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

Den här metoden fungerar både för appar med en container eller appar med flera containrar, där miljövariablerna anges i filen docker-compose.yml .

Använda beständig delad lagring

Du kan använda katalogen C:\home i ditt anpassade containerfilsystem för att spara filer mellan omstarter och dela dem mellan instanser. Katalogen C:\home tillhandahålls för att ge din anpassade container åtkomst till beständig lagring.

När beständig lagring är inaktiverad sparas inte skrivningar till C:\home-katalogen över appomstarter eller mellan flera instanser. När beständig lagring är aktiverat sparas alla skrivningar till C:\home katalog. Alla instanser av en skalad ut app kan ha åtkomst till dem. Alla befintliga filer som redan finns på den beständiga lagringen när containern börjar skriva över allt innehåll i C:\home-katalogen i containern.

Det enda undantaget är katalogen C:\home\LogFiles. Den här katalogen lagrar container- och programloggarna. Den här mappen bevaras alltid när appen startas om om programloggning är aktiverad med alternativet Filsystem, oavsett om beständig lagring är aktiverat eller inte. Att aktivera eller inaktivera den beständiga lagringen påverkar med andra ord inte programmets loggningsbeteende.

Som standard är beständig lagring aktiverat i windows anpassade containrar. Om du vill inaktivera det anger du värdet för appinställningen WEBSITES_ENABLE_APP_SERVICE_STORAGE till false genom att använda Cloud Shell. I Bash:

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

I PowerShell:

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

Du kan använda katalogen /home i ditt anpassade containerfilsystem för att spara filer mellan omstarter och dela dem mellan instanser. Katalogen /home tillhandahålls för att möjliggöra din anpassade container att få åtkomst till beständig lagring. Om du sparar data i /home- bidrar du till lagringsutrymmeskvot ingår i din App Service-plan.

När beständig lagring är inaktiverad sparas inte skrivningar till C:\home mapp vid appomstarter eller mellan flera instance. När beständiga lagring är aktiverat sparas alla skrivningar till katalogen \home. Alla instanser av en utskalad app kan komma åt dem. Alla befintliga filer som redan finns på den beständiga lagringen när containern börjar skriva över allt innehåll i \home-katalogen i containern.

Det enda undantaget är katalogen \home\LogFiles. Den här katalogen lagrar container- och programloggarna. Den här mappen bevaras alltid när appen startas om om programloggning är aktiverad med alternativet Filsystem, oavsett om beständig lagring är aktiverat eller inte. Att aktivera eller inaktivera den beständiga lagringen påverkar med andra ord inte programmets loggningsbeteende.

Vi rekommenderar att du skriver data till /home eller en monterad Azure-lagringsväg. Data som skrivs utanför dessa sökvägar är inte beständiga under omstarter. Data sparas till plattformshanterat värddiskutrymme separat från Fillagringskvoten för App Service-planer.

Som standard inaktiveras beständig lagring på anpassade Linux-containrar. För att aktivera det, ställ in WEBSITES_ENABLE_APP_SERVICE_STORAGE appinställningsvärdet till true med Cloud Shell. I Bash:

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

I PowerShell:

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

Anmärkning

Du kan också konfigurera din egen beständiga lagring.

Identifiera HTTPS-sessionen

App Service avslutar TLS i klientdelen. Det innebär att TLS-begäranden aldrig kommer till din app. Du behöver inte och bör inte implementera något stöd för TLS i din app.

Frontändarna är placerade i Azure-datacenter. Om du använder TLS med din app krypteras alltid trafiken via Internet på ett säkert sätt.

Anpassa ASP.NET maskinnyckelinmatning

Under containerstarten matas automatiskt genererade nycklar in i containern som datornycklar för ASP.NET kryptografiska rutiner. Du hittar dessa nycklar i containern genom att leta efter följande miljövariabler: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, MACHINEKEY_Validation.

De nya nycklarna vid varje omstart kan återställa ASP.NET formulärautentisering och visningstillstånd, om din app är beroende av dem. Om du vill förhindra automatisk återställning av nycklar anger du dem manuellt som App Service-appinställningar.

Ansluta till containern

Om du vill ansluta direkt till Windows-containern för diagnostikuppgifter går du till https://<app-name>.scm.azurewebsites.net/ och väljer alternativet SSH. Det här alternativet etablerar en direkt SSH-session där du kan köra kommandon i containern.

  • Den fungerar separat från den grafiska webbläsaren ovanför den, som bara visar filerna i din delade lagring.
  • I en utskalad app är SSH-sessionen ansluten till en av containerinstanserna. Du kan välja en annan instans från listrutan Instans i den översta Kudu-menyn.
  • Förutom ändringar i det delade lagringsutrymmet sparas inte alla ändringar du gör i containern inifrån SSH-sessionen inte sparas när appen startas om. Sådana ändringar är inte en del av Docker-avbildningen. Om du vill spara ändringarna, till exempel registerinställningar och programvaruinstallation, gör du dem till en del av Dockerfile.

Få åtkomst till diagnostikloggar

App Service loggar åtgärder utförda av Docker-värden och aktiviteter inifrån containern. Loggar från Docker-värden (plattformsloggar) är aktiverade som standard. Du måste aktivera programloggar eller webbserverloggar manuellt inifrån containern. Mer information finns i Aktivera programloggning och Aktivera webbserverloggning.

Det finns flera sätt att komma åt Docker-loggar:

I Azure-portalen

Docker-loggar visas i Azure-portalen på sidan Containerinställningar i din app. Loggarna är avkortade. Om du vill ladda ned alla loggar väljer du Ladda ned.

Från Kudu

Om du vill se de enskilda loggfilerna går du till https://<app-name>.scm.azurewebsites.net/DebugConsole och väljer mappen LogFiles. Om du vill ladda ned hela katalogen LogFiles väljer du ikonen Ladda ned till vänster om katalognamnet. Du kan också komma åt den här mappen med hjälp av en FTP-klient.

I SSH-terminalen kan du inte komma åt C:\home\LogFiles mapp som standard eftersom beständig delad lagring inte är aktiverad. Aktivera beständig delad lagring om du vill aktivera det här beteendet i konsolterminalen.

Om du försöker ladda ned Docker-loggen som för närvarande används med hjälp av en FTP-klient kan du få ett fel på grund av ett fillås.

Med Kudu-API:et

Navigera direkt till för att https://<app-name>.scm.azurewebsites.net/api/logs/docker se metadata för Docker-loggarna. Du kan se fler än en loggfil i listan. Med egenskapen href kan du ladda ned loggfilen direkt.

Om du vill ladda ned alla loggar tillsammans i en ZIP-fil öppnar du https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip.

Anpassa containerminne

Som standard har alla Windows-containrar som distribuerats i Azure App Service en konfigurerad minnesgräns. I följande tabell visas standardinställningarna per App Service Plan SKU.

App Service Plan-produkt SKU Standardminnesgräns per app i MB
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

Du kan ändra det här värdet genom att ange appinställningen WEBSITE_MEMORY_LIMIT_MB med hjälp av Cloud Shell-. I Bash-miljön

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

I PowerShell:

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

Värdet definieras i MB och måste vara mindre än eller lika med det fysiska minnet på värden. I till exempel en App Service-plan med 8 GB RAM-minne får den kumulativa summan av WEBSITE_MEMORY_LIMIT_MB för alla appar inte överstiga 8 GB. Mer information om hur mycket minne som är tillgängligt finns i avsnittet Premium v3-tjänstplan i App Service-prissättning.

Anpassa antalet beräkningskärnor

Som standard körs en Windows-container med alla tillgängliga kärnor för den valda prisnivån. Du kanske vill minska antalet kärnor som ditt mellanlagringsfack använder. Om du vill minska antalet kärnor som används av en container anger du appinställningen WEBSITE_CPU_CORES_LIMIT till önskat antal kärnor. Du kan ange det med hjälp av Cloud Shell-. I Bash:

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

I PowerShell:

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

Tips

Om du uppdaterar appinställningen utlöses automatisk omstart, vilket orsakar minimal stilleståndstid. För en produktionsapp bör du överväga att byta ut den till en mellanlagringsplats, ändra appinställningen i mellanlagringsplatsen och sedan växla tillbaka den till produktion.

Om du vill verifiera ditt justerade nummer öppnar du en SSH-session från Azure-portalen eller använder Kudu-portalen (https://<app-name>.scm.azurewebsites.net/webssh/host). Ange följande kommandon med PowerShell. Varje kommando returnerar ett tal.

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

Processorerna kan vara processorer med flera kärnor eller hypertrådning. Information om hur många kärnor som är tillgängliga finns i avsnittet Premium v3-tjänstplan i App Service-prissättning.

Anpassa beteende för hälso ping

App Service anser att en container har startats när containern startar och svarar på en HTTP-ping. Begäran om hälsoping innehåller rubriken User-Agent= "App Service Hyper-V Container Availability Check". Om containern startar men inte svarar på ping efter en viss tid loggar App Service en händelse i Docker-loggen.

Om ditt program är resursintensivt kanske containern inte svarar på HTTP-pingen i tid. Om du vill styra åtgärderna när HTTP-ping misslyckas anger du appinställningen CONTAINER_AVAILABILITY_CHECK_MODE . Du kan ange det med hjälp av Cloud Shell-. i Bash:

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

I PowerShell:

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

Följande tabell visar möjliga värden:

Värde Beskrivningar
Reparera Starta om containern efter tre på varandra följande tillgänglighetskontroller.
ReportOnly Standardvärdet. Starta inte om containern utan rapportera i Docker-loggarna för containern efter tre på varandra följande tillgänglighetskontroller.
Av Sök inte efter tillgänglighet.

Stöd för grupphanterade tjänstkonton

Grupphanterade tjänstkonton (gMSAs) stöds för närvarande inte i Windows-containrar i App Service.

Aktivera SSH

Secure Shell (SSH) används ofta för att fjärrköra administrativa kommandon från en kommandoradsterminal. Följ dessa steg för att aktivera SSH-konsolfunktionen i Azure-portalen med anpassade containrar:

  1. Skapa en standardfil sshd_config med följande exempelinnehåll och placera den i programprojektets rotkatalog:

    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

    Anteckning

    Den här filen konfigurerar OpenSSH och måste innehålla följande objekt för att uppfylla Azure Portal SSH-funktionen:

    • Port måste anges till 2222.
    • Ciphersmåste innehålla minst ett objekt i listan: aes128-cbc,3des-cbc,aes256-cbc.
    • MACsmåste innehålla minst ett objekt i listan: hmac-sha1,hmac-sha1-96.

  2. Skapa ett entrypoint-skript med namnet entrypoint.sh eller ändra en befintlig postpunktsfil. Lägg till kommandot för att starta SSH-tjänsten tillsammans med programmets startkommando. I följande exempel visas hur du startar ett Python-program. Ersätt det sista kommandot enligt projektspråket/-stacken:

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

  3. Lägg till följande instruktioner i Dockerfile enligt distributionen av basavbildningen. De här anvisningarna kopierar de nya filerna, installerar OpenSSH-servern, anger rätt behörigheter och konfigurerar den anpassade startpunkten och exponerar de portar som krävs av programmet respektive SSH-servern:

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

    Kommentar

    Rotlösenordet måste vara exakt Docker! eftersom det används av App Service för att du ska få åtkomst till SSH-sessionen med containern. Den här konfigurationen tillåter inte externa anslutningar till containern. Port 2222 för containern är endast tillgänglig i bryggnätverket i ett privat virtuellt nätverk och är inte tillgänglig för en angripare på Internet.

  4. Återskapa och push-överför Docker-avbildningen till registret och testa sedan funktionen Web App SSH i Azure-portalen.

Mer felsökningsinformation finns i Azure App Service-bloggen: Aktivera SSH på Linux Web App for Containers

Få åtkomst till diagnostikloggar

Du kan komma åt konsolloggarna som genereras inifrån containern.

Om du vill aktivera containerloggning kör du följande kommando:

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

Ersätt <app-name> och <resource-group-name> med namn som är lämpliga för din webbapp.

När du har aktiverat containerloggning kör du följande kommando för att se loggströmmen:

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

Om konsolloggarna inte visas omedelbart kontrollerar du igen om 30 sekunder.

Om du vill stoppa loggströmningen när som helst väljer du Ctrl+C.

Du kan också granska loggfilerna i en webbläsare på https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Konfigurera appar med flera containrar

Anteckning

Sidvagnscontainrar ersätter appar med flera containrar i App Service. Kom igång genom att läsa Självstudie: Konfigurera en sidovagnscontainer för anpassad container i Azure App Service.

Använda beständig lagring i Docker Compose

Appar med flera containrar som WordPress behöver beständig lagring för att fungera korrekt. Om du vill aktivera den måste docker Compose-konfigurationen peka på en lagringsplats utanför containern. Lagringsplatser i containern bevarar inte ändringar efter omstart av appen.

Om du vill aktivera beständig lagring anger du inställningen WEBSITES_ENABLE_APP_SERVICE_STORAGE app. Använd kommandot az webapp config appsettings set i Cloud Shell.

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

I filen docker-compose.yml mappar du volumes alternativet till ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME är en miljövariabel i App Service som är mappad till beständig lagring för din app. Till exempel:

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"

Begränsningar i förhandsversionen

Flera containrar är för närvarande i förhandsversion. Följande App Service-plattformsfunktioner stöds inte:

  • Autentisering/auktorisering
  • Hanterade identiteter
  • CORS
  • Integrering av virtuella nätverk stöds inte för Docker Compose-scenarier.
  • Docker Compose i Azure App Services har för närvarande en gräns på 4 000 tecken för tillfället.

Alternativ för Docker Compose

Följande listor visar konfigurationsalternativ för Docker Compose som stöds och inte stöds:

Alternativ som stöds

Alternativ som inte stöds

  • bygga (inte tillåtet)
  • beror_på (ignoreras)
  • nätverk (ignoreras)
  • hemligheter (ignoreras)
  • andra portar än 80 och 8080 (ignoreras)
  • standardmiljövariabler som $variable and ${variable} till skillnad från i docker

Syntaxbegränsningar

  • "version x.x" måste alltid vara den första YAML-instruktionen i filen
  • portavsnittet måste använda angivna nummer
  • Bildvolymsavsnittet > måste citatmarkeras och kan inte ha behörighetsdefinitioner
  • volymavsnittet får inte ha en tom klammerparentes efter volymnamnet

Kommentar

Andra alternativ som inte uttryckligen framhävs ignoreras i den offentliga förhandsversionen.

Ignorera robots933456-meddelandet i loggar

Du kan se följande meddelande i containerloggarna:

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

Du kan ignorera det här meddelandet. /robots933456.txt är en dummysökväg som App Service använder för att kontrollera om containern kan hantera förfrågningar. Ett 404-svar anger att sökvägen inte finns och signalerar till App Service att containern är felfri och redo att svara på begäranden.

Relaterat innehåll

Självstudie: Migrera anpassad programvara till Azure App Service med hjälp av en anpassad container

Självstudie: Konfigurera en sidovagnscontainer för anpassad container i Azure App Service

Eller se fler resurser: