Modello di hosting del contenuto statico

Distribuire contenuto statico in un servizio di archiviazione basato sul cloud in grado di distribuirlo direttamente al client. Questo approccio può ridurre la necessità di istanze di calcolo potenzialmente costose.

Contesto e problema

Le applicazioni spesso offrono contenuto che non richiede l'elaborazione per ogni richiesta. Gli esempi includono pagine HTML, immagini, fogli di stile, file JavaScript lato client, documenti PDF e pacchetti software. È possibile generare questo contenuto durante un processo di compilazione o pubblicazione e aggiornarlo in modo indipendente.

Nonostante siano ottimizzati per il rendering dinamico e la memorizzazione dell'output nella cache, i server Web devono comunque gestire le richieste per il download del contenuto statico. La gestione di queste richieste utilizza la capacità di calcolo che l'applicazione può usare per le richieste dinamiche.

Solution

Nella maggior parte degli ambienti di hosting cloud, è possibile includere alcune risorse e pagine statiche di un'applicazione in un servizio di archiviazione. Il servizio di archiviazione potrà gestire le richieste relative a tali risorse riducendo il carico sulle risorse di calcolo che gestiscono le altre richieste Web.

Il costo per l'archiviazione ospitata nel cloud è in genere molto inferiore al costo per le istanze di calcolo. Il fatto che questo modello riduca i costi di hosting dipende dal costo di calcolo che è possibile evitare e dal costo di archiviazione e distribuzione del contenuto.

Pianificare come distribuire l'applicazione e i relativi asset statici e proteggere le risorse non destinate all'accesso anonimo.

Problemi e considerazioni

Quando si decide come implementare questo modello, tenere presente quanto segue:

• Esporre un endpoint HTTP o HTTPS per i client, direttamente dall'archiviazione o tramite una content delivery network (CDN) o un proxy inverso. Usare HTTPS per impostazione predefinita per proteggere i dati in transito.

  HTTP può essere appropriato per la distribuzione degli artefatti pubblici quando la riservatezza non è necessaria e i client verificano in modo indipendente l'autenticità e l'integrità del contenuto, ad esempio convalidando le firme digitali rispetto a un autore attendibile.

• Prendere in considerazione l'uso di una rete CDN per memorizzare nella cache il contenuto vicino ai client e ridurre le richieste all'origine di archiviazione. Se i tuoi client sono distribuiti a livello globale, prendi in considerazione una rete CDN globale che memorizza nella cache il contenuto del contenitore di archiviazione in posizioni perimetrali in tutto il mondo. Il vantaggio dipende dalla posizione dei client, dai modelli di richiesta e dalle percentuali di hit della cache.

• Confronta i costi di archiviazione e recapito con i costi di calcolo che è possibile evitare. Stima i costi usando il traffico previsto, le dimensioni degli asset, le località dei client e le percentuali di hit della cache. L'offload riduce i costi di calcolo solo se riduce l'utilizzo fatturato o consente di ridurre la capacità dell'host.

• Selezionare un'opzione di ridondanza dell'archiviazione che soddisfi i requisiti di disponibilità e ripristino. Distinguere la protezione da un'interruzione della zona dalla protezione da un'interruzione regionale. La replica tra aree può essere asincrona, quindi una posizione secondaria potrebbe non avere gli asset più recenti.

  Una rete CDN introduce un'altra dipendenza di distribuzione e la relativa cache potrebbe non contenere tutti gli asset necessari durante un'indisponibilità del server origin.

• Monitorare la disponibilità degli asset, i tempi di risposta e le richieste non riuscite o soggette a throttling nel sistema di storage e in qualsiasi CDN o proxy. Crea avvisi per i problemi di recapito.

