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

Este guia apresenta os principais conceitos e instruções para a conteinerização de aplicativos do Windows no Serviço de Aplicativo. Os novos usuários do Serviço de Aplicativo do Azure devem seguir primeiro o Início rápido do contêiner personalizado e o tutorial.

Este guia apresenta os principais conceitos e instruções para conteinerização de aplicativos do Linux no Serviço de Aplicativo. Caso seja iniciante no Serviço de Aplicativo do Azure, primeiro siga o Início rápido de contêiner personalizado e o tutorial. Para contêineres sidecar (versão prévia), consulte Tutorial: configurar um contêiner sidecar para contêiner personalizado no Serviço de Aplicativo do Azure (versão prévia).

Imagens pai com suporte

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

• Para implantar aplicativos do .NET Framework, use uma imagem pai com base na versão do Canal de Manutenção em Longo Prazo (LTSC) do Windows Server 2019 Core.
• Para implantar aplicativos .NET Core, use uma imagem pai baseada na versão do Canal de Manutenção Semestral (SAC) do Windows Server 2019 Nano.

Leva algum tempo para baixar uma imagem pai durante a inicialização do aplicativo. No entanto, você pode reduzir o tempo de inicialização usando uma das seguintes imagens pai já armazenadas em cache no Serviço de Aplicativo do Azure:

• 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

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

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

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

Quando o armazenamento persistente estiver desabilitado, as gravações no diretório C:\home não serão persistidas entre as reinicializações do aplicativo ou entre várias instâncias. Quando o armazenamento persistente estiver habilitado, todas as gravações no diretório C:\home serão persistidas e poderão ser acessadas por todas as instâncias de um aplicativo expandido. Além disso, qualquer conteúdo dentro do diretório C:\home do contêiner é substituído por todos os arquivos existentes já presentes no armazenamento persistente quando o contêiner é iniciado.

A única exceção é o diretório C:\home\LogFiles, que serve para armazenar os logs do contêiner e do aplicativo. Essa pasta sempre permanece após a reinicialização do aplicativo se o log de aplicativo estiver habilitado com a opção Sistema de Arquivos, independentemente do armazenamento persistente habilitado ou desabilitado. Em outras palavras, habilitar ou desabilitar o armazenamento persistente não afeta o comportamento do log do aplicativo.

Por padrão, o armazenamento persistente está habilitado nos contêineres personalizados do Windows. Para desabilitá-lo, defina o WEBSITES_ENABLE_APP_SERVICE_STORAGE valor de false configuração do aplicativo por meio do Cloud Shell. No 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 no sistema de arquivos de contêiner personalizado para persistir os arquivos entre as reinicializações e compartilhá-los entre instâncias. O diretório /home é fornecido para permitir que o 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 de Serviço de Aplicativo.

Quando o armazenamento persistente estiver desabilitado, as gravações no diretório /home não serão persistidas entre as reinicializações do aplicativo ou entre várias instâncias. Quando o armazenamento persistente estiver habilitado, todas as gravações no diretório /home serão persistidas e poderão ser acessadas por todas as instâncias de um aplicativo expandido. Além disso, qualquer conteúdo dentro do diretório /home do contêiner é substituído por todos os arquivos existentes já presentes no armazenamento persistente quando o contêiner é iniciado.

A única exceção é o diretório /home/LogFiles, que serve para armazenar os logs do contêiner e do aplicativo. Essa pasta sempre permanece após a reinicialização do aplicativo se o log de aplicativo estiver habilitado com a opção Sistema de Arquivos, independentemente do armazenamento persistente habilitado ou desabilitado. Em outras palavras, habilitar ou desabilitar o armazenamento persistente não afeta o comportamento do log do aplicativo.

É recomendável gravar dados em /home ou em um caminho de armazenamento do Azure montado. Os dados gravados fora destes caminhos não são persistentes durante as reinicializações e são salvos no espaço em disco do host gerenciado por plataforma separado da cota de armazenamento de arquivos dos Planos de Serviço de Aplicativo.

