Funcionalidade do sistema operacional no Serviço de Aplicativo do Azure

Este artigo descreve a funcionalidade de linha de base do sistema operacional que está disponível para todos os aplicativos do Windows em execução no Serviço de Aplicativo do Azure. Essa funcionalidade inclui acesso a arquivos, rede e registro, além de logs e eventos de diagnóstico.

Observação

Os aplicativos Linux no Serviço de Aplicativo são executados em seus próprios contêineres. Você tem acesso root ao contêiner, mas não acesso ao sistema operacional host. Da mesma forma, para aplicativos executados em contêineres do Windows, você tem acesso administrativo ao contêiner, mas não ao sistema operacional host.

Camadas do plano do Serviço de Aplicativos

O Serviço de Aplicativo executa aplicativos do cliente em um ambiente de hospedagem multilocatário.

• Os aplicativos implantados nas camadas Gratuita e Compartilhada são executados em processos de trabalho em máquinas virtuais (VMs) compartilhadas.
• Os aplicativos implantados nas camadas Standard e Premium são executados em VMs dedicadas especificamente para os aplicativos associados a um único cliente.

Observação

Os planos de serviço Gratuito e Partilhado (visualização) do App Service são níveis base que funcionam nas mesmas máquinas virtuais do Azure que outras apps do App Service. Algumas aplicações podem pertencer a outros clientes. Estas camadas destinam-se apenas a fins de desenvolvimento e teste.

Como o Serviço de Aplicativo oferece suporte a uma experiência de dimensionamento perfeita entre camadas, a configuração de segurança imposta aos aplicativos do Serviço de Aplicativo permanece a mesma. Essa configuração garante que os aplicativos não se comportem de forma diferente de repente e falhem de maneiras inesperadas quando um plano do Serviço de Aplicativo muda de uma camada para outra.

Estruturas de desenvolvimento

As camadas de preços do Serviço de Aplicativo controlam a quantidade de recursos de computação (CPU, armazenamento em disco, memória e saída de rede) disponíveis para os aplicativos. No entanto, a amplitude da funcionalidade de estrutura disponível para aplicativos permanece a mesma, independentemente das camadas de escala.

O Serviço de Aplicativo suporta várias estruturas de desenvolvimento, incluindo ASP.NET, ASP clássico, Node.js, PHP e Python. Para simplificar e normalizar a configuração de segurança, os aplicativos do Serviço de Aplicativo normalmente executam as estruturas de desenvolvimento com suas configurações padrão. As estruturas e componentes de tempo de execução que a plataforma fornece são atualizados regularmente para satisfazer os requisitos de segurança e conformidade. Por esta razão, não garantimos versões secundárias ou de patch específicas. Recomendamos que os clientes apontem para as versões principais conforme necessário.

As seções a seguir resumem os tipos gerais de funcionalidade do sistema operacional disponíveis para aplicativos do Serviço de Aplicativo.

Acesso a ficheiros

Existem várias unidades no Serviço de Aplicações, incluindo unidades locais e unidades de rede.

Unidades locais

Em sua essência, o Serviço de Aplicativo é um serviço executado sobre a infraestrutura de PaaS (plataforma como serviço) do Azure. Como resultado, as unidades locais associadas a uma VM são os mesmos tipos de unidade disponíveis para qualquer função de trabalho em execução no Azure. Entre eles contam-se:

• Uma unidade do sistema operativo (%SystemDrive%) cujo tamanho depende do tamanho da VM.
• Uma unidade de recurso (%ResourceDrive%) que o Serviço de Aplicações utiliza internamente.

Uma prática recomendada é sempre usar as variáveis %SystemDrive% de ambiente e %ResourceDrive% em vez de caminhos de arquivo codificados. O caminho raiz retornado dessas duas variáveis de ambiente mudou ao longo do tempo de d:\ para c:\. No entanto, aplicações mais antigas codificadas com referências de caminho de arquivo para d:\ continuarão a funcionar porque o App Service remapeia automaticamente d:\ para apontar para c:\. Como observado anteriormente, é altamente recomendável que você sempre use as variáveis de ambiente ao criar caminhos de arquivo e evite confusão sobre alterações de plataforma no caminho de arquivo raiz padrão.

