Funzionalità del sistema operativo nel servizio app Azure

Questo articolo descrive la funzionalità del sistema operativo di base disponibile per tutte le app di Windows in esecuzione nel servizio app Azure. Questa funzionalità include l'accesso ai file, alla rete e al Registro di sistema, oltre ai log e agli eventi di diagnostica.

Nota

Le app Linux in Servizio app vengono eseguite in contenitori propri. Si dispone dell'accesso radice al contenitore, ma non è possibile accedere al sistema operativo host. Analogamente, per le app in esecuzione in contenitori Windows, è disponibile l'accesso amministrativo al contenitore ma non è consentito l'accesso al sistema operativo host.

Livelli del piano del servizio app di Azure

servizio app esegue le app dei clienti in un ambiente di hosting multi-tenant. Le app distribuite nei livelli Gratuito e Condiviso vengono eseguite nei processi di lavoro in macchine virtuali condivise. Le app distribuite nei livelli Standard e Premium vengono eseguite in macchine virtuali dedicate in modo specifico per le app associate a un singolo cliente.

Nota

servizio app piani di servizio gratuito e condiviso (anteprima) sono livelli di base eseguiti nelle stesse macchine virtuali di Azure di altre app servizio app. Alcune app potrebbero appartenere ad altri clienti. Questi livelli sono destinati solo a scopi di sviluppo e test.

Poiché servizio app supporta un'esperienza di scalabilità uniforme tra livelli, la configurazione di sicurezza applicata per le app servizio app rimane invariata. Questa configurazione garantisce che le app non si comportino improvvisamente in modo diverso e abbiano esito negativo in modi imprevisti quando un piano servizio app passa da un livello a un altro.

Framework di sviluppo

I piani tariffari del servizio app controllano la quantità di risorse di calcolo (CPU, archiviazione su disco, memoria e uscita di rete) disponibili per le app. Tuttavia, la gamma di funzionalità del framework disponibili per le app resta la stessa indipendentemente dai livelli di scalabilità.

servizio app supporta diversi framework di sviluppo, tra cui ASP.NET, ASP classico, Node.js, PHP e Python. Per semplificare e normalizzare la configurazione della sicurezza, servizio app le app in genere eseguono i framework di sviluppo con le impostazioni predefinite. I framework e i componenti di runtime forniti dalla piattaforma vengono aggiornati regolarmente per soddisfare i requisiti di sicurezza e conformità. Per questo motivo, non viene garantita alcuna versione secondaria/patch specifica. È consigliabile che i clienti siano destinati alle versioni principali in base alle esigenze.

Le sezioni seguenti riepilogano i tipi generali di funzionalità del sistema operativo disponibili per le app del servizio app.

Accesso a file

Nel servizio app sono presenti varie unità, tra cui unità locali e unità di rete.

Unità locali

Al suo interno, servizio app è un servizio in esecuzione sull'infrastruttura PaaS (Platform as a Service) di Azure. Di conseguenza, le unità locali associate a una macchina virtuale sono gli stessi tipi di unità disponibili per qualsiasi ruolo di lavoro in esecuzione in Azure. che includono:

• Unità del sistema operativo (%SystemDrive%) le cui dimensioni dipendono dalle dimensioni della macchina virtuale.
• Unità di risorse (%ResourceDrive%) che servizio app usa internamente.

Una procedura consigliata consiste nell'usare sempre le variabili %SystemDrive% di ambiente e %ResourceDrive% anziché i percorsi di file hardcoded. Il percorso radice restituito da queste due variabili di ambiente è stato spostato nel tempo da d:\ a c:\. Tuttavia, le applicazioni meno recenti hardcoded con riferimenti al percorso del file continuano a d:\ funzionare perché servizio app esegue automaticamente il mapping d:\ in modo che punti a c:\. Come indicato in precedenza, è consigliabile usare sempre le variabili di ambiente quando si creano percorsi di file ed evitare confusione sulle modifiche della piattaforma al percorso del file radice predefinito.

