Partilhar via

Configurar um contentor personalizado para o Serviço de Aplicações do Azure

  • Artigo

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 usuários do Serviço de Aplicativo do Azure devem seguir primeiro o início rápido e o tutorial do contêiner personalizado.

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

Nota

A entidade de serviço não tem mais suporte para a autenticação pull de imagem de contêiner do Windows. A maneira recomendada é usar a Identidade Gerenciada para contêineres Windows e Linux

Imagens pai suportadas

Para sua imagem personalizada do Windows, você deve escolher a imagem pai certa (imagem base) para a estrutura desejada:

  • Para implantar aplicativos do .NET Framework, use uma imagem pai baseada na versão LTSC (Canal de Manutenção de Longo Prazo) Principal do Windows Server 2019.
  • Para implantar aplicativos .NET Core, use uma imagem pai baseada na versão do Windows Server 2019 Nano Semi-Annual Servicing Channel (SAC).

O carregamento das imagens principais durante o arranque da aplicação demora algum tempo. No entanto, pode utilizar uma das seguintes imagens principais que já estão em cache no Serviço de Aplicações do Azure para reduzir o tempo de arranque:

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 pelo sistema, mas você também pode usar a identidade gerenciada atribuída pelo usuário.

  1. Habilite a identidade gerenciada atribuída ao 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 <app-name> pelo nome usado na etapa anterior. A saída do comando (filtrada --query pelos argumentos e --output ) é a ID da entidade 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 registo. A saída do comando (filtrada --query pelos argumentos e --output ) é a ID de 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 az webapp identity assign comando
    • <registry-resource-id> com o 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.

    Gorjeta

    Se você estiver usando o console do PowerShell para executar os comandos, precisará escapar das cadeias de caracteres no --generic-configurations argumento nesta e na próxima etapa. 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 a identidade gerenciada atribuída pelo <identity-name> usuário e use a saída <client-id> para configurar a 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>"}'

Você está pronto, e 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 (VNET). A integração VNET também é necessária para o Registro de Contêiner do Azure com ponto de extremidade privado. Quando a resolução de rede e DNS estiver configurada, você habilitará o roteamento da imagem puxada pela rede virtual definindo 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]

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. Cada vez que o aplicativo é reiniciado, o Serviço de Aplicativo faz um docker pull, mas apenas puxa as camadas que foram 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 predefinição, o Serviço Aplicacional assume que o seu contentor personalizado está a escutar na porta 80. Se o contêiner escutar uma porta diferente, defina a configuração do WEBSITES_PORT aplicativo no aplicativo do Serviço de Aplicativo. Você pode configurá-lo através do 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. Você pode passá-los através do 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 em variáveis de ambiente: DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME e DOCKER_REGISTRY_SERVER_PASSWORD. Devido a riscos de segurança, nenhum desses nomes de variáveis reservadas é exposto ao aplicativo.

Para contêineres baseados em IIS ou .NET Framework (4.0 ou superior), eles são injetados como System.ConfigurationManager configurações de aplicativo .NET e cadeias de conexão automaticamente pelo Serviço de Aplicativo. Para todas as outras linguagens ou estruturas, eles são fornecidos 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 .

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 C:\home diretório é fornecido para permitir que seu contêiner personalizado acesse o armazenamento persistente.

Quando o armazenamento persistente é desativado, as gravações no diretório não são persistidas nas reinicializações do C:\home aplicativo ou em várias instâncias. Quando o armazenamento persistente está habilitado, todas as gravações no C:\home diretório são mantidas e podem ser acessadas por todas as instâncias de um aplicativo dimensionado. Além disso, qualquer conteúdo dentro do C:\home diretório do contêiner é substituído por quaisquer arquivos existentes já presentes no armazenamento persistente quando o contêiner é iniciado.

A única exceção é o C:\home\LogFiles diretório, que é usado para armazenar 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 do armazenamento persistente que está sendo habilitado ou desativado. 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 por meio do 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 /home diretório é fornecido para permitir que seu contêiner personalizado acesse o armazenamento persistente. Salvar dados dentro /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 não são persistidas nas reinicializações do /home aplicativo ou em várias instâncias. Quando o armazenamento persistente está habilitado, todas as gravações no /home diretório são mantidas e podem ser acessadas por todas as instâncias de um aplicativo dimensionado. Além disso, qualquer conteúdo dentro do /home diretório do contêiner é substituído por quaisquer arquivos existentes já presentes no armazenamento persistente quando o contêiner é iniciado.

A única exceção é o /home/LogFiles diretório, que é usado para armazenar 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 do armazenamento persistente que está sendo habilitado ou desativado. Em outras palavras, habilitar ou desabilitar o armazenamento persistente não afeta o comportamento de log do aplicativo.

