Funzionalità del sistema operativo nel servizio app di Azure

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

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

Poiché il servizio app supporta un'esperienza di scalabilità uniforme tra livelli, la configurazione di sicurezza applicata per le app del 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 di servizio app passa da un livello a un altro.

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, l'ampiezza delle funzionalità del framework disponibili per le app rimane invariata indipendentemente dai livelli di scalabilità.

Il 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, le app del servizio 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 o patch specifica. Consigliamo ai clienti di mirare alle versioni principali come necessario.

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

Esistono diversi drive all'interno del Servizio App, inclusi i drive locali e i drive di rete.

Il servizio app è un servizio eseguito 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. Includono:

• Unità del sistema operativo (%SystemDrive%) le cui dimensioni dipendono dalle dimensioni della macchina virtuale.
• Unità di risorse (%ResourceDrive%) utilizzata internamente da App Service.

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 codificate staticamente con riferimenti al percorso del file continuano a funzionare perché il Servizio app esegue automaticamente la rimappatura affinché punti a d:\. 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. Per esempio:

• L'app potrebbe generare un errore che indica che lo spazio sul disco non è sufficiente.
• È possibile che vengano visualizzati errori del disco quando si accede alla 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.

Uno degli aspetti univoci del servizio app che semplifica la distribuzione e la manutenzione delle app è che tutte le condivisioni di contenuto vengono archiviate in un set di condivisioni UNC (Universal Naming Convention). Questo modello è mappato bene al modello comune di archiviazione del contenuto usato dagli ambienti di hosting Web locali con più server con carico bilanciato.

All'interno di App Service, le condivisioni UNC vengono create in ogni data center. Una percentuale dei contenuti utente di tutti i clienti in ogni data center viene assegnata a ciascuna condivisione UNC. L'abbonamento di ogni cliente ha una struttura di directory riservata su una condivisione UNC specifica in un centro dati. 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 abbassate durante il normale corso delle operazioni di Azure. Per questo motivo, le app non dovrebbero mai assumere che le informazioni sulla macchina in un percorso di file UNC rimangano stabili nel tempo. È invece consigliabile usare il pratico faux percorso assoluto %HOME%\site fornito da App Service.

Il percorso assoluto finto è un metodo portabile per riferirsi alla propria 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.

La %HOME% directory in un'app è mappata a una condivisione di contenuti nell'archiviazione di Azure dedicata a 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 il servizio app si 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'applicazione. 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. La finalità consiste invece nel fornire l'archiviazione file temporanea per i framework di applicazioni Web e IIS.

Il 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:

La directory per i file temporanei di ASP.NET e la directory per i file compressi di IIS sono due esempi di come App Service utilizzi lo spazio di archiviazione locale temporaneo. 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 %SystemDrive%\local\IIS Temporary Compressed Files directory per archiviare l'output della risposta compresso. Entrambi questi tipi di utilizzo dei file (insieme ad altri) vengono rimappati nel servizio app allo storage locale temporaneo per singola app. Questo nuovo mapping consente di garantire che la funzionalità continui come previsto.

Ogni app in App Service viene eseguita come una identità di processo di lavoro casuale, univoca e con privilegi limitati, chiamata 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à.

La directory di condivisione dei contenuti (%HOME%) contiene i contenuti 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 viene condivisa tra le istanze. Inoltre, non viene condivisa tra l'app e l'app Kudu.

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 al database SQL di Azure.

È disponibile anche una capacità limitata per le app di stabilire una connessione loopback locale e consentire a un'app di ascoltare su quel socket di loopback locale. Questa funzionalità abilita le app che utilizzano socket di loopback locali come parte del loro funzionamento. 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 pagine PHP.

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 alcuna impostazione del framework Web in modalità più limitate. Ad esempio, le app ASP.NET in esecuzione in App Service vengono eseguite con fiducia totale, piuttosto che in una modalità di fiducia 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 i 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ò provare a 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.

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 App Service includono informazioni di diagnostica e di log che un'app genera e a cui può accedere facilmente.

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

• In una cartella di log nel percorso di condivisione di rete che hai creato per l'app.
• Nell'archiviazione BLOB, se si configura la registrazione W3C nel sistema di 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 registrare le informazioni di traccia sulla condivisione di rete dell'app o in una posizione di archiviazione di tipo BLOB.

Le aree di registrazione diagnostica e tracciamento non disponibili per le app sono eventi ETW (Event Tracing for Windows) e i registri eventi comuni di Windows (ad esempio, il registro eventi di sistema, i registri eventi di applicazione e di sicurezza). Poiché le informazioni di traccia ETW possono essere potenzialmente visualizzabili in un computer usando 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.

Le app hanno accesso in sola lettura a molte, anche se non 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 che attualmente non è supportata né per l'accesso in lettura né in scrittura è il nucleo 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 del servizio app.

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

Per informazioni più up-to-date sull'ambiente di esecuzione del servizio app, vedere sandbox del servizio app di Azure. Il team di sviluppo del servizio app gestisce questa pagina.