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

Saiba mais sobre os principais conceitos e obtenha instruções para a contêinerização de aplicativos do Windows no Serviço de Aplicativo. Os novos usuários devem primeiro seguir o guia de início rápido e o tutorialdo contêiner personalizado.

Saiba mais sobre os principais conceitos e obtenha instruções para a contêinerização de aplicativos Linux no Serviço de Aplicativo. Os novos usuários devem primeiro seguir o guia de início rápido e o tutorialdo contêiner personalizado. Para contêineres sidecar, veja Tutorial: Configurar um contêiner sidecar para um contêiner personalizado no Serviço de Aplicativo do Azure.

Observação

O uso de uma entidade de serviço para autenticação de transferência de imagens de contêiner do Windows não tem mais suporte. Recomendamos que você use a identidade gerenciada para contêineres do Windows e do Linux.

Imagens pai com suporte

Selecione a imagem pai (imagem base) correta para a estrutura desejada para sua imagem personalizada do Windows:

  • Para implantar aplicativos do .NET Framework, use uma imagem pai baseada na versão do Windows Server 2019 Core Long-Term Servicing Channel.
  • Para implantar aplicativos do .NET Core, use uma imagem pai baseada na versão do Windows Server 2019 Nano Annual Channel.

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:

Alterar a imagem do Docker de um contêiner personalizado

Use o seguinte comando para alterar a imagem atual do Docker para uma nova imagem em um contêiner personalizado existente:

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

Usar uma imagem de um registro 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>

Forneça as credenciais de entrada para sua conta de registro privada nos campos \<username> e \<password>.

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

Use as etapas a seguir para configurar seu aplicativo Web para efetuar pull do Registro de Contêiner do Azure usando a identidade gerenciada. As etapas usam a identidade gerenciada atribuída pelo sistema, mas você também 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 az webapp identity assign comando:

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

    Substitua <o nome> do aplicativo pelo nome usado na etapa anterior. A saída do comando (filtrada pelos argumentos --query e --output) é o ID da entidade de serviço da identidade atribuída.

  2. Obter a ID do recurso do registro de contêiner:

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

    Substitua <o nome> do registro pelo nome do registro. A saída do comando, filtrada pelos argumentos --query e --output, é a ID do recurso do registro de contêineres.

  3. Conceda à identidade gerenciada permissão 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 a ID da entidade de serviço do comando az webapp identity assign
    • <registry-resource-id> com a ID do registro de contêiner do comando az acr show

    Para obter mais informações sobre essas permissões, confira 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êineres 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.

    Dica

    Se você usar o console do PowerShell para executar os comandos, escape as cadeias de caracteres no argumento do --generic-configurations nesta etapa e na próxima etapa. Por exemplo: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'.

  5. (Opcional) Se seu aplicativo usar uma identidade gerenciada atribuída pelo usuário, garanta que a identidade esteja configurada no aplicativo Web e, em seguida, defina a propriedade acrUserManagedIdentityID, para especificar o ID do cliente:

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

    Substitua <identity-name> de sua identidade gerenciada atribuída pelo usuário e use a saída <client-id> para configurar o ID de identidade gerenciada atribuída pelo usuário.

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

O aplicativo Web agora usa a identidade gerenciada para efetuar pull do Registro de Contêiner do Azure.

Usar uma imagem de um registro protegido por rede

Para se conectar e efetuar pull 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 com um ponto de extremidade privado para o Registro de Contêiner do Azure. Depois de configurar a rede e a resolução DNS, habilite o roteamento da transferência de imagem pela rede virtual. Defina a configuração do vnetImagePullEnabled site:

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

Solução de problemas sobre o que fazer se o contêiner atualizado não for exibido

Se você alterar as configurações de contêiner do Docker para apontar para um novo contêiner, pode levar alguns minutos para que o aplicativo atenda às solicitações HTTP do novo contêiner. Enquanto o novo contêiner é retirado e iniciado, o Serviço de Aplicativo continua a atender solicitações do contêiner antigo. O Serviço de Aplicativo envia apenas solicitações para o novo contêiner depois que ele é iniciado e está pronto para receber solicitações.

Saiba 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 executa o docker pull comando e puxa todas as camadas de imagem. As camadas são armazenadas em disco, da mesma forma que quando você usa o Docker local. Sempre que o aplicativo é reiniciado, o Serviço de Aplicativo executa o docker pull comando. Ele puxa apenas camadas alteradas. Se não houver alterações, o Serviço de Aplicativo usará as camadas existentes no disco local.

Se o aplicativo alterar as instâncias de computação por qualquer motivo (como alterar os níveis de preços), o Serviço de Aplicativo deverá novamente puxar todas as camadas. O mesmo será verdadeiro se você escalar horizontalmente para adicionar mais instâncias. Além disso, em casos raros, as instâncias do aplicativo podem ser alteradas sem que haja uma operação de escala.

Configurar o número da porta

Por padrão, o Serviço de Aplicativo pressupõe que seu contêiner personalizado escuta na porta 80. Se o contêiner escutar uma porta diferente, defina a configuração do aplicativo WEBSITES_PORT em seu aplicativo do Serviço de Aplicativo. Você pode defini-lo usando o Azure Cloud Shell. No Bash, use o seguinte comando:

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

No PowerShell, use o seguinte comando:

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

Atualmente, o Serviço de Aplicativo permite que o 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 você precisa fornecer externamente. Você pode passá-los usando o Cloud Shell. No Bash, use o seguinte comando:

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

No PowerShell, use o seguinte comando:

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

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

Ao entrar em um contêiner com imagens personalizadas do Docker, você poderá ver apenas algumas variáveis de ambiente se tentar usar comandos como env ou printenv. Para ver todas as variáveis de ambiente dentro do contêiner, como as que você passa para seu aplicativo para uso em runtime, adicione essa linha ao script do ponto de entrada:

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

Veja um exemplo completo.

Se o aplicativo usar imagens de um registro privado ou do Hub do Docker, as credenciais para acessar o repositório serão salvas em 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 reservados é exposto ao aplicativo.

Para contêineres do IIS (Serviços de Informações da Internet) ou do .NET Framework (4.0 ou posterior), as credenciais são automaticamente injetadas em System.ConfigurationManager por meio de configurações do aplicativo .NET e cadeias de conexão pelo Serviço de Aplicativo. 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_

Você pode usar esse método para aplicativos de contêiner único ou de vários contêineres, em que as variáveis de ambiente são especificadas no docker-compose.yml arquivo.

Usar armazenamento compartilhado persistente

Você pode usar o C:\home diretório em seu sistema de arquivos de contêiner personalizado para persistir arquivos entre reinicializações e compartilhá-los entre instâncias. Quando você usa o C:\home diretório, seu contêiner personalizado pode acessar o armazenamento persistente.

Quando o armazenamento persistente é desabilitado, as gravações no C:\home diretório não são mantidas em reinicializações de aplicativo ou em várias instâncias. Quando o armazenamento persistente está habilitado, todas as gravações no C:\home diretório persistem. Todas as instâncias de um aplicativo expandido podem acessá-las. Quando o contêiner é iniciado, se algum arquivo estiver presente no armazenamento persistente, ele substituirá qualquer conteúdo no C:\home diretório do contêiner.

A única exceção é o C:\home\LogFiles diretório. Esse diretório armazena os logs de contêiner e de aplicativo. A pasta sempre persistirá quando o aplicativo for reiniciado se o registro em log do aplicativo estiver habilitado com a opção Sistema de Arquivos , se o armazenamento persistente está habilitado ou não. Em outras palavras, quando você habilita ou desabilita o armazenamento persistente, ele não afeta o comportamento do registro em log do aplicativo.

Por padrão, o armazenamento persistente está habilitado nos contêineres personalizados do Windows. Para desabilitá-lo, use o Cloud Shell para definir o valor da configuração do aplicativo WEBSITES_ENABLE_APP_SERVICE_STORAGE para false. No Bash, use o seguinte comando:

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

No PowerShell, use o seguinte comando:

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

Você pode usar o /home diretório em seu sistema de arquivos de contêiner personalizado para persistir arquivos entre reinicializações e compartilhá-los entre instâncias. Quando você usa o C:\home diretório, seu contêiner personalizado pode acessar o armazenamento persistente. Tenha em mente que os dados que você salva dentro /home contribuem para a cota de espaço de armazenamento incluída no plano do Serviço de Aplicativo.

Quando o armazenamento persistente é desabilitado, as gravações no C:\home diretório não são mantidas em reinicializações de aplicativo ou em várias instâncias. Quando o armazenamento persistente está habilitado, todas as gravações no C:\home diretório persistem. Todas as instâncias de um aplicativo expandido podem acessá-las. Quando o contêiner é iniciado, se algum arquivo estiver presente no armazenamento persistente, ele substituirá qualquer conteúdo no C:\home diretório do contêiner.

