Funcionalidade do sistema operativo em Serviço de Aplicações do Azure

Este artigo descreve a funcionalidade comum do sistema operativo de base que está disponível para todas as aplicações Windows em execução no Serviço de Aplicações do Azure. Esta funcionalidade inclui acesso a ficheiros, redes e registos e registos e registos e eventos de diagnóstico.

Nota

As aplicações Linux em Serviço de Aplicações funcionam nos seus próprios contentores. Tem acesso à raiz do recipiente, mas não é permitido acesso ao sistema operativo hospedeiro. Da mesma forma, para aplicações que funcionam em contentores Windows, tem acesso administrativo ao contentor, mas sem acesso ao sistema operativo anfitrião.

Serviço de Aplicações níveis de plano

Serviço de Aplicações executa aplicativos de clientes em um ambiente de hospedagem multi-inquilino. As aplicações implementadas nos níveis Gratuito e Compartilhado funcionam em processos de trabalhadores em máquinas virtuais partilhadas, enquanto as aplicações implementadas nos níveis Standard e Premium funcionam em máquinas virtuais dedicadas especificamente às aplicações associadas a um único cliente.

Nota

Serviço de Aplicações planos de serviço gratuitos e partilhados (pré-visualização) são níveis base que funcionam nas mesmas máquinas virtuais Azure que outras aplicações Serviço de Aplicações. Algumas aplicações podem pertencer a outros clientes. Estas camadas destinam-se a ser utilizadas apenas para efeitos de desenvolvimento e teste.

Como Serviço de Aplicações suporta uma experiência de escala perfeita entre diferentes níveis, a configuração de segurança aplicada para Serviço de Aplicações aplicações permanece a mesma. Isto garante que as aplicações não se comportam de forma diferente, falhando de formas inesperadas, quando um plano Serviço de Aplicações muda de um nível para outro.

Quadros de desenvolvimento

Serviço de Aplicações os níveis de preços controlam a quantidade de recursos computacional (CPU, armazenamento de discos, memória e saída de rede) disponíveis para aplicações. No entanto, a amplitude da funcionalidade-quadro disponível para apps permanece a mesma, independentemente dos escalões de escala.

Serviço de Aplicações suporta uma variedade de quadros de desenvolvimento, incluindo ASP.NET, ASP clássico, Node.js, PHP e Python. De forma a simplificar e normalizar a configuração de segurança, Serviço de Aplicações aplicações normalmente executam os vários quadros de desenvolvimento com as suas definições padrão. Os quadros e componentes de tempo de execução fornecidos pela plataforma são atualizados regularmente para satisfazer os requisitos de segurança e conformidade, por isso não garantimos versões específicas de menores/patch e recomendamos que os clientes direcionem a versão principal conforme necessário.

As secções seguintes resumem os tipos gerais de funcionalidade do sistema operativo disponíveis para Serviço de Aplicações aplicações.

Acesso a ficheiros

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

Unidades locais

No seu cerne, Serviço de Aplicações é um serviço que funciona em cima da infraestrutura Azure PaaS (plataforma como serviço). Como resultado, as unidades locais que estão "ligadas" a uma máquina virtual são os mesmos tipos de unidade disponíveis para qualquer papel de trabalhador em execução em Azure. O que está incluído:

• Uma unidade do sistema operativo (%SystemDrive%), cujo tamanho varia consoante o tamanho do VM.
• Uma unidade de recursos (%ResourceDrive%) utilizada por Serviço de Aplicações internamente.

É importante monitorizar a utilização do disco à medida que a sua aplicação cresce. Se a quota de disco for alcançada, pode ter efeitos adversos na sua aplicação. Por exemplo:

• A aplicação pode lançar um erro indicando que não há espaço suficiente no disco.
• Pode ver erros de disco ao navegar na consola Kudu.
• A implementação de Azure DevOps ou Visual Studio pode falhar com ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk).
• A sua aplicação pode sofrer um desempenho lento.

Unidades de rede (ações da UNC)

Um dos aspetos únicos da Serviço de Aplicações que torna a implementação e manutenção de aplicações simples é que todas as ações de conteúdo são armazenadas num conjunto de ações da UNC. Este modelo mapeia bem o padrão comum de armazenamento de conteúdo usado por ambientes de hospedagem web no local que têm vários servidores equilibrados em carga.

Dentro de Serviço de Aplicações, há uma série de ações da UNC criadas em cada centro de dados. Uma percentagem do conteúdo do utilizador para todos os clientes em cada data center é atribuída a cada ação da UNC. A subscrição de cada cliente tem uma estrutura de diretório reservada numa parte específica da UNC dentro de um centro de dados. Um cliente pode ter várias aplicações criadas dentro de um centro de dados específico, pelo que todos os diretórios pertencentes a uma única subscrição de clientes são criados na mesma parte do UNC.

