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.

Nota

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 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.

Nota

Os planos de serviço Gratuito e Compartilhado (visualização) do Serviço de Aplicativo são camadas base que são executadas nas mesmas máquinas virtuais do Azure que outros aplicativos do Serviço de Aplicativo. 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/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 ficheiros

Existem várias unidades no 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. Estas 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 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, aplicativos mais antigos codificados com referências de caminho de arquivo continuarão a funcionar porque o d:\ Serviço de Aplicativo remapeia d:\ automaticamente para apontar c:\para . 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 navegar para o console 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 um desempenho lento.

Unidades de rede (partilhas UNC)

Um dos aspetos exclusivos do Serviço de Aplicativo que facilitam a implantação e a manutenção de aplicativos é que todos os compartilhamentos de conteúdo são armazenados em um conjunto de compartilhamentos UNC. 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 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 máquinas virtuais diferentes à 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 suposições codificadas de que as informações da máquina em um caminho de arquivo UNC permanecerão estáveis ao longo do tempo. Em vez disso, eles devem usar o caminho %HOME%\site falso e absoluto conveniente que o Serviço de Aplicativo fornece.

O caminho absoluto falso é um método portátil para se referir ao seu próprio aplicativo. 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 em um aplicativo mapeia para um compartilhamento de conteúdo no Armazenamento do Azure dedicado para esse aplicativo. 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 Serviço de Aplicativo limita a quantidade de armazenamento de cada aplicativo para evitar que aplicativos individuais consumam quantidades excessivas de armazenamento de %SystemDrive%\local arquivos 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	Armazenamento local de arquivos
B1/S1/P1	11 GB
B2/S2/P2	15 GB
B3/S3/P3	58 GB
P0v3	11 GB
P1v2/P1v3/P1mv3/Isolado1/Isolado1v2	21 GB
P2v2/P2V3/P2MV3/Isolado2/Isolado2v2	61 GB
P3v2/P3V3/P3mv3/Isolado3/Isolado3v2	140 GB
Isolado4v2	276 GB
P4mv3	280 GB
Isolado5v2	552 GB
P5mv3	560 GB
Isolado6v2	1.104 GB

Dois exemplos de como o Serviço de Aplicativo usa o armazenamento local temporário são o diretório para arquivos ASP.NET temporários e o diretório para arquivos compactados do IIS. 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 para armazenar a %SystemDrive%\local\IIS Temporary Compressed Files saída de resposta compactada. Ambos os tipos de uso de arquivos (juntamente 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 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 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 diretório será compartilhado entre todas as instâncias para que todas as instâncias vejam o %HOME% 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 à 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 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 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 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 máquina virtual.

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, 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. 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 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, 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 máquina virtual 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 máquina virtual 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 registro em 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, 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 registo e rastreio de diagnósticos que não estão disponíveis para aplicações são eventos do Rastreio de Eventos do Windows para Windows (ETW) e registos de eventos comuns do Windows (por exemplo, registos de eventos de sistema, aplicações e segurança). Como as informações de rastreamento do ETW podem ser potencialmente visíveis 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 eventos.

Acesso ao registo

Os aplicativos têm acesso somente leitura a grande parte (embora não 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 é suportada 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 perspetiva 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 esta página.