È importante monitorare l'utilizzo del disco man mano che l'applicazione cresce. Il raggiungimento della quota del disco può avere effetti negativi sull'applicazione. Ad esempio:

• L'app potrebbe generare un errore che indica che lo spazio sul disco non è sufficiente.
• È possibile che vengano visualizzati errori del disco durante l'esplorazione della console Kudu.
• La distribuzione da Azure DevOps o Visual Studio potrebbe non riuscire con ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk).
• L'app potrebbe avere prestazioni lente.

Unità di rete (condivisioni UNC)

Uno degli aspetti univoci di servizio app che rendono semplice la distribuzione e la manutenzione delle app è che tutte le condivisioni di contenuto vengono archiviate in un set di condivisioni UNC. Questo modello corrisponde perfettamente al modello comune di archiviazione di contenuto usato dagli ambienti host Web locali che dispongono di più server con carico bilanciato.

All'interno di servizio app, le condivisioni UNC vengono create in ogni data center. Una percentuale del contenuto utente per tutti i clienti in ogni data center viene allocata a ogni condivisione UNC. La sottoscrizione di ogni cliente ha una struttura di directory riservata in una condivisione UNC specifica in un data center. Un cliente potrebbe avere più app create in un data center specifico, quindi tutte le directory che appartengono a una singola sottoscrizione cliente vengono create nella stessa condivisione UNC.

A causa del funzionamento dei servizi di Azure, la macchina virtuale specifica responsabile dell'hosting di una condivisione UNC cambia nel tempo. Le condivisioni UNC vengono montate da macchine virtuali diverse man mano che vengono alzate e disattivate durante il normale corso delle operazioni di Azure. Per questo motivo le app non devono mai essere hardcoded in base al presupposto che le informazioni sul computer in un percorso file UNC rimarranno stabili nel corso del tempo. È invece consigliabile usare il comodo percorso %HOME%\site assoluto finto che servizio app fornisce.

Il percorso assoluto faux è un metodo portabile per fare riferimento alla tua app. Non è specifico di nessuna app o utente. Usando %HOME%\site, è possibile trasferire file condivisi dall'app all'app senza dover configurare un nuovo percorso assoluto per ogni trasferimento.

Tipi di accesso ai file concessi a un'app

La %HOME% directory in un'app è mappata a una condivisione di contenuto in Archiviazione di Azure dedicata per tale app. Il piano tariffario ne definisce le dimensioni. Può includere directory come quelle per il contenuto, i log di errore e di diagnostica e le versioni precedenti dell'app creata dal controllo del codice sorgente. Queste directory sono disponibili per il codice dell'applicazione dell'app in fase di esecuzione per l'accesso in lettura e scrittura. Poiché i file non vengono archiviati in locale, sono persistenti tra i riavvii dell'app.

Nell'unità di sistema servizio app riserva %SystemDrive%\local per l'archiviazione locale temporanea specifica dell'app. Le modifiche apportate ai file in questa directory non sono persistenti tra i riavvii dell'app. Anche se un'app ha accesso in lettura e scrittura completo alla propria risorsa di archiviazione locale temporanea, tale archiviazione non è destinata all'uso diretto dal codice dell'applicazione. L'obiettivo è invece quello di fornire una risorsa di archiviazione di file temporanea per IIS e per i framework applicazione Web.

servizio app limita la quantità di spazio di archiviazione in %SystemDrive%\local per ogni app per impedire alle singole app di consumare quantità eccessive di archiviazione file locale. Per i livelli Gratuito, Condiviso e Consumo (Funzioni di Azure), il limite è 500 MB. La tabella seguente elenca altri livelli:

