Partilhar via

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

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

Aprenda sobre conceitos-chave e obtenha instruções para a containerização de aplicações Windows no App Service. Os novos utilizadores devem primeiro seguir o início rápido de contentor personalizado e o tutorial.

Aprenda sobre conceitos-chave e obtenha instruções para a containerização de aplicações Linux no App Service. Os novos utilizadores deverão primeiro seguir o quickstart personalizado do container e o tutorial. Para contêineres de sidecar, consulte Tutorial: Configurar um contêiner de sidecar para contêiner personalizado no Serviço de Aplicativo do Azure.

Observação

A utilização de um principal de serviço para autenticação de pull de imagens de contentores no Windows já não é suportada. Recomendamos que utilize a identidade gerida tanto para contentores Windows como Linux.

Imagens pai suportadas

Selecione a imagem principal certa (imagem base) para o framework que pretende para a sua imagem personalizada do Windows:

  • Para implementar aplicações .NET Framework, utilize uma imagem principal baseada na versão do Windows Server 2019 Core Long-Term Servicing Channel.
  • Para implementar aplicações .NET Core, utilize uma imagem principal baseada na versão do Windows Server 2019 Nano Annual Channel.

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

Alterar a imagem do Docker de um contêiner personalizado

Use o seguinte comando para alterar a imagem Docker atual para uma nova imagem num contentor personalizado existente:

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>

Forneça as credenciais de início de sessão da sua conta de registo privado nos campos \<username> e \<password>.

Use a identidade gerida para extrair uma imagem do Azure Container Registry

Use os seguintes passos para configurar a sua aplicação web para extrair do Azure Container Registry usando identidade gerida. Os passos usam identidade gerida atribuída pelo sistema, mas também pode usar identidade gerida atribuída pelo utilizador.

  1. Ative a identidade gerida atribuída pelo sistema para a aplicação 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 pelos argumentos --query e --output, é o ID principal de serviço da identidade atribuída.

  2. Obtenha o ID de recurso do seu registo de contentores:

    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 registo do contentor.

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

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

    Substitua os seguintes valores:

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

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

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

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

    Substitua os seguintes valores:

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

    Sugestão

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

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

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

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

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

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

Use uma imagem de um registo 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. Também precisas de integração de rede virtual para o Azure Container Registry com um endpoint privado. Depois de configurar a rede e a resolução DNS, ative o encaminhamento da imagem através da rede virtual. Configure a definição do vnetImagePullEnabled site:

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

Soluciona o que fazer se não conseguires ver o container 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 contentor é puxado e iniciado, o App Service continua a servir pedidos do contentor antigo. O App Service só envia pedidos para o novo contentor depois de este iniciar e estar pronto para receber pedidos.

Aprenda como as imagens dos contentores são armazenadas

Na primeira vez que executas uma imagem Docker personalizada no App Service, o App Service executa o docker pull comando e puxa todas as camadas da imagem. As camadas são armazenadas em disco, tal como quando usas o Docker on-premises. Cada vez que a aplicação reinicia, o App Service executa o docker pull comando. Extrai apenas camadas alteradas. Se não houver alterações, o Serviço de Aplicativo usará camadas existentes no disco local.

Se a aplicação alterar instâncias de computação por qualquer motivo (como mudar de escalões de preço), o App Service tem de voltar a recarregar todas as camadas. O mesmo é verdadeiro se você expandir para adicionar mais instâncias. Além disso, em casos raros, as instâncias da aplicação podem mudar sem uma operação de escala.

Configurar o número da porta

Por padrão, o App Service assume que o seu contentor personalizado escuta na porta 80. Se o contentor escutar uma porta diferente, defina a configuração de aplicação WEBSITES_PORT no aplicativo do Serviço de Aplicações. Podes configurá-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 seu contêiner exponha apenas uma porta para solicitações HTTP.

Configurar variáveis de ambiente

O teu contentor personalizado pode usar variáveis de ambiente que precisas de fornecer externamente. Podes passá-los usando 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 a sua aplicação corre, as definições da app App Service são automaticamente injetadas 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.

Quando se liga por SSH a um contentor com imagens Docker personalizadas, pode 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 contentor, como as que passa para a sua aplicação para uso em tempo de execução, adicione esta linha ao seu script 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 a sua aplicação usar imagens de um registo privado ou do Docker Hub, as credenciais para aceder ao repositório são guardadas nas 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 containers do Internet Information Services (IIS) ou .NET Framework (4.0 ou posterior), as credenciais são automaticamente inseridas nas System.ConfigurationManager definições e strings de ligação da aplicação .NET pelo App Service. Para todas as outras linguagens ou frameworks, são fornecidos como variáveis de ambiente para o processo, com um dos seguintes prefixos:

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

Pode usar este método tanto para aplicações de um único contentor como de vários contentores, onde as variáveis de ambiente são especificadas no ficheiro docker-compose.yml.

Usar armazenamento compartilhado persistente

Podes usar o C:\home diretório no teu sistema de ficheiros personalizado para persistir ficheiros entre reinicios e partilhá-los entre instâncias. Quando usa o C:\home diretório, o seu contentor personalizado pode aceder ao armazenamento persistente.

Quando o armazenamento persistente está desativado, as escritas no C:\home diretório não são mantidas durante reinícios da aplicação ou em múltiplas instâncias. Quando o armazenamento persistente está ativado, todas as escritas no C:\home diretório persistem. Todas as instâncias de uma aplicação dimensionada podem acessá-las. Quando o contentor inicia, se houver ficheiros no armazenamento persistente, eles sobreescrevem qualquer conteúdo no C:\home diretório do contentor.

A única exceção é o C:\home\LogFiles diretório. Este diretório armazena o contêiner e os logs do aplicativo. A pasta persiste sempre quando a aplicação reinicia se o registo de aplicações estiver ativado com a opção de Sistema de Ficheiros , independentemente de o armazenamento persistente estar ativado ou não. Ou seja, quando ativas ou desativas o armazenamento persistente, isso não afeta o comportamento do registo de aplicações.

Por padrão, o armazenamento persistente é habilitado em contêineres personalizados do Windows. Para desativá-lo, defina a configuração da aplicação WEBSITES_ENABLE_APP_SERVICE_STORAGE para false usando 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=false

No PowerShell, use o seguinte comando:

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

Podes usar o /home diretório no teu sistema de ficheiros personalizado para persistir ficheiros entre reinicios e partilhá-los entre instâncias. Quando usa o C:\home diretório, o seu contentor personalizado pode aceder ao armazenamento persistente. Tenha em mente que os dados que guarda dentro de /home contribuem para a quota de espaço de armazenamento incluída no plano do Serviço de Aplicações.

Quando o armazenamento persistente está desativado, as escritas no C:\home diretório não são mantidas durante reinícios da aplicação ou em múltiplas instâncias. Quando o armazenamento persistente está ativado, todas as escritas no C:\home diretório persistem. Todas as instâncias de uma aplicação dimensionada podem acessá-las. Quando o contentor inicia, se houver ficheiros no armazenamento persistente, eles sobreescrevem qualquer conteúdo no C:\home diretório do contentor.

A única exceção é o C:\home\LogFiles diretório. Este diretório armazena o contêiner e os logs do aplicativo. A pasta persiste sempre quando a aplicação reinicia se o registo de aplicações estiver ativado com a opção de Sistema de Ficheiros , independentemente de o armazenamento persistente estar ativado ou não. Ou seja, quando ativas ou desativas o armazenamento persistente, isso não afeta o comportamento do registo de aplicações.

Recomendamos que escreva dados para /home ou monta um caminho de armazenamento Azure. Os dados que escreves fora desses caminhos não são persistentes durante os reinícios. Os dados são guardados no espaço de disco do host gerido pela plataforma, separado da quota de armazenamento de ficheiros dos planos do App Service.

Por padrão, o armazenamento persistente é desativado em contêineres personalizados do Linux. Para o ativar, defina o WEBSITES_ENABLE_APP_SERVICE_STORAGE valor de definição da app para 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.

Detetar sessão HTTPS

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

Os front-ends estão localizados dentro dos datacenters Azure. Se usares TLS com a tua aplicação, o teu tráfego na internet está sempre encriptado de forma segura.

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