É importante monitorar a utilização do disco à medida que o aplicativo cresce. Atingir a cota de disco pode ter efeitos adversos em seu aplicativo. Por exemplo:

• O aplicativo pode gerar um erro que indica que não há espaço suficiente no disco.
• Você pode ver erros de disco ao aceder ao console Kudu.
• A implantação a partir do Azure DevOps ou do Visual Studio pode falhar com ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk).
• Seu aplicativo pode ter um desempenho lento.

Unidades de rede (partilhas UNC)

Um dos aspetos exclusivos do Serviço de Aplicativo que tornam a implantação e a manutenção de aplicativos simples é que todos os compartilhamentos de conteúdo são armazenados em um conjunto de compartilhamentos UNC (Convenção Universal de Nomenclatura). Esse modelo mapeia bem o padrão comum de armazenamento de conteúdo usado por ambientes de hospedagem na Web locais que têm vários servidores com balanceamento de carga.

No Serviço de Aplicativo, os compartilhamentos UNC são criados em cada datacenter. Uma porcentagem do conteúdo do usuário para todos os clientes em cada datacenter é alocada para cada compartilhamento UNC. A assinatura de cada cliente tem uma estrutura de diretório reservada numa partilha UNC específica num datacenter. Um cliente pode ter vários aplicativos criados em um datacenter específico, portanto, todos os diretórios que pertencem a uma única assinatura de cliente são criados no mesmo compartilhamento UNC.

Devido à maneira como os serviços do Azure funcionam, a VM específica responsável por hospedar um compartilhamento UNC muda ao longo do tempo. As partilhas UNC são montadas por diferentes VMs à medida que são iniciadas e encerradas durante o curso normal das operações do Azure. Por esse motivo, os aplicativos nunca devem fazer suposições codificadas de que as informações da máquina em um caminho de arquivo UNC permanecem estáveis ao longo do tempo. Em vez disso, eles devem usar o conveniente caminho faux absoluto %HOME%\site que o App Service fornece.

O caminho absoluto simulado é um método portátil para se referir à sua própria aplicação. Não é específico de nenhum aplicativo ou usuário. %HOME%\siteUsando o , você pode transferir arquivos compartilhados de aplicativo para aplicativo sem ter que configurar um novo caminho absoluto para cada transferência.

Tipos de acesso a arquivos concedidos a um aplicativo

O %HOME% diretório num aplicativo corresponde a uma partilha de conteúdo no Armazenamento do Azure dedicada a essa aplicação. Seu nível de preço define seu tamanho. Ele pode incluir diretórios como aqueles para conteúdo, logs de erro e diagnóstico e versões anteriores do aplicativo que o controle do código-fonte criou. Esses diretórios estão disponíveis para o código do aplicativo em tempo de execução para acesso de leitura e gravação. Como os arquivos não são armazenados localmente, eles são persistentes nas reinicializações do aplicativo.

Na unidade do sistema, o Serviço de Aplicativo reserva %SystemDrive%\local para armazenamento local temporário específico do aplicativo. As alterações nos arquivos neste diretório não são persistentes nas reinicializações do aplicativo. Embora um aplicativo tenha acesso total de leitura e gravação ao seu próprio armazenamento local temporário, esse armazenamento não se destina ao uso direto pelo código do aplicativo. Em vez disso, a intenção é fornecer armazenamento temporário de arquivos para estruturas do IIS e de aplicativos Web.

O App Service limita a quantidade de armazenamento em %SystemDrive%\local para cada aplicação, para evitar que aplicações individuais consumam quantidades excessivas de armazenamento de ficheiros local. Para as camadas Livre, Compartilhada e de Consumo (Azure Functions), o limite é de 500 MB. A tabela a seguir lista outras camadas:

Escalão de serviço	Limite de armazenamento local
B1/S1/P1	11 GB
B2/S2/P2	15 GB
B3/S3/P3	58 GB
P0v3/P0v4	11 GB
P1v2/P1v3/P1mv3/P1mv4/Isolado1/Isolado1v2	21 GB
P2v2/P2v3/P2mv3/P2mv4/Isolado2/Isolado2v2	61 GB
P3v2/P3v3/P3mv3/P3mv4/Isolado3/Isolado3v2	140 GB
Isolado4v2	276 GB
P4mv3/P4mv4	280 GB
Isolado5v2	552 GB
P5mv3/P5mv4	560 GB
Isolado6v2	1.104 GB

O diretório para arquivos ASP.NET temporários e o diretório para arquivos compactados do IIS são dois exemplos de como o Serviço de Aplicativo usa o armazenamento local temporário. O sistema de compilação ASP.NET usa o %SystemDrive%\local\Temporary ASP.NET Files diretório como um local de cache de compilação temporário. O IIS usa o diretório %SystemDrive%\local\IIS Temporary Compressed Files para armazenar a saída da resposta compactada. Ambos os tipos de uso de ficheiros (juntamente com outros) são remapeados no App Service para armazenamento local temporário por aplicativo. Este remapeamento ajuda a garantir que a funcionalidade continue como esperado.

Cada aplicação no App Service é executada como uma identidade de processo de trabalho aleatória, exclusiva e com baixos privilégios chamada identidade do pool de aplicativos. O código da aplicação usa esta identidade para acesso básico de apenas leitura à unidade do sistema operativo. Esse acesso significa que o código do aplicativo pode listar estruturas de diretório comuns e ler arquivos comuns na unidade do sistema operacional. Embora esse nível de acesso possa parecer amplo, os mesmos diretórios e arquivos são acessíveis quando você provisiona uma função de trabalho em um serviço hospedado no Azure e lê o conteúdo da unidade.

Acesso a arquivos em várias instâncias

O diretório de compartilhamento de conteúdo (%HOME%) contém o conteúdo de um aplicativo e o código do aplicativo pode ser gravado nele. Se um aplicativo for executado em várias instâncias, o %HOME% diretório será compartilhado entre todas as instâncias para que todas as instâncias vejam o mesmo diretório. Por exemplo, se um aplicativo salvar arquivos carregados no %HOME% diretório, esses arquivos estarão imediatamente disponíveis para todas as instâncias.

O diretório de armazenamento local temporário (%SystemDrive%\local) não é compartilhado entre instâncias. Também não é partilhado entre a aplicação e a sua aplicação Kudu.

Acesso à rede

O código da aplicação pode usar protocolos baseados em TCP/IP e UDP para estabelecer ligações de rede de saída para pontos de extremidade acessíveis pela Internet que disponibilizam serviços externos. Os aplicativos podem usar esses mesmos protocolos para se conectar a serviços no Azure, por exemplo, estabelecendo conexões HTTPS com o Banco de Dados SQL do Azure.

Há também uma capacidade limitada para que os aplicativos estabeleçam uma conexão de loopback local e façam com que um aplicativo ouça nesse soquete de loopback local. Esse recurso permite que aplicativos escutem em soquetes de loopback local como parte de sua funcionalidade. Cada aplicação tem uma conexão de loopback privada. Um aplicativo não pode escutar um soquete de loopback local que outro aplicativo estabeleceu.

Os pipes nomeados também são suportados como um mecanismo de comunicação entre processos que executam coletivamente um aplicativo. Por exemplo, o módulo FastCGI do IIS depende de pipes nomeados para coordenar os processos individuais que executam páginas PHP.

Execução de código, processos e memória

Como observado anteriormente, os aplicativos são executados dentro de processos de trabalho com privilégios baixos usando uma identidade aleatória do pool de aplicativos. O código do aplicativo tem acesso ao espaço de memória associado ao processo de trabalho, juntamente com quaisquer processos filho que processos CGI ou outros aplicativos possam gerar. No entanto, um aplicativo não pode acessar a memória ou os dados de outro aplicativo, mesmo que esteja na mesma VM.

Os aplicativos podem executar scripts ou páginas escritas com estruturas de desenvolvimento da Web suportadas. O Serviço de Aplicativo não define nenhuma configuração de estrutura da Web para modos mais restritos. Por exemplo, aplicações ASP.NET em execução no Serviço de Aplicações operam com confiança plena, em oposição a um modo de confiança mais restrito. Estruturas da Web, incluindo ASP clássico e ASP.NET, podem chamar componentes COM em processo (como ActiveX Data Objects) que são registrados por padrão no sistema operacional Windows. As frameworks Web não conseguem chamar componentes COM fora de processo.

Um aplicativo pode gerar e executar código arbitrário, abrir um shell de comando ou executar um script do PowerShell. No entanto, programas executáveis e scripts ainda estão restritos aos privilégios concedidos ao pool de aplicativos pai. Por exemplo, um aplicativo pode gerar um programa executável que faz uma chamada HTTP de saída, mas esse programa executável não pode tentar desvincular o endereço IP de uma VM de seu adaptador de rede. Fazer uma chamada de rede de saída é permitido para código de baixo privilégio, mas tentar reconfigurar as configurações de rede em uma VM requer privilégios administrativos.

Logs e eventos de diagnóstico

As informações de log são outro conjunto de dados que alguns aplicativos tentam acessar. Os tipos de informações de log disponíveis para o código em execução no Serviço de Aplicativo incluem informações de diagnóstico e log que um aplicativo gera e pode acessar facilmente.

Por exemplo, os logs HTTP do W3C gerados por aplicativos estão disponíveis:

• Em um diretório de log no local de compartilhamento de rede que você criou para o aplicativo.
• No armazenamento de blob se você configurar o log do W3C no armazenamento.

A última opção permite que os aplicativos reúnam grandes quantidades de logs sem exceder os limites de armazenamento de arquivos associados a um compartilhamento de rede.

Da mesma forma, as informações de diagnóstico em tempo real de aplicativos .NET podem ser registradas por meio da infraestrutura de rastreamento e diagnóstico do .NET. Em seguida, pode-se guardar as informações de rastreamento no compartilhamento de rede da aplicação ou num local de armazenamento de blob.

As áreas de log e rastreamento de diagnóstico que não estão disponíveis para aplicações são os eventos do Rastreamento de Eventos para o Windows (ETW) e os logs comuns de eventos do Windows (por exemplo, logs de eventos de sistema, aplicação e segurança). Como as informações de rastreamento do ETW podem ser potencialmente visíveis em uma máquina usando as listas de controle de acesso corretas, o acesso de leitura e o acesso de gravação aos eventos do ETW são bloqueados. Chamadas de API para ler e gravar eventos ETW e logs de eventos comuns do Windows podem parecer funcionar, mas, na realidade, o código do aplicativo não tem acesso a esses dados de eventos.

Acesso ao registo

Os aplicativos têm acesso somente leitura a muito, embora não a todos, do registro da VM em que estão sendo executados. Esse acesso significa que os aplicativos podem acessar chaves do Registro que permitem acesso somente leitura ao grupo Usuários Locais. Uma área do Registro que atualmente não é suportada para acesso de leitura ou gravação é a HKEY_CURRENT_USER colmeia.

O acesso de gravação ao registo é bloqueado, incluindo o acesso a quaisquer chaves de registo para cada utilizador. Do ponto de vista da aplicação, ela não pode depender do acesso de gravação ao Registro no ambiente do Azure porque as aplicações podem ser migradas entre máquinas virtuais. O único armazenamento gravável persistente do qual um aplicativo pode depender é a estrutura de diretório de conteúdo por aplicativo armazenada nos compartilhamentos UNC do Serviço de Aplicativo.

Acesso remoto à área de trabalho

O Serviço de Aplicativo não fornece acesso à área de trabalho remota às instâncias da VM.

Conteúdo relacionado

Para obter as informações mais up-tosobre o ambiente de execução do Serviço de Aplicativo, consulte a área restrita do Serviço de Aplicativo do Azure. A equipe de desenvolvimento do Serviço de Aplicativo mantém esta página.