Livello	Archiviazione file locale
B1/S1/P1	11 GB
B2/S2/P2	15 GB
B3/S3/P3	58 GB
P0v3	11 GB
P1v2/P1v3/P1mv3/Isolated1/Isolated1v2	21 GB
P2v2/P2v3/P2mv3/Isolated2/Isolated2v2	61 GB
P3v2/P3v3/P3mv3/Isolated3/Isolated3v2	140 GB
Isolated4v2	276 GB
P4mv3	280 GB
Isolated5v2	552 GB
P5mv3	560 GB
Isolated6v2	1.104 GB

Due esempi del modo in cui il servizio app usa le risorse di archiviazione locale temporanea sono costituiti dalla directory per i file ASP.NET temporanei e dalla directory per i file IIS compressi. Il sistema di compilazione ASP.NET usa la %SystemDrive%\local\Temporary ASP.NET Files directory come percorso temporaneo della cache di compilazione. IIS usa la directory per archiviare l'output %SystemDrive%\local\IIS Temporary Compressed Files della risposta compresso. Entrambi questi tipi di utilizzo dei file (insieme ad altri) vengono mappati in servizio app alla risorsa di archiviazione locale temporanea per app. Questo nuovo mapping consente di garantire che la funzionalità continui come previsto.

Ogni app in servizio app viene eseguita come identità casuale e univoca del processo di lavoro con privilegi limitati denominata identità del pool di applicazioni. Il codice dell'applicazione usa questa identità per l'accesso di sola lettura di base all'unità del sistema operativo. Questo accesso significa che il codice dell'applicazione può elencare le strutture di directory comuni e leggere i file comuni nell'unità del sistema operativo. Anche se questo livello di accesso potrebbe sembrare ampio, le stesse directory e i file sono accessibili quando si effettua il provisioning di un ruolo di lavoro in un servizio ospitato in Azure e si legge il contenuto dell'unità.

Accesso ai file tra più istanze

La directory condivisione contenuto (%HOME%) contiene il contenuto di un'app e il codice dell'applicazione può scrivervi. Se un'app viene eseguita su più istanze, la %HOME% directory viene condivisa tra tutte le istanze in modo che tutte le istanze visualizzino la stessa directory. Ad esempio, se un'app salva i file caricati nella %HOME% directory, tali file sono immediatamente disponibili per tutte le istanze.

La directory di archiviazione locale temporanea (%SystemDrive%\local) non è condivisa tra le istanze. Non viene inoltre condivisa tra l'app e l'app Kudu.

Accesso alla rete

Il codice dell'applicazione può usare protocolli basati su TCP/IP e UDP per stabilire connessioni di rete in uscita a endpoint accessibili da Internet che espongono servizi esterni. Le app possono usare questi stessi protocolli per connettersi ai servizi all'interno di Azure, ad esempio stabilendo connessioni HTTPS a database SQL di Azure.

È disponibile anche una funzionalità limitata per le app per stabilire una connessione loopback locale e avere un'app in ascolto su tale socket di loopback locale. Questa funzionalità abilita le app in ascolto sui socket di loopback locali come parte della relativa funzionalità. Ogni app ha una connessione loopback privata. Un'app non può ascoltare un socket di loopback locale stabilito da un'altra app.

Le named pipe sono supportate anche come meccanismo per la comunicazione interprocesso tra processi che eseguono collettivamente un'app. Ad esempio, il modulo IIS FastCGI si basa su named pipe per coordinare i singoli processi che eseguono le pagine PHP.

Esecuzione del codice, processi e memoria

Come indicato in precedenza, le app vengono eseguite all'interno di processi di lavoro con privilegi limitati usando un'identità casuale del pool di applicazioni. Il codice dell'applicazione ha accesso allo spazio di memoria associato al processo di lavoro, insieme ai processi figlio che possono generare processi CGI o altre applicazioni. Tuttavia, un'app non può accedere alla memoria o ai dati di un'altra app, anche se si trova nella stessa macchina virtuale.

