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

  • Artigo

Este artigo mostra como configurar um contêiner personalizado para ser executado no 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. Há também um guia de início rápido de aplicativo de vários contêineres 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).

Observação

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

Imagens pai com suporte

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

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

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

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>

Para <nome de usuário> e <senha>, forneça as credenciais de logon para sua conta de registro particular.

Usar identidade gerenciada para efetuar pull da imagem do Registro de Contêiner do Azure

Use as etapas a seguir a fim de configurar seu aplicativo Web para efetuar pull do ACR (Registro de Contêiner do Azure) usando identidade gerenciada. As etapas usam a identidade gerenciada atribuída pelo sistema, mas também é possível 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 da entidade de serviço da identidade atribuída.

  2. Obtenha o ID de 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 de recurso do Registro de Contêiner do Azure.

  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> pelo 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 pull de 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> pelo nome do aplicativo Web.

    Dica

    Caso esteja usando o console do PowerShell para executar os comandos, é necessário escapar das cadeias de caracteres no argumento --generic-configurations nesta 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>"}'

Está tudo pronto, e 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 pela rede

Para se conectar e efetuar pull de um registro dentro de uma rede virtual ou local, seu aplicativo deve se integrar a uma VNET (rede virtual). A integração VNET também é necessária para o Registro de Contêiner do Azure com ponto de extremidade privado. Quando a sua rede e a resolução de DNS são configuradas, você habilita o roteamento do pull da imagem pela rede virtual definindo a configuração do site vnetImagePullEnabled:

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

Eu não vejo o contêiner atualizado

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 está sendo efetuado o pull e inicialização do novo contêiner, o Serviço de Aplicativo continua a atender solicitações do contêiner antigo. Somente quando o novo contêiner for iniciado e estiver pronto para receber solicitações, o Serviço de Aplicativo começará 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 efetua pull de todas as camadas da imagem. Essas camadas são armazenadas em disco, como se você estivesse usando o Docker local. Cada vez que o aplicativo é reiniciado, o Serviço de Aplicativo faz um docker pull, mas apenas efetua pull das camadas que foram 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 escalar ou reduzir verticalmente os tipos de preço, o Serviço de Aplicativo deverá efetuar pull de todas as camadas novamente. O mesmo será verdadeiro se você escalar horizontalmente para adicionar mais instâncias. Também há casos raros em que as instâncias de aplicativo podem ser alteradas sem uma operação de escala.

Configurar o número da porta

Por padrão, o Serviço de Aplicativo presume que o contêiner personalizado está escutando 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-la por meio do Cloud Shell. No 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 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 precisam ser fornecidas externamente. Você pode passá-las por meio do Cloud Shell. No 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 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.

Se o 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 reservados é exposto ao aplicativo.

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.

Usar armazenamento compartilhado persistente

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á desabilitado nos contêineres personalizados do Windows. 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}

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 está habilitado nos contêineres personalizados do Linux. 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}

Observação

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

Detectar sessão HTTPS

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

Os front-ends ficam localizados dentro dos data centers do Azure. Caso use TLS/SSL com seu aplicativo, o tráfego na Internet sempre será criptografado com segurança.

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:

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.

SKU do Plano de 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 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}

Observação

A atualização da configuração do aplicativo dispara o reinício automático, causando tempo de inatividade mínimo. Para um aplicativo de produção, considere alterná-lo em um slot de preparo, altere a configuração do aplicativo no slot de preparo e, em seguida, alterne-o novamente em produção.

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:

Valor Descrições
Repair Reinicia o contêiner após três verificações de disponibilidade consecutivas
ReportOnly O valor padrão. Não reinicia contêiner, mas gera relatório nos logs do Docker para o contêiner após três verificações de disponibilidade consecutivas.
Desativado Não verifica a disponibilidade.

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:

    #!/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:

    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

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

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

Observação

Qualquer outra opção não explicitamente chamada também é ignorada na Visualização Pública.

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.

Próximas etapas

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

Tutorial: Aplicativo WordPress cm vários contêineres

Ou veja mais recursos: