Partilhar via

Configurar um contêiner personalizado para o Serviço de Aplicativo do Azure

Este artigo mostra como configurar um contêiner personalizado para ser executado no Serviço de Aplicativo do Azure.

Este guia fornece conceitos-chave e instruções para a conteinerização de aplicativos do Windows no Serviço de Aplicativo. Os novos utilizadores do Serviço de Aplicações do Azure devem primeiro seguir o início rápido do contêiner personalizado e o tutorial.

Este guia fornece conceitos-chave e instruções para a conteinerização de aplicativos Linux no Serviço de Aplicativo. Se você é novo no Serviço de Aplicativo do Azure, primeiro siga o início rápido e o tutorial do contêiner personalizado. Para contêineres de sidecar, consulte Tutorial: Configurar um contêiner de sidecar para contêiner personalizado no Serviço de Aplicativo do Azure.

Observação

Service Principal não tem mais suporte para a autenticação de pull de imagens de contêineres Windows. Recomendamos que você use o Managed Identity para contêineres Windows e Linux

Imagens pai suportadas

Para sua imagem personalizada do Windows, escolha a imagem pai certa (imagem base) para a estrutura desejada:

Leva algum tempo para baixar uma imagem principal durante a inicialização do aplicativo. Você pode reduzir o tempo de inicialização usando uma das seguintes imagens principais que já estão em cache no Serviço de Aplicações do Azure:

Alterar a imagem do Docker de um contêiner personalizado

Para alterar um contêiner personalizado existente da imagem atual do Docker para uma nova imagem, use o seguinte comando:

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

Utilizar uma imagem de um registo privado

Para usar uma imagem de um registro privado, como o Registro de Contêiner do Azure, execute o seguinte comando:

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>

Para <nome> de utilizador e <palavra-passe>, forneça as credenciais de início de sessão para a sua conta de registo privado.

Usar identidade gerenciada para extrair imagem do Registro de Contêiner do Azure

Use as etapas a seguir para configurar seu aplicativo Web para extrair do Registro de Contêiner do Azure (ACR) usando a identidade gerenciada. As etapas usam a identidade gerenciada atribuída ao sistema. Em vez disso, você pode usar a identidade gerenciada atribuída pelo usuário.

  1. Habilite a identidade gerenciada atribuída pelo sistema para o aplicativo Web usando o comando az webapp identity assign :

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

    Substitua <app-name> pelo nome usado na etapa anterior. A saída do comando, filtrada pelos argumentos --query e --output, é o ID principal de serviço da identidade atribuída.

  2. Obtenha a ID do recurso do seu Registro de Contêiner do Azure:

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

    Substitua <registry-name> pelo nome do seu registro. A saída do comando, filtrada pelos argumentos --query e --output, é o ID do recurso do Registro de Contêiner do Azure.

  3. Conceda a permissão de identidade gerenciada para acessar o registro de contêiner:

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

    Substitua os seguintes valores:

    • <principal-id> com o ID da entidade de serviço do comando az webapp identity assign
    • <registry-resource-id> com a ID do seu registro de contêiner do az acr show comando

    Para obter mais informações sobre essas permissões, consulte O que é o controle de acesso baseado em função do Azure.

  4. Configure seu aplicativo para usar a identidade gerenciada para extrair do Registro de Contêiner do Azure.

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

    Substitua os seguintes valores:

    • <app-name> com o nome do seu aplicativo Web.

    Sugestão

    Se utilizares o console do PowerShell para executar os comandos, escapa as cadeias de caracteres no argumento --generic-configurations neste passo e no próximo passo. Por exemplo: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (Opcional) Se o seu aplicativo usa uma identidade gerenciada atribuída pelo usuário, verifique se a identidade está configurada no aplicativo Web e defina a propriedade para especificar sua ID de acrUserManagedIdentityID cliente:

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

    Substitua o <identity-name> na identidade gerida atribuída ao usuário e utilize o resultado <client-id> para configurar o ID da identidade atribuída ao usuário.

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

Está tudo pronto! O aplicativo Web agora usa a identidade gerenciada para extrair do Registro de Contêiner do Azure.

