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

Este artigo descreve a funcionalidade do sistema operacional de linha de base 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.

Níveis do Plano do Serviço de Aplicativo

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

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

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

Estruturas de desenvolvimento

Os tipos de preço 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 aplicativos. No entanto, a amplitude da funcionalidade de estrutura disponível para aplicativos permanece a mesma, independentemente das camadas de dimensionamento.

O Serviço de Aplicativo dá suporte a 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 os componentes de runtime que a plataforma fornece são atualizados regularmente para atender aos requisitos de segurança e conformidade. Por esse motivo, não garantimos versões secundárias ou de patch específicas. Recomendamos que os clientes tenham como alvo 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 arquivos

Existem várias unidades no Serviço de Aplicativo do Azure, incluindo unidades locais e unidades de rede.

Unidades locais

Em sua essência, o Serviço de Aplicativo é um serviço executado na parte superior da 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. Elas incluem:

• Uma unidade do sistema operacional (%SystemDrive%) cujo tamanho depende do tamanho da VM.
• Uma unidade de recurso (%ResourceDrive%) que o Serviço de Aplicativo do Azure usa internamente.

Uma prática recomendada é sempre usar as variáveis %SystemDrive% de ambiente e %ResourceDrive% , em vez de caminhos de arquivo embutidos em código. O caminho raiz retornado dessas duas variáveis de ambiente mudou ao longo do tempo de d:\ para c:\. No entanto, os aplicativos mais antigos codificados com referências de caminho de arquivo para d:\ continuam a funcionar porque o Serviço de Aplicativo do Azure 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 evitar confusão sobre as alterações de plataforma no caminho do 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 navegar até o console do Kudu.
• A implantação 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 (compartilhamentos UNC)

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

No Serviço de Aplicações, 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 em um compartilhamento UNC específico em um 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. Os compartilhamentos UNC são montados por diferentes VMs à medida que são ativados e desativados 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 do computador em um caminho de arquivo UNC permanecem estáveis ao longo do tempo. Em vez disso, eles devem usar o conveniente falso caminho absoluto %HOME%\site fornecido pelo Serviço de Aplicativo do Azure.

O caminho absoluto falso é um método portátil para se referir ao seu próprio aplicativo. Não é específico para nenhum aplicativo ou usuário. Ao usar %HOME%\site, você pode transferir arquivos compartilhados de aplicativo para aplicativo sem precisar configurar um novo caminho absoluto para cada transferência.

Tipos de acesso a arquivos concedidos a um aplicativo

O diretório %HOME% em um aplicativo é mapeado para um compartilhamento de conteúdo no Azure Storage dedicado a esse aplicativo. Seu tipo de preço define seu tamanho. Ele pode incluir diretórios como os de 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 durante o tempo de execução, oferecendo acesso de leitura e gravação. Como os arquivos não são armazenados localmente, eles são persistentes entre as reinicializações do aplicativo.

Na unidade do sistema, o Serviço de Aplicativo do Azure 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 completo 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 de aplicativo Web e IIS.

O Serviço de Aplicativo limita a quantidade de armazenamento em %SystemDrive%\local cada aplicativo para impedir que aplicativos individuais consumam quantidades excessivas de armazenamento de arquivos local. Para camadas gratuitas, compartilhadas e de consumo (Azure Functions), o limite é de 500 MB. A tabela a seguir lista outras camadas:

O diretório para arquivos de 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ária. O IIS usa o %SystemDrive%\local\IIS Temporary Compressed Files diretório para armazenar a saída de resposta compactada. Ambos os tipos de uso de arquivo (junto com outros) são remapeados no Serviço de Aplicativo do Azure para armazenamento local temporário por aplicativo. Esse remapeamento ajuda a garantir que as funcionalidades continuem funcionando conforme o esperado.

Cada aplicativo no App Service é executado como uma identidade de processo de trabalho aleatória, exclusiva e com poucos privilégios, chamada identidade do pool de aplicativos. O código do aplicativo usa essa identidade para acesso básico somente leitura à unidade do sistema operacional. 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 pareça ser 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 compartilhamento de conteúdo (%HOME%) contém o conteúdo de um aplicativo, e o código do aplicativo pode gravar 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 é compartilhado entre o aplicativo e seu aplicativo Kudu.

Acesso de rede

O código do aplicativo pode utilizar protocolos baseados em TCP/IP e UDP para estabelecer conexões de rede de saída com endpoints acessíveis na 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.

Também há uma capacidade limitada para que os aplicativos estabeleçam uma conexão de loopback local e tenham um aplicativo escutando nesse soquete de loopback local. Esse recurso habilita aplicativos que escutam em soquetes de loopback locais como parte de sua funcionalidade. Cada aplicativo tem uma conexão de retorno privada. Um aplicativo não pode escutar um soquete de loopback local que outro aplicativo estabeleceu.

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

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

Conforme observado anteriormente, os aplicativos são executados dentro de processos de trabalho de baixo privilégio 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, assim como a qualquer processo filho que os 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 com suporte. O App Service não configura nenhuma configuração de framework web para modos mais restritos. Por exemplo, aplicativos ASP.NET em execução no serviço de aplicativo executam com total confiança, ao invés de um modo de confiança mais restrita. Estruturas da Web, incluindo ASP clássico e ASP.NET, podem chamar componentes COM em processo (como Objetos de Dados ActiveX) que são registrados por padrão no sistema operacional Windows. Estruturas da Web não podem chamar componentes COM fora do processo.

Um aplicativo pode gerar e executar código arbitrário, abrir um shell de comando ou executar um script do PowerShell. No entanto, os programas e scripts executáveis ainda sã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.

Registros 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 pelo aplicativo 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 blobs, se você configurar o registro W3C no armazenamento.

A última opção permite que os aplicativos coletem 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, você pode gravar as informações de rastreamento no compartilhamento de rede do aplicativo ou em um local de armazenamento de blobs.

Áreas de registro e rastreamento de diagnóstico que não estão disponíveis para aplicativos são eventos do Rastreamento de Eventos do Windows (ETW) e logs de eventos comuns do Windows (por exemplo, logs de eventos do sistema, de aplicativo e de segurança). Como as informações de rastreamento do ETW podem, potencialmente, ser visualizadas em um computador, usando as listas de controle de acesso corretas, o acesso de leitura e de escrita aos eventos ETW é bloqueado. Chamadas à 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 evento.

Acesso ao Registro

Os aplicativos têm acesso somente leitura a grande parte, mas não a todo, o registro da VM na qual 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 tem suporte para acesso de leitura ou gravação é o HKEY_CURRENT_USER hive.

O acesso de gravação ao registro é bloqueado, incluindo o acesso a quaisquer chaves de registro por usuário. Da perspectiva do aplicativo, ele não pode depender do acesso de gravação ao registro no ambiente do Azure porque os aplicativos podem ser migrados entre VMs. 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 à área de trabalho remota

O App Service não fornece acesso de área de trabalho remota às instâncias de máquina virtual (VM).

Conteúdo relacionado

Para obter as informações mais atualizadas sobre o ambiente de execução do App Service, veja o sandbox do Serviço de Aplicativo do Azure. A equipe de desenvolvimento do Serviço de Aplicativo mantém esta página.