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ölja snabbstarten och självstudiekursen för den anpassade containern först.

Den här guiden innehåller viktiga begrepp och instruktioner för containerisering av Linux-appar i App Service. Om är nya för Azure App Service följer du snabbstarten och självstudiekursen för den anpassade containern först. Det finns också en snabbstart och självstudiekurs för flera containerappar. För sidovagnscontainrar (förhandsversion) finns i Självstudie: Konfigurera en sidovagnscontainer för anpassad container i Azure App Service (förhandsversion).

Kommentar

Tjänstens huvudnamn stöds inte längre för pull-autentisering för Windows-containeravbildningar. Det rekommenderade sättet är att använda hanterad identitet för både Windows- och Linux-containrar

Överordnade avbildningar som stöds

För din anpassade Windows-avbildning måste du välja rätt överordnad avbildning (basavbildning) för det ramverk du vill ha:

Det tar lite tid att ladda ned en överordnad avbildning när appen startas. Men du kan minska starttiden genom att använda någon av följande överordnade avbildningar som redan har cachelagrats i 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

Ä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 inloggningsuppgifterna för ditt privata registerkonto för användarnamn> och <lösenord>.<

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, men du kan också använda användartilldelad hanterad identitet.

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

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

    Ersätt <app-name> med det namn som 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

    Byt ut <registry-name> mot namnet på ditt register. Utdata från kommandot (filtrerat efter argumenten --query och --output ) är resurs-ID:t 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 värden:

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

    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 värden:

    • <app-name> med namnet på webbappen.

    Dricks

    Om du använder PowerShell-konsolen för att köra kommandona måste du fly från strängarna --generic-configurations i argumentet i det här 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 den <identity-name> användartilldelade hanterade identiteten och använd utdata <client-id> för att konfigurera det användartilldelade hanterade identitets-ID:t.

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

Allt är klart och 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 (VNET). VNET-integrering krävs också för Azure Container Registry med en privat slutpunkt. När nätverket och DNS-matchningen har konfigurerats aktiverar du routningen av avbildningen 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 Service ett docker pull, men hämtar bara 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är appinstanserna kan ändras utan en skalningsåtgärd.

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 den via Cloud Shell. I Bash:

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 skicka in dem via Cloud Shell. I Bash:

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

I PowerShell:

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 autentiseringsuppgifterna för åtkomst till lagringsplatsen i miljövariablerna: DOCKER_REGISTRY_SERVER_URLoch DOCKER_REGISTRY_SERVER_USERNAMEDOCKER_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 de in som System.ConfigurationManager .NET-appinställningar och anslutningssträng 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 motsvarande 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 göra det möjligt för din anpassade container att komma åt beständig lagring.

När beständig lagring är inaktiverad sparas inte skrivningar till C:\home katalogen mellan appomstarter eller flera instanser. När beständig lagring är aktiverat sparas alla skrivningar till C:\home katalogen och kan nås av alla instanser av en utskalad app. Dessutom skrivs allt innehåll i C:\home containerns katalog över av befintliga filer som redan finns på den beständiga lagringen när containern startar.

Det enda undantaget är katalogen C:\home\LogFiles som används för att lagra container- och programloggarna. Den här mappen bevaras alltid när appen startas om om programloggning är aktiverad med alternativet Filsystem , oberoende av den beständiga lagring som aktiveras eller inaktiveras. Att aktivera eller inaktivera den beständiga lagringen påverkar med andra ord inte programmets loggningsbeteende.

Som standard inaktiveras beständig lagring på anpassade Windows-containrar. Om du vill aktivera det anger du värdet för appinställningen WEBSITES_ENABLE_APP_SERVICE_STORAGEtill true via 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}

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 göra det möjligt för din anpassade container att komma åt beständig lagring. Att spara data i /home bidrar till den lagringskvot som ingår i din App Service-plan.

När beständig lagring är inaktiverad sparas inte skrivningar till /home katalogen mellan appomstarter eller flera instanser. När beständig lagring är aktiverat sparas alla skrivningar till /home katalogen och kan nås av alla instanser av en utskalad app. Dessutom skrivs allt innehåll i /home containerns katalog över av befintliga filer som redan finns på den beständiga lagringen när containern startar.