Usar uma imagem de um registro protegido pela rede

Para se conectar e extrair de um registro dentro de uma rede virtual ou local, seu aplicativo deve se integrar a uma rede virtual. Você também precisa de integração de rede virtual para o Registro de Contêiner do Azure com ponto de extremidade privado. Depois de configurar a rede e a resolução de DNS, ative o roteamento da imagem transferida através da rede virtual configurando a definição do site vnetImagePullEnabled:

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

Não vejo o contêiner atualizado

Se você alterar as configurações do contêiner do Docker para apontar para um novo contêiner, pode levar alguns minutos até que o aplicativo atenda às solicitações HTTP do novo contêiner. Enquanto o novo contêiner está sendo puxado e iniciado, o Serviço de Aplicativo continua a atender solicitações do contêiner antigo. Somente quando o novo contêiner é iniciado e pronto para receber solicitações é que o Serviço de Aplicativo começa a enviar solicitações para ele.

Como as imagens de contêiner são armazenadas

Na primeira vez que você executa uma imagem personalizada do Docker no Serviço de Aplicativo, o Serviço de Aplicativo faz um docker pull e extrai todas as camadas de imagem. Essas camadas são armazenadas no disco, como se você estivesse usando o Docker localmente. Sempre que a aplicação é reiniciada, o App Service faz um docker pull. Extrai apenas camadas alteradas. Se não houver alterações, o Serviço de Aplicativo usará camadas existentes no disco local.

Se o aplicativo alterar instâncias de computação por qualquer motivo, como escalar para cima e para baixo as camadas de preço, o Serviço de Aplicativo deverá puxar todas as camadas para baixo novamente. O mesmo é verdadeiro se você expandir para adicionar mais instâncias. Também há casos raros em que as instâncias do aplicativo podem ser alteradas sem uma operação de escala.

Configurar o número da porta

Por padrão, o App Service assume que o seu contentor personalizado escuta na porta 80. Se o contentor escutar uma porta diferente, defina a configuração de aplicação WEBSITES_PORT no aplicativo do Serviço de Aplicações. Você pode configurá-lo usando o Cloud Shell. Em Bash:

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

No PowerShell:

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

Atualmente, o Serviço de Aplicativo permite que seu contêiner exponha apenas uma porta para solicitações HTTP.

Configurar variáveis de ambiente

Seu contêiner personalizado pode usar variáveis de ambiente que precisam ser fornecidas externamente. Pode introduzi-los usando o Cloud Shell. Em Bash:

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

No PowerShell:

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

Quando seu aplicativo é executado, as configurações do aplicativo do Serviço de Aplicativo são injetadas no processo como variáveis de ambiente automaticamente. Você pode verificar as variáveis de ambiente do contêiner com a URL https://<app-name>.scm.azurewebsites.net/Env.

Se seu aplicativo usa imagens de um registro privado ou do Docker Hub, as credenciais para acessar o repositório são salvas nas variáveis de ambiente: DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAMEe DOCKER_REGISTRY_SERVER_PASSWORD. Devido a riscos de segurança, nenhum desses nomes de variáveis reservadas é exposto ao aplicativo.

Para contêineres baseados no IIS ou .NET Framework (4.0 ou posterior), as credenciais são injetadas no System.ConfigurationManager automaticamente pelo Serviço de Aplicativo como configurações de aplicativo .NET e cadeias de conexão. Para todas as outras linguagens ou estruturas, elas são fornecidas como variáveis de ambiente para o processo, com um dos seguintes prefixos:

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

Esse método funciona tanto para aplicativos de contêiner único quanto para aplicativos de vários contêineres, onde as variáveis de ambiente são especificadas no arquivo docker-compose.yml .

Usar armazenamento compartilhado persistente

Você pode usar o diretório C:\home em seu sistema de arquivos de contêiner personalizado para persistir arquivos em reinicializações e compartilhá-los entre instâncias. O diretório C:\home é fornecido para permitir que seu contêiner personalizado acesse o armazenamento persistente.

