Öppna ett container shell (SSH) och kör kommandon i Azure App Service

App Service ger webbläsarbaserad SSH-åtkomst till appar som körs i Windows-anpassade containrar. Ingen särskild bildkonfiguration krävs för webbläsarsessionen.

Azure CLI-kommandot az webapp exec stöds endast för Linux-webbappar. Använd inte CLI-exemplen för Linux i denna artikel för Windows App Service-planer.

För inbyggda och anpassade Linux-containrar använder den nyare webbläsarterminalen och az webapp exec Kudu som en autentiserad proxy för att ansluta till den körande containern. Dessa alternativ kräver inte att du installerar en SSH-server, bäddar in ett SSH-lösenord, exponerar en SSH-port eller startar en SSH-daemon i din anpassade image. Legacy Kudu WebSSH och az webapp ssh åtkomst kan fortfarande kräva en SSH-server i en anpassad image.

Använd Azure-portalen för en webbläsarsession, eller använd förhandsgranskningskommandot az webapp exec för en lokal terminalsession eller frikopplad kommandoexekvering. Webbläsarterminalen kräver att /bin/bash finns i avbilden och stöder för närvarande inte att välja en annan shell. Om bilden har ett annat shell, använd az webapp exec --shell /bin/sh istället. Bilder utan shell, inklusive distrolösa bilder, kan inte öppna en interaktiv session.

• För CLI-exemplen, installera Azure CLI 2.90.0 eller senare och logga in. Kontrollera din version med az version. Du kan också använda Azure Cloud Shell om dess CLI uppfyller detta krav.
• För en interaktiv CLI-session, använd en interaktiv terminal och ett skal som finns i din avbild. Standard är /bin/bash; för en bild utan bash, ange --shell /bin/sh om det skalet är tillgängligt.

Öppna SSH-session med Azure CLI

Förhandsgranskningskommandot az webapp exec öppnar ett interaktivt skal i appens huvudcontainer. Sessionen använder din lokala terminal på Windows, macOS och Linux; den öppnar ingen webbläsare.

az webapp exec --resource-group <resource-group-name> --name <app-name>

För en bild som använder /bin/sh istället för bash:

az webapp exec --resource-group <resource-group-name> --name <app-name> --shell /bin/sh

Du kan köra kommandon och inspektera deras utdata i denna session. Till exempel, använd top om det är installerat i avbilden. För att inspektera SCM/Kudu-containern istället för appcontainern:

az webapp exec --resource-group <resource-group-name> --name <app-name> --target kudu

Appen och Kudu-containrarna är olika miljöer. Kör kommandon som är beroende av appens körtid, beroenden eller nätverksanslutning i appcontainern.

Välj en instans eller distributionsfack

Som standard ansluter CLI:n till en appinstans. För att hitta instans-ID:n:

az webapp list-instances --resource-group <resource-group-name> --name <app-name> --output table

För att koppla till en specifik instans:

az webapp exec --resource-group <resource-group-name> --name <app-name> --instance <instance-id>

Lägg till --slot <slot-name> för att få tillgång till ett distributionsfack. När du väljer en slots instans, lägg också till --slot till az webapp list-instances

Interaktivt skalläge stöder endast en instans åt gången.

Kör kommandon utan en interaktiv session

Använd --mode execute för att skicka ett kommando till huvudapplikationscontainern utan att öppna en terminalsession. Kommandot körs i frånkopplat läge. Detta läge är användbart för bakgrundsdiagnostik eller annat arbete som inte kräver omedelbar utdata.

Kör ett program direkt

Använd --command för att specificera ett program och dess argument. Citera hela kommandot:

az webapp exec --resource-group <resource-group-name> --name <app-name> --mode execute --command "python3 /home/site/wwwroot/scripts/diagnostics.py" --working-directory /home/site/wwwroot --instance <instance-id>

Byt ut skriptvägen mot ett skript som är distribuerat i din app. Den körbara filen och dess beroenden måste finnas i containern.

--command tolkar inte skaloperatorer som >, |, eller &&. Använd --shell-command istället när du behöver en shell. Dessa två alternativ utesluter varandra.

Fånga utdata och kontrollera slutförande

Följande exempel använder citering i Bash-klienten, till exempel i Cloud Shell. Den skickar in ett icke-modifierande diagnostiskt kommando till en enda instans och registrerar dess utgångs- och avslutningsstatus separat. Ersätt <run-id> med en ny identifierare för varje anrop och <instance-id> med ett ID från az webapp list-instances.

az webapp exec --resource-group <resource-group-name> --name <app-name> \
  --mode execute --instance <instance-id> --shell /bin/sh \
  --shell-command 'uname -a > /home/LogFiles/diagnostics-<run-id>.log 2>&1; result=$?; printf "%s\n" "$result" > /home/LogFiles/diagnostics-<run-id>.exit'

Se till att /bin/sh och det diagnostiska kommandot existerar, och att /home/LogFiles finns och är skrivbart. Persistens av /home i anpassade containrar beror på appens lagringskonfiguration. De enkla citattecknen hindrar klientskalet från att expandera $? och $result innan begäran når containern.

Efter inlämning, öppna ett interaktivt app shell på samma instans och inspektera filerna:

cat /home/LogFiles/diagnostics-<run-id>.log
cat /home/LogFiles/diagnostics-<run-id>.exit

En registrerad avslutsstatus på 0 indikerar att diagnoskommandot lyckades. En icke-noll status indikerar fel; inspektera loggen. Om statusfilen inte finns har slutförandet inte fastställts: kommandot kan fortfarande köras, kanske inte ha startat eller ha blivit avbrutet. Dra inte slutsatsen att något lyckades utifrån acceptans eller att det finns en partiell logg. Använd en ny körningsidentifierare så att en äldre statusfil inte kan förväxlas med det aktuella resultatet.

CLI:n tillhandahåller inget API för att polla status/slutförande. Att omdirigera utdata till en fil gör den inte automatiskt tillgänglig i App Service-loggströmningen.

Vid databasmigreringar eller andra operationer som ändrar delat tillstånd, välj en instans, kontrollera slutförandet separat och kör inte om operationen bara för att inlämningen inte gav någon utdata. Behåll det interaktiva arbetsflödet när du behöver kontrollera att det lyckades innan du fortsätter.

Kör oberoende kommandon på flera instanser

Exekveringsläget accepterar också en komma-separerad lista av instans-ID:n eller --instance all. Förfrågningar om flera instanser skickas parallellt. Till exempel, kör ett driftsatt diagnostiskt skript per instans på varje instans:

az webapp exec --resource-group <resource-group-name> --name <app-name> --mode execute --command "python3 /home/site/wwwroot/scripts/diagnostics.py" --instance all

Manuset måste registrera sina egna resultat. Använd separata utdatasökvägar per instans och per körning om lagringen delas. Använd inte all för migreringar av delade databaser eller andra operationer som bara måste köras en gång. Om vissa inlämningar misslyckas rapporterar CLI ett fel även om andra instanser kan ha accepterat kommandot.

Lägg till --slot <slot-name> för att köra mot ett distributionsfack.

Limitations

• Utföringsläget riktar sig endast mot huvudapplikationscontainern. Du kan bara använda --target kudu i interaktivt shell-läge.
• Använd --working-directory eller --cwd endast i exekveringsläge, och ge en absolut väg.
• Ge en absolut sökväg för --shell. I exekveringsläge kan du använda den endast med --shell-command.
• Denna förhandsvisning erbjuder inte filöverföring, portvidarebefordran eller möjlighet att välja godtyckliga sidecar-containrar. Använd stödda distributions-/implementeringsmetoder för att ladda upp filer.
• Frikopplad körning är inte en hållbar jobbschemaläggare. En omstart eller byte av containern kan avbryta arbetet. Anta inte att det sker automatiska omförsök eller exekvering exakt en gång.