Le app possono eseguire script o pagine scritte con framework di sviluppo Web supportati. Il servizio app non configura le impostazioni dei framework Web su modalità con maggiori restrizioni. Ad esempio, ASP.NET le app in esecuzione in servizio app vengono eseguite con attendibilità totale, anziché una modalità di attendibilità più limitata. I framework Web, inclusi ASP classico e ASP.NET, possono chiamare componenti COM in-process (ad esempio ActiveX Data Objects) registrati per impostazione predefinita nel sistema operativo Windows. I framework Web non possono chiamare componenti COM out-of-process.

Un'app può generare ed eseguire codice arbitrario, aprire una shell dei comandi o eseguire uno script di PowerShell. Tuttavia, i programmi eseguibili e gli script sono ancora limitati ai privilegi concessi al pool di applicazioni padre. Ad esempio, un'app può generare un programma eseguibile che effettua una chiamata HTTP in uscita, ma tale programma eseguibile non può tentare di scollegare l'indirizzo IP di una macchina virtuale dalla scheda di rete. L'esecuzione di una chiamata di rete in uscita è consentita per il codice con privilegi limitati, ma il tentativo di riconfigurare le impostazioni di rete in una macchina virtuale richiede privilegi amministrativi.

Log ed eventi di diagnostica

Le informazioni di log sono un altro set di dati a cui alcune app tentano di accedere. I tipi di informazioni di log disponibili per il codice in esecuzione in servizio app includono informazioni di diagnostica e log generate da un'app e possono accedere facilmente.

Ad esempio, i log HTTP W3C generati dall'app sono disponibili:

• In una directory di log nel percorso di condivisione di rete creato per l'app
• Nell'archiviazione BLOB se si configura la registrazione W3C nell'archiviazione

Quest'ultima opzione consente alle app di raccogliere grandi quantità di log senza superare i limiti di archiviazione dei file associati a una condivisione di rete.

Analogamente, le informazioni di diagnostica in tempo reale delle app .NET possono essere registrate tramite l'infrastruttura di diagnostica e traccia .NET. È quindi possibile scrivere le informazioni di traccia nella condivisione di rete dell'app o in un percorso di archiviazione BLOB.

Le aree di registrazione e traccia di diagnostica non disponibili per le app sono eventi ETW (Event Tracing for Windows) e registri eventi comuni di Windows (ad esempio, registro eventi di sistema, applicazioni e log eventi di sicurezza). Poiché le informazioni di traccia ETW possono essere potenzialmente visualizzabili in un computer (con gli elenchi di controllo di accesso corretti), l'accesso in lettura e l'accesso in scrittura agli eventi ETW vengono bloccati. Le chiamate API per leggere e scrivere eventi ETW e log eventi di Windows comuni potrebbero sembrare funzionare, ma in realtà il codice dell'applicazione non ha accesso a questi dati dell'evento.

Accesso al Registro di sistema

Le app hanno accesso in sola lettura a molte (anche se non a tutte) del Registro di sistema della macchina virtuale in cui sono in esecuzione. Questo accesso significa che le app possono accedere alle chiavi del Registro di sistema che consentono l'accesso in sola lettura al gruppo Utenti locali. Un'area del Registro di sistema attualmente non supportata per l'accesso in lettura o scrittura è l'hive HKEY\_CURRENT\_USER .

L'accesso in scrittura al Registro di sistema è bloccato, incluso l'accesso a qualsiasi chiave del Registro di sistema per utente. Dal punto di vista dell'app, non può basarsi sull'accesso in scrittura al Registro di sistema nell'ambiente Azure perché è possibile eseguire la migrazione delle app tra macchine virtuali. L'unica risorsa di archiviazione scrivibile persistente da cui un'app può dipendere è la struttura di directory del contenuto per app archiviata nelle condivisioni UNC servizio app.

Accesso tramite Desktop remoto

Il servizio app non fornisce l'accesso tramite Desktop remoto alle istanze della macchina virtuale.

Altre informazioni

Per le informazioni più aggiornate sull'ambiente di esecuzione di servizio app, vedere sandbox del servizio app Azure. Il team di sviluppo servizio app gestisce questa pagina.