Quando o armazenamento persistente é desativado, as gravações no diretório C:\home não são persistidas nas reinicializações do aplicativo ou em várias instâncias. Quando o armazenamento persistente está habilitado, todas as gravações no diretório C:\home persistem. Todas as instâncias de uma aplicação dimensionada podem acessá-las. Todos os arquivos existentes já presentes no armazenamento persistente quando o contêiner é iniciado substituem qualquer conteúdo no diretório C:\home do contêiner.

A única exceção é o diretório C:\home\LogFiles . Este diretório armazena o contêiner e os logs do aplicativo. Essa pasta sempre persiste quando o aplicativo é reiniciado se o log do aplicativo estiver habilitado com a opção Sistema de arquivos , independentemente de o armazenamento persistente estar habilitado ou não. Em outras palavras, habilitar ou desabilitar o armazenamento persistente não afeta o comportamento de log do aplicativo.

Por padrão, o armazenamento persistente é habilitado em contêineres personalizados do Windows. Para desativá-lo, defina o valor da configuração do WEBSITES_ENABLE_APP_SERVICE_STORAGE aplicativo como false usando o Cloud Shell. Em Bash:

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

No PowerShell:

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

Você pode usar o diretório /home em seu sistema de arquivos de contêiner personalizado para persistir arquivos em reinicializações e compartilhá-los entre instâncias. O diretório /home é fornecido para permitir que seu contêiner personalizado acesse o armazenamento persistente. Salvar dados em /home contribui para a cota de espaço de armazenamento incluída no seu Plano do Serviço de Aplicativo.

Quando o armazenamento persistente é desativado, as gravações no diretório /home não são mantidas nas reinicializações do aplicativo ou em várias instâncias. Quando o armazenamento persistente está habilitado, todas as gravações no diretório /home persistem. Todas as instâncias de uma aplicação dimensionada podem acessá-las. Todos os arquivos existentes já presentes no armazenamento persistente quando o contêiner é iniciado substituem qualquer conteúdo no diretório /home do contêiner.

A única exceção é o diretório /home/LogFiles . Este diretório armazena o contêiner e os logs do aplicativo. Essa pasta sempre persiste quando o aplicativo é reiniciado se o log do aplicativo estiver habilitado com a opção Sistema de arquivos , independentemente de o armazenamento persistente estar habilitado ou não. Em outras palavras, habilitar ou desabilitar o armazenamento persistente não afeta o comportamento de log do aplicativo.

Recomendamos que você grave dados em /home ou em um caminho de armazenamento montado do Azure. Os dados gravados fora desses caminhos não são persistentes durante as reinicializações. Os dados são salvos no espaço em disco do host gerenciado pela plataforma, separado da cota de armazenamento de arquivos dos Planos do Serviço de Aplicativo.

Por padrão, o armazenamento persistente é desativado em contêineres personalizados do Linux. Para habilitá-lo, defina o valor da configuração do WEBSITES_ENABLE_APP_SERVICE_STORAGE aplicativo como true usando o Cloud Shell. Em Bash:

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

No PowerShell:

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

Observação

Você também pode configurar seu próprio armazenamento persistente.

Detetar sessão HTTPS

O Serviço de Aplicativo encerra o TLS nos front-ends. Isso significa que as solicitações TLS nunca chegam ao seu aplicativo. Você não precisa e não deve implementar nenhum suporte para TLS em seu aplicativo.

Os front-ends estão localizados dentro dos data centers do Azure. Se você usa TLS com seu aplicativo, seu tráfego na Internet é sempre criptografado com segurança.

Personalizar injeção de chave da máquina do ASP.NET

Durante a inicialização do container, chaves geradas automaticamente são injetadas no container como chaves de máquina para as rotinas criptográficas do ASP.NET. Você pode encontrar essas chaves em seu contêiner procurando as seguintes variáveis de ambiente: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, MACHINEKEY_Validation.

As novas chaves em cada reinicialização podem redefinir a autenticação de formulários do ASP.NET e o estado de visualização, se a sua aplicação depender delas. Para impedir a regeneração automática de chaves, defina-as manualmente como definições da aplicação do serviço App.