Por padrão, o armazenamento persistente é desabilitado nos contêineres personalizados do Linux. Para habilitá-lo, defina o WEBSITES_ENABLE_APP_SERVICE_STORAGE valor de true configuração do aplicativo por meio do Cloud Shell. No 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}

Personalizar a injeção de chave do computador ASP.NET

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

As novas chaves em cada reinício podem redefinir o estado de exibição e a autenticação de formulários ASP.NET, caso seu aplicativo dependa delas. Para evitar a regeneração automática das chaves, defina-as manualmente como configurações de Serviço de Aplicativo.

Conectar-se ao contêiner

Você pode se conectar ao seu contêiner do Windows diretamente para tarefas de diagnóstico navegando até https://<app-name>.scm.azurewebsites.net/ e escolhendo a opção SSH. Uma sessão SSH direta com seu contêiner é estabelecida na qual você pode executar comandos dentro de seu contêiner.

• Ele funciona separadamente do navegador gráfico acima dele, que mostra apenas os arquivos no armazenamento compartilhado.
• Em um aplicativo expandido, 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 Kudu superior.
• Qualquer alteração feita no contêiner de dentro da sessão SSH não persiste quando o aplicativo é reiniciado (exceto por alterações no armazenamento compartilhado), porque ela não faz parte da imagem do Docker. Para persistir suas alterações, como configurações do registro e instalação de software, torne-as parte do Dockerfile.

Acessar logs de diagnóstico

O Serviço de Aplicativo registra ações pelo host do Docker e atividades de dentro do contêiner. Os logs do host do Docker (logs de plataforma) são fornecidos por padrão, mas os logs de aplicativo ou de servidor Web de dentro do contêiner precisam ser habilitados manualmente. Para obter mais informações, consulte Habilitar o registro em log do aplicativo e Habilitar o registro em log do servidor Web.

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

• Portal do Azure
• Kudu
• Kudu API
• Azure Monitor

No Portal do Azure

Os logs do Docker são exibidos no portal, na página Configurações de contêiner do seu aplicativo. Os logs são truncados, mas você pode baixar todos os logs selecionando Download.

Do Kudu

Navegue até https://<app-name>.scm.azurewebsites.net/DebugConsole e selecione a pasta LogFiles, para visualizar os arquivos de log individuais. Para baixar todo o diretório de LogFiles, selecione o ícone “Download” à esquerda do nome do diretório. Também é possível acessar essa pasta usando um cliente FTP.

No terminal do SSH, não é possível 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á em uso no momento usando um cliente FTP, poderá receber um erro devido a um bloqueio de arquivo.

Com a API do Kudu

Navegue diretamente até https://<app-name>.scm.azurewebsites.net/api/logs/docker para ver os metadados para os logs do Docker. Você pode ver mais de um arquivo de log listado e a propriedade href permite baixar 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 de Serviço de Aplicativo.

Você pode alterar esse valor fornecendo a configuração de aplicativo WEBSITE_MEMORY_LIMIT_MB por meio do Cloud Shell. No 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 cumulativo de WEBSITE_MEMORY_LIMIT_MB para todos os aplicativos não deve exceder 8 GB. Informações sobre a quantidade de memória disponível para cada tipo de preço podem ser encontradas em Preços do Serviço de Aplicativo, na seção Plano de Serviço Premium v3.

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 tipo de preço escolhido. Você pode desejar reduzir o número de núcleos que o slot de preparo usa, por exemplo. Para reduzir o número de núcleos usados por um contêiner, defina a configuração de aplicativo WEBSITE_CPU_CORES_LIMIT para o número preferencial de núcleos. Você pode defini-la por meio do Cloud Shell. No 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}

Verifique o número ajustado abrindo uma sessão do SSH no portal ou por meio do portal do Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host) e digitando os comandos a seguir com o PowerShell. Cada comando produz 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 processadores hyperthreading. Informações sobre quantos núcleos estão disponíveis para cada tipo de preço podem ser encontradas em Preços do Serviço de Aplicativo, na seção Plano de Serviço Premium v3.

Personalizar comportamento do ping de integridade

O Serviço de Aplicativo considera que um contêiner é iniciado com êxito quando o contêiner inicia 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 iniciar, mas não responder aos pings após determinado período de tempo, o Serviço de Aplicativo registrará um evento no log do Docker, dizendo que o contêiner não iniciou.

Se o aplicativo estiver com uso intensivo de recursos, o contêiner poderá não responder ao ping HTTP a tempo. Para controlar as ações quando ocorre falha em pings HTTP, defina a configuração de aplicativo CONTAINER_AVAILABILITY_CHECK_MODE. Você pode defini-la por meio do Cloud Shell. No 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:

Suporte para Contas de Serviço Gerenciado de Grupo

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

Habilitar SSH

Secure Shell (SSH) normalmente é usado para executar comandos administrativos remotamente a partir de um terminal de linha de comando. Para habilitar o recurso de console SSH no portal do Azure com contêineres personalizados, as seguintes etapas são necessárias:

1. Crie um arquivo sshd_config padrão 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 item nesta lista: aes128-cbc,3des-cbc,aes256-cbc.
   • MACs deve incluir pelo menos um item nesta lista: hmac-sha1,hmac-sha1-96.

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

   • Debian
   • Alpine

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

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

   • Debian
   • Alpine

   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 raiz deve ser exatamente Docker! como é usada pelo Serviço de Aplicativo do Azure para conceder acesso à 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 por um invasor na Internet.

4. Recompile e envie por push a imagem do Docker para o registro e, em seguida, teste o recurso SSH do Aplicativo Web no portal do Azure.

Para obter mais informações sobre solução de problemas, confira o blog do Serviço de Aplicativo do Azure: Habilitar o SSH no Aplicativo Web para Contêineres do Linux

Acessar logs de diagnóstico

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

Primeiro, ative o log do contêiner executando 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> pelos nomes apropriados para seu aplicativo Web.

Depois que o log do contêiner estiver ativado, execute o seguinte comando para ver o fluxo de log:

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

Se você não vir os logs do console imediatamente, verifique novamente após 30 segundos.

Para interromper o streaming de log a qualquer momento, digite Ctrl+C.

Você também pode inspecionar os arquivos de log em um navegador em https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Configurar aplicativos de vários contêineres

• Usar armazenamento persistente no Docker Compose
• Limitações da versão prévia
• Opções do Docker Compose

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, sua 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 as alterações além do reinício do aplicativo.

Habilite o armazenamento persistente definindo a configuração de aplicativo WEBSITES_ENABLE_APP_SERVICE_STORAGE, usando 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 opção volumes para ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME é uma variável de ambiente no Serviço de Aplicativo mapeada para armazenamento persistente para o 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 visualização

O multi-contêiner está atualmente em versão prévia. Não há suporte para os seguintes recursos da plataforma do Serviço de Aplicativo:

• Autenticação/Autorização
• Identidades gerenciadas
• CORS
• Não há suporte para a integração de rede virtual em cenários de Docker Compose
• O Docker Compose nos Serviços de Aplicativo do Azure tem um limite de 4 mil caracteres no momento.

Opções do Docker Compose

As listas a seguir mostram opções de configuração do Docker Compose com e sem suporte:

Opções com suporte

• .
• entrypoint
• ambiente
• image
• ports
• restart
• services
• volumes (o mapeamento para o Armazenamento do Azure não tem suporte)

Opções sem suporte

• build (não permitido)
• depends_on (ignorado)
• networks (ignorada)
• secrets (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

• a "versão x.x" precisa sempre 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 estar entre aspas e não é possível ter definições de permissões
• a seção de volumes não pode ter uma chave vazia após o nome do volume

robots933456 em logs

Você poderá ver a seguinte mensagem nos logs de contêiner:

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

Você pode ignorar essa mensagem com segurança. /robots933456.txt é um caminho de URL fictício que o Serviço de Aplicativo usa para verificar se o contêiner é capaz de atender a solicitações. Uma resposta 404 indica apenas que o caminho não existe, mas informa ao Serviço de Aplicativo que o contêiner está íntegro e pronto para responder a solicitações.