Devido ao funcionamento dos serviços Azure, a máquina virtual específica responsável por hospedar uma parte da UNC mudará ao longo do tempo. É garantido que as ações da UNC serão montadas por diferentes máquinas virtuais, uma vez que são criadas para cima e para baixo durante o curso normal das operações do Azure. Por esta razão, as aplicações nunca devem fazer pressupostos codificados de que as informações da máquina num caminho de ficheiros da UNC permanecerão estáveis ao longo do tempo. Em vez disso, devem usar o conveniente caminho%HOME%\site absoluto falso que Serviço de Aplicações proporciona. Este caminho falso absoluto fornece um método portátil, app-e-utilizador-agnóstico para se referir à própria app. Ao utilizar %HOME%\site, é possível transferir ficheiros partilhados de app para app sem ter de configurar um novo caminho absoluto para cada transferência.

Tipos de acesso a ficheiros concedidos a uma aplicação

O %HOME% diretório de uma aplicação mapeia para uma partilha de conteúdo no Azure Armazenamento dedicado a essa aplicação, e o seu tamanho é definido pelo seu nível de preços. Pode incluir diretórios como os de conteúdos, erros e registos de diagnóstico, e versões anteriores da app criadas por controlo de origem. Estes diretórios estão disponíveis para o código de aplicação da aplicação no tempo de execução para leitura e para o acesso. Como os ficheiros não são armazenados localmente, são persistentes através do reinício da aplicação.

Na unidade do sistema, Serviço de Aplicações reservas %SystemDrive%\local para armazenamento local temporário específico de aplicações. As alterações nos ficheiros deste diretório não são persistentes em todos os recomeçamentos da aplicação. Apesar de uma aplicação ter acesso total de leitura/escrita ao seu próprio armazenamento local temporário, esse armazenamento realmente não se destina a ser usado diretamente pelo código da aplicação. Em vez disso, a intenção é fornecer armazenamento temporário de ficheiros para iis e quadros de aplicações web. Serviço de Aplicações também limita a quantidade de armazenamento em %SystemDrive%\local cada app para evitar que aplicações individuais consumam quantidades excessivas de armazenamento de ficheiros locais. Para os níveis de Consumo Gratuito, Partilhado e Consumo (Funções do Azure), o limite é de 500 MB. Consulte a tabela seguinte para outros níveis:

Família de SKU	B1/S1/etc.	B2/S2/etc.	B3/S3/etc.
Básico, Standard, Premium	11 GB	15 GB	58 GB
PremiumV2, PremiumV3, Isolado	21 GB	61 GB	140 GB

Dois exemplos de como Serviço de Aplicações utiliza armazenamento local temporário são o diretório para ficheiros de ASP.NET temporárias e o diretório para ficheiros comprimidos IIS. O sistema de compilação ASP.NET utiliza o %SystemDrive%\local\Temporary ASP.NET Files diretório como um local de cache de compilação temporária. O IIS utiliza o %SystemDrive%\local\IIS Temporary Compressed Files diretório para armazenar a saída de resposta comprimido. Ambos os tipos de utilização de ficheiros (assim como outros) são rempepeitados em Serviço de Aplicações para o armazenamento local temporário por aplicação. Este remapping garante que a funcionalidade continua como esperado.

Cada aplicação em Serviço de Aplicações funciona como uma identidade de processo de trabalhadoridade única e privilegiada aleatória chamada "identidade do conjunto de aplicações", descrita mais na documentação do IIS Application Pool Identities. O código de aplicação utiliza esta identidade para o acesso básico apenas à unidade do sistema operativo. Isto significa que o código de aplicação pode listar estruturas comuns de diretório e ler ficheiros comuns sobre a unidade do sistema operativo. Embora este possa parecer um nível de acesso um pouco amplo, os mesmos diretórios e ficheiros são acessíveis quando fornece um papel de trabalhador num serviço hospedado no Azure e lê o conteúdo da unidade.

Acesso a ficheiros em várias instâncias

O diretório de partilha de conteúdos (%HOME%) contém conteúdo de uma aplicação, e o código de aplicação pode escrever-lhe. Se uma aplicação for executado em várias instâncias, o %HOME% diretório é partilhado entre todas as instâncias para que todas as instâncias vejam o mesmo diretório. Assim, por exemplo, se uma aplicação guardar ficheiros enviados para o %HOME% diretório, esses ficheiros estão imediatamente disponíveis para todas as instâncias.

O diretório de armazenamento local temporário (%SystemDrive%\local) não é partilhado entre instâncias, nem é partilhado entre a app e a sua app Kudu.

Acesso à rede

O código de aplicação pode utilizar protocolos baseados em TCP/IP e UDP para fazer ligações de rede de saída a pontos finais acessíveis à Internet que expõem serviços externos. As aplicações podem utilizar estes mesmos protocolos para se conectarem a serviços dentro do Azure, por exemplo, estabelecendo ligações HTTPS a Base de Dados SQL.

Existe também uma capacidade limitada para as aplicações estabelecerem uma ligação loopback local, e ter uma aplicação a ouvir sobre a tomada de backback local. Esta funcionalidade existe principalmente para permitir que as aplicações que ouçam as tomadas de backback locais como parte da sua funcionalidade. Cada aplicação vê uma ligação loopback "privada". A aplicação "A" não pode ouvir uma tomada de retorno local estabelecida pela aplicação "B".