Conecte-se ao contêiner

Para se conectar ao contentor do Windows diretamente para tarefas de diagnóstico, navegue até https://<app-name>.scm.azurewebsites.net/ e escolha a opção SSH. Esta opção estabelece uma sessão SSH direta na qual você pode executar comandos dentro do contêiner.

  • Ele funciona separadamente do navegador gráfico acima dele, que mostra apenas os arquivos em seu armazenamento compartilhado.
  • Em um aplicativo dimensionado, a sessão SSH é conectada a uma das instâncias de contêiner. Você pode selecionar uma instância diferente na lista suspensa Instância no menu superior do Kudu.
  • Exceto para alterações no armazenamento compartilhado, qualquer alteração feita no contêiner de dentro da sessão SSH não persiste quando seu aplicativo é reiniciado. Essas alterações não fazem parte da imagem do Docker. Para persistir as alterações, como configurações do Registro e instalação de software, torne-as parte do Dockerfile.

Aceder aos registos de diagnósticos

O Serviço de Aplicativo registra ações do host do Docker e atividades de dentro do contêiner. Os logs do anfitrião Docker (logs da plataforma) são ativados por padrão. Você precisa ativar manualmente os registos de aplicações ou os registos do servidor web a partir de dentro do contêiner. Para obter mais informações, consulte Habilitar o log de aplicativos e Habilitar o log do servidor Web.

Há várias maneiras de acessar os logs do Docker:

No portal do Azure

Os logs do Docker são exibidos no portal do Azure, na página Configurações de Contêiner do seu aplicativo. Os registos são truncados. Para baixar todos os logs, selecione Download.

De Kudu

Para ver os arquivos de log individuais, navegue até https://<app-name>.scm.azurewebsites.net/DebugConsole a pasta LogFiles e selecione-a. Para baixar todo o diretório LogFiles , selecione o ícone Download à esquerda do nome do diretório. Você também pode acessar essa pasta usando um cliente FTP.

No terminal SSH, você não pode acessar a pasta C:\home\LogFiles por padrão porque o armazenamento compartilhado persistente não está habilitado. Para habilitar esse comportamento no terminal do console, habilite o armazenamento compartilhado persistente.

Se você tentar baixar o log do Docker que está atualmente em uso usando um cliente FTP, poderá receber um erro devido a um bloqueio de arquivo.

Com a API Kudu

Navegue diretamente para https://<app-name>.scm.azurewebsites.net/api/logs/docker para ver os metadados dos registos do Docker. Você pode ver mais de um arquivo de log listado. A href propriedade permite que você baixe o arquivo de log diretamente.

Para baixar todos os logs juntos em um arquivo ZIP, acesse https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip.

Personalizar a memória do contêiner

Por padrão, todos os Contêineres do Windows implantados no Serviço de Aplicativo do Azure têm um limite de memória configurado. A tabela a seguir lista as configurações padrão por SKU do Plano do Serviço de Aplicativo.

SKU do Plano de Serviço de Aplicação Limite de memória padrão por aplicativo em MB
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

Você pode alterar esse valor fornecendo a configuração do WEBSITE_MEMORY_LIMIT_MB aplicativo usando o Cloud Shell. Em Bash:

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

No PowerShell:

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

O valor é definido em MB e deve ser menor e igual à memória física total do host. Por exemplo, em um plano do Serviço de Aplicativo com 8 GB de RAM, o total acumulado de WEBSITE_MEMORY_LIMIT_MB todos os aplicativos não deve exceder 8 GB. Para obter mais informações sobre a quantidade de memória disponível, consulte a seção Plano de serviço Premium v3 de Preços do Serviço de Aplicativo.

Personalizar o número de núcleos de computação

Por padrão, um contêiner do Windows é executado com todos os núcleos disponíveis para o nível de preço escolhido. Talvez você queira reduzir o número de núcleos que o seu ambiente de testes usa. Para reduzir o número de núcleos usados por um contêiner, defina a configuração do WEBSITE_CPU_CORES_LIMIT aplicativo para o número preferencial de núcleos. Você pode configurá-lo usando o Cloud Shell. Em Bash:

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