• Coordinare le distribuzioni di applicazioni e asset. Pubblicare asset modificati in nuovi URL versionati prima di distribuire le pagine che vi fanno riferimento. Conservare gli asset meno recenti mentre le pagine memorizzate nella cache, le versioni dell'applicazione supportate o le procedure di rollback dipendono comunque da questi asset.

  Configurare le chiavi della cache per distinguere le versioni del contenuto e le varianti. Scegliere anche la durata della cache del browser e della rete CDN deliberatamente. La modifica, l'eliminazione o la limitazione dell'accesso al contenuto di origine non invalidano le copie memorizzate nella cache. Svuotare le cache quando è necessario, ma tenere conto del tempo di propagazione e ricordare che gli svuotamenti della rete CDN non cancellano le cache del browser. Per altre informazioni, vedere Routing della rete CDN e controllo delle versioni e eliminazione della cache in Frontdoor di Azure.

• Impostare e verificare le proprietà HTTP come Content-Type, Content-Encoding e Cache-Control quando si distribuiscono asset in modo che i client interpretino e memorizzino correttamente i file nella cache. Per indicazioni specifiche di Azure, vedere Proprietà HTTP Blob.

• Gestire gli URL durante lo spostamento di file tra posizioni di archiviazione. Usare il routing o la riscrittura dell'URL per mantenere i collegamenti esistenti funzionanti quando cambia solo il layout di archiviazione. Se un URL pubblico deve cambiare, configurare un reindirizzamento sul CDN, sul proxy inverso o su un altro componente http-serving che supporta i mapping necessari. Per indicazioni correlate, vedere Mantenere i collegamenti quando si sposta il contenuto.

• Decidere se le risorse statiche devono usare l'origine pubblica dell'applicazione o un nome host separato. Un proxy inverso può instradare percorsi della stessa origine verso lo storage, quindi l'archiviazione separata non richiede sempre URL assoluti distinti.

  Per le richieste del browser tra le origini che richiedono la condivisione di risorse tra le origini (CORS), configurare le intestazioni di risposta necessarie. Per altre informazioni, vedere Usare Frontdoor di Azure con BLOB di Archiviazione di Azure e il supporto CORS per Archiviazione di Azure.

• Consentire l'accesso in lettura anonimo solo per il contenuto che si intende rendere pubblico. Il recapito pubblico può usare un'origine di archiviazione a cui può accedere solo una rete CDN o un proxy. Limitare l'accesso diretto all'origine quando aggirerebbe i controlli del livello di recapito.

  Mantenere il contenuto privato nei contenitori che richiedono l'autorizzazione. Limita le autorizzazioni per caricare, sostituire o eliminare contenuto ospitato alle identità di distribuzione attendibili. Per altre informazioni, vedere Accesso sicuro alle origini di Frontdoor di Azure.

• Considera l'uso di una chiave di accesso limitato o di un token per controllare l'accesso alle risorse che non dovrebbero essere accessibili anonimamente. Per i download protetti recapitati tramite una rete CDN, disabilitare la memorizzazione nella cache condivisa, a meno che il livello di recapito non convalida le autorizzazioni di accesso per ogni richiesta, anche quando si gestisce una risposta memorizzata nella cache. Per altre informazioni, vedere modello Valet Key e autenticazione per il contenuto di gestione rete virtuale di Azure distribuito tramite Frontdoor di Azure.

Quando usare questo modello

Questo modello è utile per:

• Ridurre al minimo il costo di hosting di applicazioni e siti Web che contengono risorse statiche.

• Ridurre al minimo il costo di hosting per i siti Web costituiti solo da contenuto statico e risorse. In base alle funzionalità del sistema di archiviazione del provider di hosting, potrebbe essere possibile ospitare completamente un sito Web interamente statico in un account di archiviazione.

• Esposizione di risorse e contenuto statico per applicazioni in esecuzione in ambienti di hosting diversi o in server locali.

• Distribuzione di artefatti predefiniti, ad esempio pacchetti software, che i client possono scaricare senza elaborazione per richiesta. Per gli artefatti pubblici recapitati tramite HTTP, i client devono essere in grado di verificare in modo indipendente l'autenticità e l'integrità. Per un esempio di questo approccio, vedere sicurezza di Windows Update.

• Distribuzione del contenuto in più aree geografiche tramite una rete per la distribuzione di contenuti che memorizza nella cache il contenuto dell'account di archiviazione in più data center in tutto il mondo.

• Monitorare i costi e l'uso della larghezza di banda. L'uso di un account di archiviazione separato per una parte o per l'intero contenuto statico consente una più semplice separazione dei costi da quelli di hosting e di runtime.