Os tubos nomeados também são suportados como um mecanismo de comunicação inter-processo (IPC) entre diferentes processos que executam coletivamente uma aplicação. Por exemplo, o módulo IIS FastCGI baseia-se em tubos nomeados para coordenar os processos individuais que executam páginas PHP.

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

Como já foi notado, as aplicações são executadas dentro de processos de trabalhadores pouco privilegiados usando uma identidade de conjunto de aplicações aleatória. O código de aplicação tem acesso ao espaço de memória associado ao processo do trabalhador, bem como a quaisquer processos infantis que possam ser gerados por processos CGI ou outras aplicações. No entanto, uma aplicação não consegue aceder à memória ou dados de outra app, mesmo que se desempenhe na mesma máquina virtual.

As aplicações podem executar scripts ou páginas escritas com quadros de desenvolvimento web suportados. Serviço de Aplicações não configura nenhuma configuração de estrutura web para modos mais restritos. Por exemplo, ASP.NET aplicações em execução em Serviço de Aplicações funcionam em confiança "completa", em oposição a um modo de confiança mais restrito. As estruturas web, incluindo as asp clássicas e ASP.NET, podem chamar componentes COM in-process (mas não fora dos componentes DE processo) como ADO (ActiveX Data Objects) que são registados por padrão no sistema operativo Windows.

As aplicações podem desovar e executar código arbitrário. É permitido para uma aplicação fazer coisas como desovar uma concha de comando ou executar um script PowerShell. No entanto, apesar de códigos e processos arbitrários poderem ser gerados a partir de uma aplicação, os programas e scripts executáveis ainda estão restritos aos privilégios concedidos ao conjunto de aplicações dos pais. Por exemplo, uma aplicação pode gerar uma chamada executável que faz uma chamada HTTP de saída, mas essa mesma executável não pode tentar desvincular o endereço IP de uma máquina virtual a partir do seu NIC. Fazer uma chamada de rede de saída é permitido a um código de baixa privilégio, mas tentar reconfigurar as definições de rede numa máquina virtual requer privilégios administrativos.

Registos e eventos de diagnóstico

A informação de registo é outro conjunto de dados que algumas apps tentam aceder. Os tipos de informação de registo disponível para código em execução em Serviço de Aplicações inclui informações de diagnóstico e registo geradas por uma aplicação que também é facilmente acessível à aplicação.

Por exemplo, os registos W3C HTTP gerados por uma aplicação ativa estão disponíveis quer num diretório de registos na localização da partilha de rede criada para a aplicação, quer disponível no armazenamento de blob se um cliente tiver configurado o registo W3C para armazenamento. Esta última opção permite recolher grandes quantidades de registos sem o risco de exceder os limites de armazenamento de ficheiros associados a uma partilha de rede.

Numa veia semelhante, as informações de diagnóstico em tempo real de aplicações .NET também podem ser registadas utilizando a infraestrutura de rastreio e diagnóstico .NET, com opções para escrever a informação de rastreio para a partilha de rede da app, ou alternativamente para um local de armazenamento de bolhas.

Áreas de registo e rastreio de diagnósticos que não estão disponíveis para aplicações estão Windows eventos DAEW e registos de eventos comuns Windows (por exemplo, registos de eventos de sistema, aplicação e segurança). Uma vez que as informações sobre vestígios da ETW podem potencialmente ser visualizadas em toda a máquina (com os ACLs certos), ler e escrever o acesso a eventos ETW são bloqueados. Os desenvolvedores podem notar que a API chama para ler e escrever eventos ETW e registos de eventos comuns Windows parecem funcionar, mas isso é porque Serviço de Aplicações está a "fingir" as chamadas para que pareçam ter sucesso. Na realidade, o código da aplicação não tem acesso a estes dados do evento.

Acesso ao registo

As aplicações têm acesso apenas a muito (embora nem todos) do registo da máquina virtual em que estão a funcionar. Na prática, isto significa que as chaves de registo que permitem o acesso apenas à leitura do grupo de Utilizadores locais são acessíveis por apps. Uma área do registo que não é suportada atualmente para o acesso lido ou escrito é a HKEY_CURRENT_USER colmeia.

O acesso por escrito ao registo está bloqueado, incluindo o acesso a quaisquer chaves de registo por utilizador. Do ponto de vista da aplicação, escrever o acesso ao registo nunca deve ser confiado no ambiente Azure, uma vez que as aplicações podem (e fazem) ser migradas através de diferentes máquinas virtuais. O único armazenamento escrito persistente que pode ser dependente de uma aplicação é a estrutura de diretório de conteúdos por aplicação armazenada nas ações Serviço de Aplicações UNC.

Acesso remoto ao ambiente de trabalho

Serviço de Aplicações não fornece acesso remoto ao ambiente de trabalho às instâncias VM.

Mais informações

Serviço de Aplicações do Azure caixa de areia - A informação mais atualizada sobre o ambiente de execução de Serviço de Aplicações. Esta página é mantida diretamente pela equipa de desenvolvimento Serviço de Aplicações.