A única exceção é o C:\home\LogFiles diretório. Esse diretório armazena os logs de contêiner e de aplicativo. A pasta sempre persistirá quando o aplicativo for reiniciado se o registro em log do aplicativo estiver habilitado com a opção Sistema de Arquivos , se o armazenamento persistente está habilitado ou não. Em outras palavras, quando você habilita ou desabilita o armazenamento persistente, ele não afeta o comportamento do registro em log do aplicativo.

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

Por padrão, o armazenamento persistente é desabilitado nos contêineres personalizados do Linux. Para habilitá-lo, defina o valor da configuração do aplicativo WEBSITES_ENABLE_APP_SERVICE_STORAGE como true usando o Cloud Shell. No Bash, use o seguinte comando:

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

No PowerShell, use o seguinte comando:

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.

Detectar sessão HTTPS

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

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

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

Durante o início do contêiner, as chaves são geradas e injetadas automaticamente no contêiner como as chaves do computador para ASP.NET rotinas criptográficas. Você pode encontrar essas chaves em seu contêiner procurando as seguintes variáveis de ambiente: MACHINEKEY_Decryption, , MACHINEKEY_DecryptionKeye MACHINEKEY_ValidationKeyMACHINEKEY_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

Para se conectar ao contêiner do Windows diretamente para tarefas de diagnóstico, acesse https://<app-name>.scm.azurewebsites.net/ e selecione a opção SSH. Essa 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 no armazenamento compartilhado.
  • Em um aplicativo de expansão, a sessão SSH conecta-se a uma das instâncias de contêiner. Você pode selecionar uma instância diferente na lista suspensa Instância no menu Kudu superior.
  • Com exceção das alterações no armazenamento compartilhado, qualquer alteração feita no contêiner de dentro da sessão SSH não persiste quando o aplicativo é reiniciado. Essas alterações não fazem parte da imagem do Docker. Para persistir alterações como configurações de registro e instalação de software, faça-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 habilitados por padrão. Você precisa ativar manualmente os logs de aplicativos ou os logs do servidor web dentro do contêiner. Para obter mais informações, consulte Habilitar o registro em log do aplicativo e Habilitar o registro em log do servidor Web.

Você pode acessar logs do Docker de várias maneiras:

portal do Azure

Os logs do Docker são exibidos no portal do Azure no painel Configurações de Contêiner do aplicativo. Os logs são truncados. Para baixar todos os logs, selecione Baixar.

Kudu

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

Por padrão, você não pode acessar a C:\home\LogFiles pasta no terminal SSH 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á sendo usado no momento usando um cliente FTP, poderá receber um erro devido a um bloqueio de arquivo.

Kudu API

Vá diretamente para https://<app-name>.scm.azurewebsites.net/api/logs/docker para ver os metadados dos logs do Docker. Você pode ver mais de um arquivo de log listado. Você pode usar a href propriedade para baixar diretamente o arquivo de log.

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 do Serviço de Aplicativo Limite de memória padrão por aplicativo (em MB)
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2.048
P3Mv3 2.048
P4Mv3 2560
P5Mv3 3072

Você pode alterar esse valor fornecendo a configuração do WEBSITE_MEMORY_LIMIT_MB aplicativo no Cloud Shell. No Bash, use o seguinte comando:

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

No PowerShell, use o seguinte comando:

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

O valor é definido em megabytes (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 todos os aplicativos não pode exceder 8 GB. Para obter mais informações sobre a quantidade de memória disponível, consulte o plano de serviço Premium v3 nos 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 seu tipo de preço. Talvez você queira reduzir o número de núcleos usados pelo slot de preparo. Para reduzir o número de núcleos que um contêiner usa, defina a configuração do WEBSITE_CPU_CORES_LIMIT aplicativo como o número preferencial de núcleos. Você pode defini-lo usando o Cloud Shell. No Bash, use o seguinte comando:

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

No PowerShell, use o seguinte comando:

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

Dica

Atualizar a configuração do aplicativo dispara a reinicialização automática, o que causa um tempo de inatividade mínimo. Para um aplicativo de produção, considere fazer swap em um slot de preparo. Altere a configuração do aplicativo no slot de teste e, em seguida, troque-o de volta para produção.

Para verificar o número ajustado, abra uma sessão SSH usando o portal do Azure ou o portal do Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host). Insira os comandos a seguir 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 hyper-threading. Para descobrir quantos núcleos estão disponíveis, consulte o plano de serviço Premium v3 nos preços do Serviço de Aplicativo.

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 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 aplicativo estiver com uso intensivo de recursos, o contêiner poderá não responder ao ping HTTP a tempo. Para controlar o que acontece quando os pings HTTP falham, defina a configuração do CONTAINER_AVAILABILITY_CHECK_MODE aplicativo. Você pode defini-lo usando o Cloud Shell. No Bash, use o seguinte comando:

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