É recomendável gravar 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 e 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 por meio do 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}

Nota

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

Detetar sessão HTTPS

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

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

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

Durante o início do contêiner, as chaves geradas automaticamente são injetadas no contêiner como as chaves da máquina 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_DecryptionKey, MACHINEKEY_ValidationKey, MACHINEKEY_Validation.

As novas chaves em cada reinicialização podem redefinir ASP.NET autenticação de formulários e o estado de exibição, se seu aplicativo depender delas. Para impedir a regeneração automática de chaves, defina-as manualmente como configurações do aplicativo Serviço de Aplicativo.

Conecte-se ao contêiner

Você pode se conectar ao contêiner do Windows diretamente para tarefas de diagnóstico navegando e https://<app-name>.scm.azurewebsites.net/ 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 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.
  • Qualquer alteração feita no contêiner de dentro da sessão SSH não persiste quando seu aplicativo é reiniciado (exceto alterações no armazenamento compartilhado), porque não faz 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 host do Docker (logs da plataforma) são enviados por padrão, mas os logs de aplicativos ou logs do servidor Web de dentro do contêiner precisam ser habilitados manualmente. 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, 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.

De Kudu

Navegue até a https://<app-name>.scm.azurewebsites.net/DebugConsole pasta LogFiles e selecione-a para ver os arquivos de log individuais. 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 por padrão porque o C:\home\LogFiles 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 ver os metadados dos logs do Docker. Você pode ver mais de um arquivo de log listado, e 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 do Serviço de Aplicativo 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 por meio do 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. Informações sobre a quantidade de memória disponível para cada camada 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 nível de preço escolhido. Você pode querer reduzir o número de núcleos que seu slot de preparo usa, por exemplo. 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 através do 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}

Nota

A atualização da configuração do aplicativo aciona a reinicialização automática, causando um tempo de inatividade mínimo. Para um aplicativo de produção, considere trocá-lo por um slot de preparação, altere a configuração do aplicativo no slot de preparo e troque-o novamente para a produção.

Verifique seu número ajustado abrindo uma sessão SSH do portal ou através do portal Kudu (https://<app-name>.scm.azurewebsites.net/webssh/host) e digitando os seguintes comandos usando o PowerShell. Cada comando gera 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 para cada camada 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 comportamento de ping de integridade

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, informando que o contêiner não foi iniciado.

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 através do 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:

Value 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 contêiner, mas relate nos logs do Docker para o contêiner após três verificações de disponibilidade consecutivas.
Desativado 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, as seguintes etapas são necessárias:

  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

    Nota

    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 tem de incluir, pelo menos, um item na lista aes128-cbc,3des-cbc,aes256-cbc.
    • MACs tem de incluir, pelo menos, um item na 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 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" ]

    Nota

    A senha de root deve ser exatamente Docker! como é 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 envie por push a imagem do Docker para o Registro e teste o recurso SSH do Aplicativo Web no portal do Azure.

Mais informações sobre solução de problemas estão disponíveis no 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.

Primeiro, ative o log de 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.

Quando o log de 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 não vir os registos da consola imediatamente, volte a consultar dentro de 30 segundos.

Para interromper o streaming de logs 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

Nota

Os contêineres de sidecar (visualização) terão êxito aos aplicativos de vários contêineres no Serviço de Aplicativo. Para começar, consulte Tutorial: Configurar um contêiner sidecar para contêiner personalizado no Serviço de Aplicativo do Azure (visualização).

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.

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

WEBAPP_STORAGE_HOME é uma variável de ambiente no Serviço de Aplicações, que está mapeado para um armazenamento persistente para a sua aplicação. 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 visualização. Os seguintes recursos da plataforma do Serviço de Aplicativo não são suportados:

  • Autenticação/Autorização
  • Identidades Geridas
  • CORS
  • A integração de rede virtual não é suportada para cenários do Docker Compose
  • 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

  • comando
  • entrypoint
  • ambiente
  • image
  • ports
  • restart
  • services
  • volumes (não há suporte para o mapeamento para o Armazenamento do Azure)

Opções não suportadas

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

Nota

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

robots933456 nos registos

Pode ver a seguinte mensagem nos registos do contentor:

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 simplesmente que o caminho não existe, mas permite que o Serviço de Aplicações saiba que o contentor está em bom estado de funcionamento e pronto para responder aos pedidos.

Próximos passos

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

Tutorial: Configurar um contêiner sidecar para contêiner personalizado no Serviço de Aplicativo do Azure (visualização)

Ou veja mais recursos: