Abra um container shell (SSH) e execute comandos no Serviço de Aplicativo do Azure

O Serviço de Aplicativos oferece acesso SSH baseado em navegador para aplicativos hospedados em contêineres personalizados do Windows. Não é necessária configuração especial de imagem para a sessão do navegador.

O comando CLI do Azure az webapp exec é suportado apenas para aplicativos web Linux. Não use os exemplos de CLI do Linux neste artigo para planos do App Service do Windows.

Para contêineres Linux integrados e personalizados, o terminal do navegador mais recente e az webapp exec usam o Kudu como proxy autenticado para se conectar ao contêiner em execução. Essas opções não exigem que você instale um servidor SSH, incorpore uma senha SSH, exponha uma porta SSH ou inicie um daemon SSH na sua imagem personalizada. O WebSSH az webapp ssh e o acesso do Kudu legado ainda podem exigir um servidor SSH em uma imagem personalizada.

Use o portal do Azure para uma sessão de navegador, ou use o comando de pré-visualização az webapp exec para uma sessão de terminal local ou execução de comando desanexada. O terminal do navegador exige /bin/bash na imagem e atualmente não suporta selecionar outro shell. Se a imagem tiver uma shell diferente, use az webapp exec --shell /bin/sh em vez disso. Imagens sem shell, incluindo imagens distroless, não conseguem abrir uma sessão interativa.

• Para os exemplos de CLI, instale o CLI do Azure 2.90.0 ou posterior e faça login. Verifique sua versão com az version. Você também pode usar o Azure Cloud Shell se a CLI dele atender a esse requisito.
• Para uma sessão interativa de CLI, use um terminal interativo e uma shell que exista na sua imagem. O padrão é /bin/bash; para uma imagem sem bash, especifique --shell /bin/sh se essa shell está disponível.

Abrir a sessão SSH com a CLI do Azure

O comando de pré-visualização az webapp exec abre uma shell interativa no contêiner principal do seu app. A sessão usa seu terminal local no Windows, macOS e Linux; ela não abre um navegador.

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

Para uma imagem que usa /bin/sh em vez de bash:

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

Você pode executar comandos e inspecionar a saída deles nesta sessão. Por exemplo, use top se estiver instalado na imagem. Para inspecionar o contêiner SCM/Kudu em vez do contêiner do app:

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

O app e os contêineres Kudu são ambientes diferentes. Execute comandos que dependam do tempo de execução do seu app, dependências ou conectividade de rede no contêiner do app.

Selecione uma instância ou slot de implantação

Por padrão, a CLI se conecta a uma única instância do app. Para encontrar IDs de instância:

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

Para conectar a uma instância específica:

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

Adicione --slot <slot-name> para acessar um slot de implantação. Ao selecionar a instância de um slot, também adicione --slot a az webapp list-instances.

O modo shell interativo suporta apenas uma instância por vez.

Executar comandos sem uma sessão interativa

Use --mode execute para enviar um comando para o contêiner principal do app sem abrir uma sessão de terminal. O comando é executado em segundo plano. Esse modo é útil para diagnósticos em segundo plano ou outros trabalhos que não exigem saída imediata.

Execute um programa diretamente

Use --command para especificar um programa e seus argumentos. Cite o comando completo:

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>

Substitua o caminho do script por um script implantado no seu app. O executável e suas dependências devem existir no contêiner.

--command não interpreta operadores de shell como >, |, ou &&. Use --shell-command em vez disso quando precisar de um shell. Essas duas opções são mutuamente exclusivas.

Capture a saída e verifique a conclusão

O exemplo a seguir utiliza aspas no cliente Bash, como no Cloud Shell. Ele envia um comando de diagnóstico somente leitura para uma instância e registra sua saída e seu status de saída separadamente. Substitua <run-id> por um novo identificador para cada invocação e <instance-id> por um ID de 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'

Certifique-se de que /bin/sh e o comando de diagnóstico existem, e que /home/LogFiles existe e tem permissão de escrita. A persistência de /home em contêineres personalizados depende da configuração de armazenamento do app. As aspas simples impedem que o shell do cliente expanda $? e $result antes que a solicitação chegue ao container.

Após o envio, abra um shell interativo do aplicativo na mesma instância e inspecione os arquivos:

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

Um status de saída registrado de 0 indica que o comando de diagnóstico teve sucesso. Um status diferente de zero indica falha; inspecione o log. Se o arquivo de status não existir, a conclusão não foi confirmada: o comando pode ainda estar em execução, pode não ter começado ou pode ter sido interrompido. Não infira sucesso a partir da aceitação ou da presença de um log parcial. Use um identificador de execução novo para que um arquivo de status antigo não possa ser confundido com o resultado atual.

A CLI não fornece uma API para consultar a conclusão. Redirecionar a saída para um arquivo não o torna automaticamente disponível no streaming de logs do App Service.

Para migrações de banco de dados ou outras operações que mudam o estado compartilhado, selecione uma instância, verifique a conclusão separadamente e não execute a operação apenas porque a submissão não retornou saída. Mantenha o fluxo de trabalho interativo quando precisar verificar o sucesso antes de continuar.

Execute comandos independentes em múltiplas instâncias

O modo de execução também aceita uma lista separada por vírgulas de IDs de instância ou --instance all. Solicitações para múltiplas instâncias são enviadas em paralelo. Por exemplo, execute um script de diagnóstico por instância implantado em cada instância:

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

O roteiro deve capturar seus próprios resultados. Use caminhos de saída distintos por instância e por execução se o armazenamento for compartilhado. Não use all para migrações de banco compartilhado ou outras operações que devem ser executadas apenas uma vez. Se algumas submissões falharem, a CLI reporta um erro, mesmo que outras instâncias possam ter aceitado o comando.

Adicionar --slot <slot-name> para executar em um slot de implantação.

Limitations

• O modo de execução mira apenas o contêiner principal do app. Você só pode usar --target kudu no modo shell interativo.
• Use --working-directory ou --cwd apenas no modo de execução e forneça um caminho absoluto.
• Forneça um caminho absoluto para --shell. No modo de execução, você só pode usá-lo com --shell-command.
• Esta pré-visualização não oferece transferência de arquivos, encaminhamento de portas ou opção para selecionar contêineres sidecar arbitrários. Use métodos de implantação/publicação suportados para enviar arquivos.
• Execução desacoplada não é um agendador de tarefas duradouro. Uma reinicialização ou substituição de contêiner pode interromper o trabalho. Não presuma tentativas automáticas ou execução exatamente uma vez.