Dela via

Konfigurera en anpassad container för Azure App Service

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

Lär dig mer om viktiga begrepp och få instruktioner för containerisering av Windows-appar i App Service. Nya användare bör först följa snabbstarten och självstudien för anpassad container.

Lär dig mer om viktiga begrepp och få instruktioner för containerisering av Linux-appar i App Service. Nya användare bör först följa snabbstart för anpassad container och sedan handledning. För sidovagnscontainrar, se Självstudie: Konfigurera en sidovagnscontainer för anpassad container i Azure App Service.

Anmärkning

Det går inte längre att använda en tjänsthuvudman för pull-autentisering av Windows-containeravbildningar. Vi rekommenderar att du använder hanterad identitet för både Windows- och Linux-containrar.

Överordnade avbildningar som stöds

Välj rätt överordnad avbildning (basavbildning) för det ramverk som du vill använda för din anpassade Windows-avbildning:

  • Om du vill distribuera .NET Framework-appar använder du en överordnad avbildning baserat på Windows Server 2019 Core Long-Term Servicing Channel-versionen .
  • Om du vill distribuera .NET Core-appar använder du en överordnad avbildning baserad på Windows Server 2019 Nano Annual Channel-utgåvan.

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

Använd följande kommando för att ändra den aktuella Docker-avbildningen till en ny avbildning i en befintlig anpassad container:

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 i fälten \<username> och \<password> .

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

Använd följande steg för att konfigurera webbappen att hämta från Azure Container Registry 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 <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 ditt containerregister:

    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 containerregistret.

  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>"}'

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ätverket och DNS-upplösningen aktiverar du dirigeringen av bildhämtningen genom det virtuella nätverket. Konfigurera webbplatsinställningen vnetImagePullEnabled :

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

Felsöka vad du ska göra om du inte ser 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. App Service skickar endast begäranden till den nya containern när den har startats och är redo att ta emot begäranden.

Lär dig hur containeravbildningar lagras

Första gången du kör en anpassad Docker-avbildning i App Service kommer kommandot docker pull att utföras av App Service och alla avbildningslager kommer att hämtas. Lagren lagras på disken, på samma sätt som när du använder Docker lokalt. Varje gång appen startas om utför docker pull App Service kommandot . 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 (som att ändra prisnivåer) måste App Service hämta alla lager igen. Detsamma gäller om du skalar ut för att lägga till fler instanser. I sällsynta fall kan appinstanserna ändras utan en skalningsoperation.

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 Azure Cloud Shell. Använd följande kommando i Bash:

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

Använd följande kommando 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 du behöver ange externt. Du kan skicka in dem med hjälp av Cloud Shell. Använd följande kommando i Bash:

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

Använd följande kommando 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 automatiskt in i processen som miljövariabler. Du kan verifiera miljövariabler för containrar med URL:en https://<app-name>.scm.azurewebsites.net/Env.

När du SSH till en container med anpassade Docker-avbildningar kanske du bara ser några miljövariabler om du försöker använda kommandon som env eller printenv. Om du vill se alla miljövariabler i containern, som de som du skickar in till ditt program för körningsanvändning, lägger du till den här raden i ditt entrypoint-skript:

eval $(printenv | sed -n "s/^\([^=]\+\)=\(.*\)$/export \1=\2/p" | sed 's/"/\\\"/g' | sed '/=/s//="/' | sed 's/$/"/' >> /etc/profile)

Se ett fullständigt exempel.

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_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-containrar (Internet Information Services) eller .NET Framework-containrar (4.0 eller senare) matas autentiseringsuppgifter automatiskt in i System.ConfigurationManager som .NET-appinställningar och anslutningssträngar 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_

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

Använda beständig delad lagring

Du kan använda C:\home katalogen i ditt anpassade containerfilsystem för att spara filer mellan omstarter och dela dem mellan instanser. När du använder C:\home katalogen kan din anpassade container 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. Alla instanser av en skalad ut app kan ha åtkomst till dem. När containern startar skriver de över allt innehåll i C:\home containerns katalog om det finns några filer på den beständiga lagringen.