Det enda undantaget är katalogen /home/LogFiles som används för att lagra container- och programloggarna. Den här mappen bevaras alltid när appen startas om om programloggning är aktiverad med alternativet Filsystem , oberoende av den beständiga lagring som aktiveras eller inaktiveras. 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-lagringssökväg. Data som skrivs utanför dessa sökvägar är inte beständiga under omstarter och sparas i plattformshanterat värddiskutrymme separat från Fillagringskvoten för App Service-planer.

Som standard är beständig lagring aktiverat på anpassade Linux-containrar. Om du vill inaktivera det anger du värdet för appinställningen WEBSITES_ENABLE_APP_SERVICE_STORAGEtill false via 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}

Kommentar

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

Identifiera HTTPS-sessionen

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

Klientdelarna finns i Azure-datacenter. Om du använder TLS/SSL med din app krypteras alltid trafiken över 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.

Anslut till containern

Du kan ansluta till din Windows-container direkt för diagnostikuppgifter genom att navigera till https://<app-name>.scm.azurewebsites.net/ och välja SSH-alternativet. En direkt SSH-session med containern upprättas 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.
  • Alla ändringar du gör i containern inifrån SSH-sessionen sparas inte när din app startas om (förutom ändringar i det delade lagringsutrymmet), eftersom den inte är 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 av Docker-värden och aktiviteter inifrån containern. Loggar från Docker-värden (plattformsloggar) levereras som standard, men programloggar eller webbserverloggar inifrån containern måste aktiveras manuellt. 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 portalen på sidan Container Inställningar i din app. Loggarna trunkeras, men du kan ladda ned alla loggar som väljer Ladda ned.

Från Kudu

Gå till https://<app-name>.scm.azurewebsites.net/DebugConsole och välj mappen LogFiles för att se de enskilda loggfilerna. Om du vill ladda ned hela LogFiles-katalogen 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 mappen 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, och med href egenskapen 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 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_MBvia Cloud Shell. I Bash:

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 och lika med värdens totala fysiska minne. I en App Service-plan med 8 GB RAM får den kumulativa summan WEBSITE_MEMORY_LIMIT_MB för alla appar till exempel inte överstiga 8 GB. Information om hur mycket minne som är tillgängligt för varje prisnivå finns i App Service-priser i avsnittet Premium v3-tjänstplan .

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, till exempel. 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 den via 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}

Kommentar

Uppdatering av appinställningen utlöser 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.

Kontrollera ditt justerade nummer genom att öppna en SSH-session från portalen eller via Kudu-portalen (https://<app-name>.scm.azurewebsites.net/webssh/host) och skriva följande kommandon med powershell. Varje kommando matar ut 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 för varje prisnivå finns i App Service-priser i avsnittet Premium v3-tjänstplan .

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älsot ping 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 och säger att containern inte startade.

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 den via 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
Reparation 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 köra administrativa kommandon via fjärranslutning från en kommandoradsterminal. För att aktivera SSH-konsolfunktionen i Azure-portalen med anpassade containrar krävs följande steg:

  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

    Kommentar

    Den här filen konfigurerar OpenSSH och måste innehålla följande objekt för att uppfylla azure-portalens SSH-funktion:

    • 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) och lägg till kommandot för att starta SSH-tjänsten, tillsammans med kommandot start av programmet. 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 basavbildningsdistributionen. 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! som det används av App Service för att du ska kunna komma åt 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 webbappens SSH-funktion på Azure-portalen.

Ytterligare felsökningsinformation finns på 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.

Aktivera först containerloggning genom att köra 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 de namn som är lämpliga för din webbapp.

När containerloggning har aktiverats kör du följande kommando för att visa loggströmmen:

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

Om du inte ser konsolloggarna omedelbart kan du titta efter igen efter 30 sekunder.

Om du vill stoppa loggströmningen när som helst skriver 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

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.

Aktivera beständig lagring genom att ange appinställningen WEBSITES_ENABLE_APP_SERVICE_STORAGEmed 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

  • build (inte tillåtet)
  • depends_on (ignoreras)
  • networks (ignoreras)
  • secrets (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
  • avbildningsvolymavsnittet > måste anges 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.

robots933456 i loggar

Följande meddelande kan visas 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 för URL:en som App Service använder till att kontrollera om containern kan hantera begäranden. Ett 404-svar innebär helt enkelt att sökvägen inte finns, men det låter App Service veta att containern är felfri och redo att svara på begäranden.

Nästa steg

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

Självstudie: WordPress-app med flera containrar

Eller se fler resurser: