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.

Camadas de plano do Serviço de Aplicativo

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.

Como o Serviço de Aplicativo oferece suporte a uma experiência de dimensionamento perfeita 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 repentina de maneira diferente e falhem de maneiras inesperadas quando um plano do Serviço de Aplicativo alterna 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 egresso de rede) disponíveis para aplicativos. No entanto, a amplitude da funcionalidade da estrutura disponível para aplicativos permanece a mesma, independentemente das camadas de dimensionamento.

O Serviço de Aplicativo oferece 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 tempo de execução 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/de patch específicas. Recomendamos que os clientes direcionem 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 diversas unidades dentro do Serviço de Aplicativo, 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 máquina virtual 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 usa internamente.

Uma boa prática é sempre usar as variáveis de ambiente %SystemDrive% 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, aplicativos mais antigos codificados com referências de caminho de arquivo continuam a funcionar porque o Serviço de d:\ Aplicativo remapeia d:\ automaticamente 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 as alterações de plataforma no caminho de arquivo raiz padrão.

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

• O aplicativo pode lançar um erro que indica que não há espaço suficiente no disco.
• Você pode ver erros de disco ao navegar para 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)o .
• Seu aplicativo pode ter desempenho lento.

Unidades de rede (compartilhamentos UNC)

Um dos aspectos 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. Esse modelo mapeia bem para o padrão comum de armazenamento de conteúdo usado por ambientes de hospedagem na Web local com 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 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 máquina virtual específica responsável por hospedar um compartilhamento UNC muda ao longo do tempo. Os compartilhamentos UNC são montados por diferentes máquinas virtuais à medida que são trazidos para cima e para baixo durante o curso normal das operações do Azure. Por esse motivo, os aplicativos nunca devem fazer pressuposições codificadas de que as informações da máquina em um caminho de arquivo UNC permanecerão estáveis com o passar do tempo. Em vez disso, eles devem usar o caminho absoluto faux%HOME%\site fornecido pelo Serviço de Aplicativo.

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. %HOME%\siteUsando o , 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 %HOME% diretório em um aplicativo é mapeado para um compartilhamento de conteúdo no Armazenamento do Azure dedicado a esse aplicativo. Seu nível de preços 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 criado pelo controle do código-fonte. Esses diretórios estão disponíveis para o código do aplicativo em runtime para 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 reserva %SystemDrive%\local para o armazenamento local temporário específico do aplicativo. As alterações em arquivos nesse diretório não são persistentes entre as 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, o objetivo é fornecer um armazenamento de arquivo temporário para o IIS e para as estruturas do aplicativo Web.

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

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

Cada aplicativo no Serviço de Aplicativo é executado como uma identidade de processo de trabalho aleatória, exclusiva e com privilégios reduzidos chamada identidade do pool de aplicativos. O código do aplicativo usa essa identidade no acesso somente leitura básico à 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 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%) apresenta 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 diretório %HOME% 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. Ele também não é compartilhado entre o aplicativo e seu aplicativo Kudu.

Acesso de rede

O código do aplicativo pode usar protocolos baseados em TCP/IP e UDP para fazer conexões de rede de saída para pontos de extremidade acessíveis pela Internet que expõem 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 tenham um aplicativo escutando nesse soquete de loopback local. Esse recurso permite que aplicativos que escutam em soquetes de loopback local como parte de sua funcionalidade. Cada aplicativo tem uma conexão de loopback privada. Um aplicativo não pode ouvir 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 de pool de aplicativos aleatória. 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 máquina virtual.

Os aplicativos podem executar scripts ou páginas gravadas com estruturas de desenvolvimento na Web com suporte. O Serviço de Aplicativo não define configurações de estrutura na Web como modos mais restritos. Por exemplo, ASP.NET aplicativos executados no Serviço de Aplicativo são executados em confiança total, em oposição a um modo de confiança mais restrito. As estruturas da Web, incluindo ASP e ASP.NET clássicos, podem chamar componentes COM em processo (como ActiveX Data Objects) que são registrados por padrão no sistema operacional Windows. As 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 executáveis e scripts 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 máquina virtual de seu adaptador de rede. Fazer uma chamada de rede de saída é permitido para código com privilégios baixos, mas tentar redefinir as configurações de rede em uma máquina virtual requer privilégios administrativos.

Logs de diagnóstico e eventos

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 blob se você configurar o log W3C para 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, você pode gravar as informações de rastreamento no compartilhamento de rede do aplicativo ou em um local de armazenamento de blob.

As áreas de log e rastreamento de diagnóstico que não estão disponíveis para aplicativos são eventos ETW (Rastreamento de Eventos do Windows) e logs de eventos comuns do Windows (por exemplo, logs de eventos de sistema, aplicativo e segurança). Como as informações de rastreamento do ETW podem ser visualizadas em uma máquina (com 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 evento.

Acesso ao Registro

Os aplicativos têm acesso somente leitura a grande parte (embora não a todos) do registro da máquina virtual 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 tem suporte para acesso de leitura ou gravação é a HKEY\_CURRENT\_USER colmeia.

O acesso de gravação ao Registro é bloqueado, incluindo o acesso a quaisquer chaves do 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 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.

Mais informações

Para obter as informações mais atualizadas sobre 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 essa página.