Questo modello potrebbe non essere adatto quando:

• L'applicazione deve elaborare o personalizzare il contenuto per ogni richiesta prima di recapitarlo. Ad esempio, potrebbe essere necessario inserire dati specifici dell'utente in un documento.

• Il volume del contenuto statico è molto ridotto. Il sovraccarico per il recupero del contenuto da un archivio separato può annullare il vantaggio del costo della separazione dalla risorsa di calcolo.

Progettazione del carico di lavoro

Valutare come usare il modello di hosting di contenuti statici nella progettazione di un carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Example

Archiviazione BLOB di Azure hosting di siti Web statici serve file pubblici dal $web contenitore tramite richieste anonime di sola lettura. Per impostazione predefinita, i file hanno un URL in un sottodominio di core.windows.net, ad esempio https://contoso.z4.web.core.windows.net/image.png. È possibile configurare un nome di dominio personalizzato e usare Frontdoor di Azure Standard o Premium per accedere ai file tramite HTTPS. Per altre informazioni, vedere Eseguire il mapping di un dominio personalizzato a un endpoint di Archiviazione BLOB di Azure.

L'endpoint del sito Web statico non supporta l'autenticazione o l'autorizzazione. La modifica del livello di accesso del $web contenitore o la disabilitazione dell'accesso BLOB anonimo nell'account di archiviazione non rende privato questo endpoint. Non salvare contenuti privati in $web. Per altre informazioni, vedere Impatto dell'impostazione del livello di accesso nel contenitore Web.

Per pubblicare contenuto privato, archiviare i file in un contenitore privato separato di gestione rete virtuale di Azure e usare l'endpoint del servizio BLOB anziché l'endpoint del sito Web statico. Dopo aver autorizzato il client, rilasciare una firma di accesso condiviso di delega utente (SAS) di breve durata, di sola lettura, con ambito ai BLOB necessari. Considerare i token SAS come credenziali e distribuirli solo tramite HTTPS. Per maggiori informazioni, consulta le migliori pratiche nell'uso di SAS.

Abilita Trasferimento sicuro obbligatorio nell'account di archiviazione per rifiutare le richieste HTTP. Per altre informazioni, vedere Trasferimento sicuro obbligatorio.

Se i file statici vengono gestiti da un dominio diverso da quello della pagina, collegarsi agli URL completi, ad esempio https://static.contoso.com/image.png. Se un proxy inverso gestisce i file nel dominio dell'applicazione, è possibile usare percorsi come /image.png invece . Se la risorsa è protetta con un SAS, includere il token SAS nell'URL della risorsa.

L'endpoint del sito Web statico non supporta le regole CORS Archiviazione di Azure. Se lo scenario del browser richiede l'accesso tra le origini, usare un livello di recapito che fornisca le intestazioni CORS necessarie o un endpoint che supporta la configurazione CORS.

L'esempio di hosting di contenuti statici illustra come un client recupera le risorse statiche direttamente da gestione rete virtuale di Azure. Usa Bicep e il interfaccia della riga di comando di Azure per effettuare il provisioning di un account di archiviazione, abilitare l'hosting di siti Web statici e caricare un foglio di stile e una pagina 404 personalizzata nel $web contenitore.

L'esempio genera un file locale index.html sostituendo un segnaposto in un modello HTML con l'URL del sito Web statico dell'account di archiviazione. Quando si apre questo file in un browser, il browser carica il foglio di stile direttamente dall'archiviazione. In un carico di lavoro distribuito nell'ambiente di destinazione, l'ambiente di calcolo delle applicazioni può servire pagine che fanno riferimento a questi asset ospitati nell'archiviazione.

Passaggio successivo

• Usare Frontdoor di Azure con BLOB di Archiviazione di Azure. Applicare questo modello con la memorizzazione nella cache perimetrale, HTTPS e un'origine di archiviazione con restrizioni.

Risorsa collegata

• Schema Valet Key. Se le risorse di destinazione non devono essere disponibili per gli utenti anonimi, usare questo modello per limitare l'accesso diretto.