No PowerShell:

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

Sugestão

A atualização da configuração do aplicativo aciona a reinicialização automática, o que causa um tempo de inatividade mínimo. Para uma aplicação de produção, considere alterá-la para um slot de ensaio, modifique a configuração da aplicação no slot de ensaio e volte a transferi-la para a produção.

Para verificar seu número ajustado, abra uma sessão SSH no portal do Azure ou use o portal Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host). Insira os seguintes comandos usando o PowerShell. Cada comando retorna um número.

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

Os processadores podem ser multicore ou hyperthreading. Informações sobre quantos núcleos estão disponíveis, consulte a seção Plano de serviço Premium v3 de Preços do Serviço de Aplicativo.

Personalizar o comportamento de ping de saúde

O Serviço de Aplicativo considera que um contêiner foi iniciado com êxito quando o contêiner é iniciado e responde a um ping HTTP. A solicitação de ping de integridade contém o cabeçalho User-Agent= "App Service Hyper-V Container Availability Check". Se o contêiner for iniciado, mas não responder a pings após um determinado período de tempo, o Serviço de Aplicativo registrará um evento no log do Docker.

Se o seu aplicativo consome muitos recursos, o contêiner pode não responder ao ping HTTP a tempo. Para controlar as ações quando os pings HTTP falham, defina a configuração do CONTAINER_AVAILABILITY_CHECK_MODE aplicativo. Você pode configurá-lo usando o Cloud Shell. Em Bash:

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

No PowerShell:

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

A tabela a seguir mostra os valores possíveis:

Valor Descrições
Reparação Reinicie o contêiner após três verificações de disponibilidade consecutivas.
ReportOnly O valor padrão. Não reinicie o contentor, mas registe nos logs do Docker do contentor após três verificações consecutivas de disponibilidade.
Desligado Não verifique a disponibilidade.

Suporte para Contas de Serviço Gerenciado de Grupo

Atualmente, não há suporte para Contas de Serviço Gerenciado de Grupo (gMSAs) em contêineres do Windows no Serviço de Aplicativo.

Ativar SSH

O Secure Shell (SSH) é comumente usado para executar comandos administrativos remotamente a partir de um terminal de linha de comando. Para habilitar o recurso de console SSH do portal do Azure com contêineres personalizados, siga estas etapas:

  1. Crie um arquivo padrão sshd_config com o seguinte conteúdo de exemplo e coloque-o no diretório raiz do projeto de aplicativo:

    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

    Observação

    Esse arquivo configura o OpenSSH e deve incluir os seguintes itens para estar em conformidade com o recurso SSH do portal do Azure:

    • Port deve ser definido como 2222.
    • Ciphers deve incluir pelo menos um elemento nesta lista: aes128-cbc,3des-cbc,aes256-cbc.
    • MACs deve incluir pelo menos um elemento nesta lista: hmac-sha1,hmac-sha1-96.

  2. Crie um script de entrada com o nome entrypoint.sh ou altere qualquer ficheiro de entrada existente. Adicione o comando para iniciar o serviço SSH, juntamente com o comando de inicialização do aplicativo. O exemplo a seguir demonstra iniciar um aplicativo Python. Substitua o último comando de acordo com a linguagem/pilha do projeto:

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

  3. Adicione ao Dockerfile as seguintes instruções de acordo com a distribuição da imagem base. Estas instruções copiam os novos arquivos, instalam o servidor OpenSSH, definem as permissões adequadas e configuram o ponto de entrada personalizado e expõem as portas exigidas pelo aplicativo e pelo servidor SSH, respectivamente:

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

    Observação

    A senha de root deve ser exatamente Docker! porque é usada pelo Serviço de Aplicativo para permitir que você acesse a sessão SSH com o contêiner. Essa configuração não permite conexões externas com o contêiner. A porta 2222 do contêiner é acessível somente dentro da rede de ponte de uma rede virtual privada e não é acessível a um invasor na Internet.

  4. Recrie e submeta por push a imagem do Docker para o registo e teste a funcionalidade SSH da Aplicação Web no portal do Azure.