Det enda undantaget är C:\home\LogFiles katalogen. Den här katalogen lagrar container- och programloggarna. Mappen bevaras alltid när appen startas om om programloggning är aktiverad med alternativet Filsystem , oavsett om beständig lagring är aktiverat eller inte. När du aktiverar eller inaktiverar beständig lagring påverkar det 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 med false hjälp av Cloud Shell. Använd följande kommando i Bash:

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

Använd följande kommando i PowerShell:

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

Du kan använda /home katalogen i ditt anpassade containerfilsystem för att spara filer mellan omstarter och dela dem mellan instanser. När du använder C:\home katalogen kan din anpassade container komma åt beständig lagring. Tänk på att data som du sparar inom /home bidrar till den lagringskvot som ingår i din App Service-plan.

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. Alla instanser av en skalad ut app kan ha åtkomst till dem. När containern startar skriver de över allt innehåll i C:\home containerns katalog om det finns några filer på den beständiga lagringen.

Det enda undantaget är C:\home\LogFiles katalogen. Den här katalogen lagrar container- och programloggarna. Mappen bevaras alltid när appen startas om om programloggning är aktiverad med alternativet Filsystem , oavsett om beständig lagring är aktiverat eller inte. När du aktiverar eller inaktiverar beständig lagring påverkar det med andra ord inte programmets loggningsbeteende.

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

Som standard inaktiveras beständig lagring på anpassade Linux-containrar. Om du vill aktivera det, använd Cloud Shell för att ställa in värdet på appinställningen till true. Använd följande kommando i Bash:

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

Använd följande kommando 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 vid frontändarna. 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.

Frontend-komponenterna finns inne 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 genereras nycklar automatiskt och matas 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_ValidationKeyoch 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 till din Windows-container direkt 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 ansluter SSH-sessionen 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 som du gör i containern inifrån SSH-sessionen när appen startas om. Dessa ändringar är inte en del av Docker-avbildningen. Om du vill spara ändringar som 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.

Du kan komma åt Docker-loggar på flera sätt:

Azure-portalen

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

Kudu

Om du vill se de enskilda loggfilerna går du till https://<app-name>.scm.azurewebsites.net/DebugConsole och väljer LogFiles mappen. 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.

Som standard kan du inte komma åt C:\home\LogFiles mappen i SSH-terminalen 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.

Kudu API

Gå direkt till https://<app-name>.scm.azurewebsites.net/api/logs/docker för att se metadata för Docker-loggarna. Du kan se fler än en loggfil i listan. Du kan använda egenskapen href för att 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.

SKU för App Service-plan 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 i Cloud Shell. Använd följande kommando i Bash:

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

Använd följande kommando 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 värdmaskinens totala fysiska minne. I till exempel en App Service-plan med 8 GB RAM-minne får den kumulativa summan WEBSITE_MEMORY_LIMIT_MB för alla appar inte överstiga 8 GB. Mer information om hur mycket minne som är tillgängligt finns i Premium v3-tjänstplanen i App Service-priser.

Anpassa antalet beräkningskärnor

Som standard körs en Windows-container med alla tillgängliga kärnor för din prisnivå. Du kanske vill minska antalet kärnor som ditt mellanlagringsfack använder. Om du vill minska antalet kärnor som en container använder anger du appinställningen WEBSITE_CPU_CORES_LIMIT till det önskade antalet kärnor. Du kan ange det med hjälp av Cloud Shell. Använd följande kommando i Bash:

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

Använd följande kommando 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 staging-slotten och flytta den sedan tillbaka till produktion.

Om du vill verifiera ditt justerade nummer öppnar du en SSH-session med hjälp av Azure-portalen eller Kudu-portalen (https://<app-name>.scm.azurewebsites.net/webssh/host). Ange följande kommandon med hjälp av 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 Premium v3-tjänstplanen i App Service-priser.

Anpassa beteende för hälsoping

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 vad som händer när HTTP-ping misslyckas anger du appinställningen CONTAINER_AVAILABILITY_CHECK_MODE . Du kan ange det med hjälp av Cloud Shell. Använd följande kommando i Bash:

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

Använd följande kommando 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 Description
Repair Starta om containern efter tre på varandra följande tillgänglighetskontroller.
ReportOnly Standardvärdet. Rapportera containern i Docker-loggarna efter tre på varandra följande tillgänglighetskontroller, men starta inte om den.
Off Sök inte efter tillgänglighet.

Stöd för grupphanterade tjänstkonton

Grupphanterade tjänstkonton stöds inte i Windows-containrar i App Service.

Aktivera SSH

Du kan använda Secure Shell (SSH) 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

    Anmärkning

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

    • Värdet Port måste anges till 2222.
    • Värdena Ciphers måste innehålla minst ett objekt i den här listan: aes128-cbc, 3des-cbceller aes256-cbc.
    • Värdena MACs måste innehålla minst ett objekt i den här listan: hmac-sha1 eller 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 eller 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 basbildens distribution. Dessa instruktioner 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" ]

    Anmärkning

    Rotlösenordet måste vara exakt Docker! eftersom App Service använder det för att ge dig åtkomst till SSH-sessionen med containern. Den här konfigurationen tillåter inte externa anslutningar till containern. Containerporten 2222 är endast tillgänglig i bryggnätverket i ett privat virtuellt nätverk. En angripare på Internet kan inte komma åt den.

  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å en Linux-webbapp för containrar.

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

<app-name> Ersätt värdena 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 använder du kortkommandot Ctrl+C.

Konfigurera appar med flera containrar

Anmärkning

Docker Compose-funktionen kommer att dras tillbaka den 31 mars 2027. Sidvagnscontainrar ersätter appar med flera containrar i App Service. För nya tjänster, se Självstudie: Konfigurera en sidecar-container för anpassad container i Azure App Service. För befintliga appar med flera containrar i App Service, se Migrera dina Docker Compose-program till sidovagnsfunktionen.

Använda beständig lagring i Docker Compose

Appar med flera containrar som WordPress behöver beständig lagring för att fungera korrekt. För att aktivera beständig lagring 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. az webapp config appsettings set Använd kommandot i Cloud Shell.

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

I din docker-compose.yml-fil, mappa alternativet volumes till ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME är en miljövariabel i App Service som mappar 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

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

  • Autentisering eller auktorisering.
  • Hanterade identiteter.
  • Resursdelning mellan ursprung (CORS).
  • Integrering av virtuella nätverk med Docker Compose-scenarier.

Docker Compose i Azure App Service har för närvarande en gräns på 4 000 tecken.

Alternativ för Docker Compose

Följande avsnitt visar konfigurationsalternativ för Docker Compose som stöds och inte stöds.

Alternativ som stöds

Alternativ som inte stöds

  • build (tillåts inte)
  • depends_on (ignoreras)
  • networks (ignoreras)
  • secrets (ignoreras)
  • Andra portar än 80 och 8080 (ignoreras)
  • Standardmiljövariabler som $variable och ${variable} (till skillnad från i Docker)

Syntaxbegränsningar

  • Den första YAML-instruktionen i filen måste alltid vara version x.x.
  • Portavsnittet måste använda citerade tal.
  • Avsnittet image > volume måste anges och kan inte ha behörighetsdefinitioner.
  • Avsnittet volymer kan inte innehålla en tom klammerparentes efter volymnamnet.

Anmärkning

Andra alternativ som inte uttryckligen nämns ignoreras i 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 dummy-URL-sökväg. App Service använder den för att kontrollera om containern kan hantera begäranden. Ett "404"-felsvar 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

  • Last updated on