Durante o início do contentor, as chaves são automaticamente geradas e injetadas no contentor como as chaves de máquina para rotinas criptográficas ASP.NET. Pode encontrar estas chaves no seu contentor procurando as seguintes variáveis de ambiente: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, e MACHINEKEY_Validation.

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

Conecte-se ao contêiner

Para se ligar diretamente ao seu contentor do Windows para tarefas de diagnóstico, vá e https://<app-name>.scm.azurewebsites.net/ selecione a opção SSH. Esta opção estabelece uma sessão SSH direta na qual pode executar comandos dentro do seu contentor.

  • Ele funciona separadamente do navegador gráfico acima dele, que mostra apenas os arquivos em seu armazenamento compartilhado.
  • Numa aplicação escalonada, a sessão SSH liga-se a uma das instâncias do contentor. Você pode selecionar uma instância diferente na lista suspensa Instância no menu superior do Kudu.
  • Exceto por alterações no armazenamento partilhado, qualquer alteração que faças no contentor dentro da sessão SSH não persiste quando a tua aplicação reinicia. Estas alterações não fazem parte da imagem do Docker. Para persistir alterações como definições do registo e instalação de software, faça com que façam parte do Dockerfile.

Aceder aos registos de diagnósticos

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

Pode aceder aos registos do Docker de várias formas:

portal do Azure

Os registos do Docker são exibidos no portal Azure, no painel de Definições do Container da sua aplicação. Os registos são truncados. Para baixar todos os logs, selecione Download.

Kudu

Para ver os ficheiros de registo individuais, vá para https://<app-name>.scm.azurewebsites.net/DebugConsole e selecione LogFiles pasta. Para descarregar todo LogFiles o diretório, selecione o ícone Download à esquerda do nome do diretório. Também pode aceder a esta pasta usando um cliente FTP.

Por defeito, não consegues aceder à C:\home\LogFiles pasta no terminal SSH porque o armazenamento partilhado persistente não está ativado. Para habilitar esse comportamento no terminal do console, habilite o armazenamento compartilhado persistente.

Se tentares descarregar o registo do Docker que está atualmente em uso usando um cliente FTP, podes receber um erro devido a um bloqueio de ficheiros.

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. Pode usar a href propriedade para descarregar diretamente o ficheiro de registo.

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 defeito, todos os contentores do Windows implementados no Azure App Service têm um limite de memória configurado. A tabela seguinte lista as definições padrão por SKU do plano App Service.

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

Pode alterar este valor fornecendo a definição da WEBSITE_MEMORY_LIMIT_MB aplicação 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 hospedeiro. Por exemplo, num plano de App Service com 8 GB de RAM, o total acumulado de WEBSITE_MEMORY_LIMIT_MB todas as aplicações não pode exceder 8 GB. Para mais informações sobre a quantidade de memória disponível, consulte o plano de serviço Premium v3 em preços de Serviços de Aplicação.

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

Por defeito, um container do Windows utiliza todos os núcleos disponíveis para o seu escalão de preço. Talvez você queira reduzir o número de núcleos que o seu ambiente de testes usa. Para reduzir o número de núcleos que um contentor utiliza, defina a WEBSITE_CPU_CORES_LIMIT definição da aplicação para o número preferido de núcleos. Podes configurá-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}

Sugestão

A atualização da configuração do aplicativo aciona a reinicialização automática, o que causa um tempo de inatividade mínimo. Para uma aplicação de produção, considera trocá-la para um slot de staging. Altere a configuração da aplicação no slot de staging e depois volte a colocá-la em produção.

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

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

Os processadores podem ser multinúcleos ou de hiper-threading. Para saber quantos núcleos estão disponíveis, consulte o plano de serviços Premium v3 na página de preços do App Service.

Personalizar o comportamento de ping de saúde

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

Se a sua aplicação for intensiva em recursos, o contentor pode não responder ao ping HTTP a tempo. Para controlar o que acontece quando os pings HTTP falham, defina a configuração da aplicação CONTAINER_AVAILABILITY_CHECK_MODE. Podes configurá-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. Reporta o contentor nos registos Docker após três verificações consecutivas de disponibilidade, mas não o reinicies.
Off Não verifique a disponibilidade.

Suporte para contas de serviço gerido em grupo

Contas de serviço gerido em grupo não são suportadas em contentores do Windows no App Service.

Ativar SSH

Pode usar o Secure Shell (SSH) para executar comandos administrativos remotamente a partir de um terminal de linha de comandos. Para ativar a funcionalidade de consola SSH do portal Azure com contentores personalizados, siga estes passos:

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

    Port 			2222
ListenAddress 		0.0.0.0
LoginGraceTime 		180
X11Forwarding 		yes
Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1,hmac-sha1-96
StrictModes 		yes
SyslogFacility 		DAEMON
PasswordAuthentication 	yes
PermitEmptyPasswords 	no
PermitRootLogin 	yes
Subsystem sftp internal-sftp

    Observação

    Este ficheiro configura o OpenSSH e deve incluir os seguintes itens para cumprir a funcionalidade SSH do portal Azure:

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

  2. Crie um script de entrada com nome entrypoint.sh ou altere qualquer ficheiro 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 iniciar um aplicativo Python. Substituir o último comando de acordo com a linguagem 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 seguintes instruções ao Dockerfile de acordo com a distribuição base da imagem. Estas instruções copiam os novos ficheiros, instalam o servidor OpenSSH, definem as permissões adequadas e configuram o ponto de entrada personalizado, e expõem as portas exigidas pela aplicação e pelo servidor SSH, respetivamente:

    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 palavra-passe root deve ser exatamente Docker! porque o App Service a usa para te dar acesso à sessão SSH com o contentor. Essa configuração não permite conexões externas com o contêiner. A porta 2222 do contentor só é acessível dentro da rede bridge de uma rede virtual privada. Um atacante na internet não pode aceder.

  4. Reconstrua e envie a imagem Docker para o registo, e depois teste a funcionalidade SSH da Web App no portal Azure.

Para mais informações sobre resolução de problemas, consulte o blogue Azure App Service: Habilitar SSH numa aplicação web Linux para containers.

Aceder aos registos de diagnósticos

Você pode acessar os logs do console que são gerados de dentro do contêiner.

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

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

Substitua os <app-name> valores e <resource-group-name> por nomes apropriados para a sua aplicação web.

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

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

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

Para parar a transmissão de registos a qualquer momento, use o atalho de teclado Ctrl+C.

Configurar aplicativos de vários contêineres

Observação

O recurso Docker Compose será desativado em 31 de março de 2027. Os contêineres de sidecar sucedem aplicativos de vários contêineres no Serviço de Aplicativo. Para novos serviços, veja Tutorial: Configurar um contentor sidecar para container personalizado no Azure App Service. Para aplicações multi-contentor existentes no App Service, consulte Migrar as suas aplicações Docker Compose para a funcionalidade sidecar.

Usar armazenamento persistente no Docker Compose

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

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

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

No seu ficheiro docker-compose.yml, mapear a opção volumes para ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME é uma variável de ambiente no App Service que corresponde ao armazenamento persistente da 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 pré-visualização. Os seguintes recursos da plataforma do Serviço de Aplicativo não são suportados:

  • Autenticação ou autorização.
  • Identidades gerenciadas.
  • Partilha de recursos entre origens (CORS).
  • Integração de rede virtual com cenários Docker Compose.

O Docker Compose no Azure App Service tem atualmente um limite de 4.000 caracteres.

Opções de composição do Docker

As secções seguintes mostram opções de configuração Docker Compose suportadas e não suportadas.

Opções suportadas

Opções não suportadas

  • 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 sintáticas

  • A primeira instrução YAML no ficheiro precisa sempre de ser version x.x.
  • A secção de portas deve usar números entre aspas.
  • A image > volume secção tem de ser citada e não pode ter definições de permissões.
  • A secção de volumes não pode incluir uma órtese enrolada vazia depois do nome do volume.

Observação

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

Ignorar a mensagem robots933456 nos logs

Poderá ver a seguinte mensagem nos registos de contentores:

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

Pode ignorar esta mensagem. /robots933456.txt é um caminho de URL fictício. O App Service usa-o para verificar se o contentor é capaz de servir pedidos. Uma resposta de erro "404" indica que o caminho não existe e sinaliza ao App Service que o contentor está saudável e pronto para responder a pedidos.

Conteúdo relacionado

  • Last updated on