No PowerShell, use o seguinte comando:

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

A tabela a seguir mostra os valores possíveis:

Valor Description
Repair Reinicie o contêiner após três verificações de disponibilidade consecutivas.
ReportOnly O valor padrão. Relate o contêiner nos logs do Docker após três verificações de disponibilidade consecutivas, mas não reinicie-o.
Off Não verifica a disponibilidade.

Suporte para contas de serviço gerenciado de grupo

Não há suporte para contas de serviço gerenciado de grupo em contêineres do Windows no Serviço de Aplicativo.

Habilitar SSH

Você pode usar o Secure Shell (SSH) para executar remotamente comandos administrativos 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 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 cumprir o recurso SSH do portal do Azure:

    • O Port valor deve ser definido como 2222.
    • Os Ciphers valores devem incluir pelo menos um item nesta lista: aes128-cbc, ou 3des-cbcaes256-cbc.
    • Os MACs valores devem incluir pelo menos um item nesta lista: hmac-sha1 ou hmac-sha1-96.

  2. Crie um script de ponto de entrada nomeado entrypoint.sh ou altere qualquer arquivo de ponto 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 como iniciar um aplicativo Python. Substitua o último comando conforme o idioma ou stack do projeto.

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

  3. Adicione as instruções a seguir ao Dockerfile de acordo com a distribuição de imagem base. Essas instruções copiam os novos arquivos, instalam o servidor OpenSSH, definem 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 raiz deve ser exatamente Docker! porque o Serviço de Aplicativo a usa 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 só pode ser acessada na rede de ponte de uma rede virtual privada. Um invasor na Internet não pode acessá-lo.

  4. Reconstrua e faça o push da imagem do Docker para o repositório, e então teste o recurso SSH do Aplicativo Web no portal do Azure.

Para obter mais informações de solução de problemas, consulte o blog do Serviço de Aplicativo do Azure: Habilitar o SSH em um aplicativo Web Linux para contêineres.

Acessar logs de diagnóstico

É possível acessar os logs de console gerados de dentro do contêiner.

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

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

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

Depois de ativar o log do 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 log a qualquer momento, use o atalho de teclado Ctrl+C.

Configurar aplicativos multicontêineres

Observação

O recurso Docker Compose será desativado em 31 de março de 2027. Os contêineres sidecar têm êxito em aplicativos de vários contêineres no Serviço de Aplicativo. Para novos serviços, confira Tutorial: configurar um contêiner sidecar para contêiner personalizado no Serviço de Aplicativo do Azure. Para aplicativos multi-contêiner existentes no Serviço de Aplicativo, confira Migrar 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 habilitar o armazenamento persistente, a configuração do Docker Compose deve apontar para um local de armazenamento fora do contêiner. Locais de armazenamento dentro do contêiner não mantêm as alterações após o reinício do aplicativo.

Para habilitar o armazenamento persistente, defina a configuração do WEBSITES_ENABLE_APP_SERVICE_STORAGE aplicativo. Use 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 seu 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 que mapeia para o armazenamento persistente do 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 ou autorização.
  • Identidades gerenciadas.
  • CORS (compartilhamento de recursos entre origens).
  • Integração de rede virtual com cenários do Docker Compose.

O Docker Compose no Serviço de Aplicativo do Azure atualmente tem um limite de 4.000 caracteres.

Opções do Docker Compose

As seções a seguir mostram opções de configuração do Docker Compose compatíveis e sem suporte.

Opções com suporte

Opções sem suporte

  • build (não permitido)
  • depends_on (ignorado)
  • networks (ignorado)
  • secrets (ignorado)
  • Portas diferentes de 80 e 8080 (ignoradas)
  • Variáveis de ambiente padrão como $variable e ${variable} (ao contrário do Docker)

Limitações de sintaxe

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

Observação

Quaisquer outras opções não mencionadas explicitamente são ignoradas na visualização.

Ignore a mensagem robots933456 nos 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. O Serviço de Aplicativo o usa para verificar se o contêiner é capaz de atender solicitações. Uma resposta de erro "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

  • Last updated on