Para obter mais informações sobre solução de problemas, consulte o blog do Serviço de Aplicativo do Azure: Habilitando o SSH no Linux Web App for Containers

Aceder aos registos de diagnósticos

Você pode acessar os logs do console gerados de dentro do contêiner.

Para ativar o log de contêiner, execute o seguinte comando:

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

Substitua <app-name> e <resource-group-name> por nomes apropriados para seu aplicativo Web.

Depois de ativar o log de contêiner, execute o seguinte comando para ver o fluxo de log:

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

Se os logs do console não aparecerem imediatamente, verifique novamente em 30 segundos.

Para interromper o streaming de logs a qualquer momento, selecione Ctrl+C.

Configurar aplicativos de vários contêineres

Observação

O recurso Docker Compose será desativado em 31 de março de 2027. Os contêineres de sidecar sucedem aplicativos de vários contêineres no Serviço de Aplicativo. Para obter novos serviços, consulte Tutorial: Configurar um contêiner sidecar para contêiner personalizado no Serviço de Aplicativo do Azure. Para aplicativos multicontêineres existentes no Serviço de Aplicativo, consulte Migrando seus aplicativos Docker Compose para o recurso Sidecar.

Usar armazenamento persistente no Docker Compose

Aplicativos de vários contêineres, como o WordPress, precisam de armazenamento persistente para funcionar corretamente. Para habilitá-lo, a configuração do Docker Compose deve apontar para um local de armazenamento fora do contêiner. Os locais de armazenamento dentro do contêiner não persistem alterações além da reinicialização do aplicativo.

Para habilitar o armazenamento persistente, defina a configuração do WEBSITES_ENABLE_APP_SERVICE_STORAGE aplicativo. Utilize o comando az webapp config appsettings set no Cloud Shell.

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

No arquivo docker-compose.yml , mapeie a volumes opção para ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME é uma variável de ambiente no Serviço de Aplicativo mapeada para armazenamento persistente para seu aplicativo. Por exemplo:

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"

Limitações de pré-visualização

Multi-contêiner está atualmente em pré-visualização. Os seguintes recursos da plataforma do Serviço de Aplicativo não são suportados:

  • Autenticação / Autorização
  • Identidades gerenciadas
  • CORS
  • A integração de rede virtual não é suportada em cenários de composição do Docker.
  • Atualmente, o Docker Compose nos Serviços de Aplicativo do Azure tem um limite de 4.000 caracteres.

Opções de composição do Docker

As listas a seguir mostram as opções de configuração do Docker Compose suportadas e não suportadas:

Opções suportadas

Opções não suportadas

  • build (não permitido)
  • depends_on (ignorado)
  • redes (ignorado)
  • Segredos (ignorados)
  • portas diferentes de 80 e 8080 (ignoradas)
  • variáveis de ambiente padrão, como $variable and ${variable} ao contrário do docker

Limitações de sintaxe

  • "version x.x" sempre precisa ser a primeira instrução YAML no arquivo
  • A seção de portas deve usar números entre aspas
  • A seção de volume de imagem > deve ser citada e não pode ter definições de permissões
  • A seção de volumes não deve ter uma chave vazia após o nome do volume

Observação

Quaisquer outras opções não explicitamente destacadas são ignoradas na Pré-visualização Pública.

Ignorar a mensagem robots933456 nos logs

Poderá ver a seguinte mensagem nos registos de contentores:

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

Pode ignorar esta mensagem. /robots933456.txt é um caminho de URL fictício que o Serviço de Aplicações utiliza para verificar se o contentor consegue satisfazer pedidos. Uma resposta 404 indica que o caminho não existe e sinaliza ao Serviço de Aplicativo que o contêiner está íntegro e pronto para responder às solicitações.

Conteúdo relacionado

Tutorial: Migrar software personalizado para o Serviço de Aplicativo do Azure usando um contêiner personalizado

Tutorial: Configurar um contenedor sidecar para contenedor personalizado no Serviço de Aplicações do Azure

Ou veja mais recursos: