Modèle d’hébergement de contenu statique

Déployez du contenu statique sur un service de stockage cloud qui peut le diffuser directement au client. Cette approche peut réduire le besoin d’instances de calcul potentiellement coûteuses.

Contexte et problème

Les applications fournissent souvent du contenu qui ne nécessite pas de traitement pour chaque requête. Les exemples incluent des pages HTML, des images, des feuilles de style, des fichiers JavaScript côté client, des documents PDF et des packages logiciels. Vous pouvez générer ce contenu pendant un processus de génération ou de publication et le mettre à jour indépendamment.

Bien que les serveurs web soient optimisés pour le rendu dynamique et la mise en cache de sortie, ils doivent néanmoins gérer les requêtes pour le téléchargement de contenu statique. Le traitement de ces requêtes consomme la capacité de calcul que l’application pourrait utiliser pour les requêtes dynamiques.

Solution

Dans la plupart des environnements d’hébergement cloud, vous pouvez placer certaines des ressources et des pages statiques d’une application dans un service de stockage. Le service de stockage peut traiter les requêtes de ces ressources, ce qui permet ainsi de réduire la charge des ressources de calcul qui gèrent d’autres requêtes web.

Le coût du stockage hébergé dans le cloud est généralement beaucoup moins élevé que le coût des instances de calcul. La question de savoir si ce modèle réduit les coûts d’hébergement dépend du coût de calcul que vous pouvez éviter et du coût de stockage et de remise du contenu.

Planifiez le déploiement de l’application et de ses ressources statiques, et sécurisez les ressources qui ne sont pas destinées à un accès anonyme.

Problèmes et considérations

Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :

• Exposez un point de terminaison HTTP ou HTTPS pour les clients, directement depuis un service de stockage ou via un réseau de distribution de contenu (CDN) ou un proxy inverse. Utilisez HTTPS par défaut pour protéger les données en transit.

  HTTP peut être approprié pour la distribution d’artefacts publics lorsque la confidentialité n’est pas requise et que les clients vérifient indépendamment l’authenticité et l’intégrité du contenu, par exemple en validant les signatures numériques auprès d’un éditeur de confiance.

• Envisagez d’utiliser un CDN pour mettre en cache du contenu au plus près des clients et réduire les requêtes vers l’origine de stockage. Si vos clients sont répartis dans le monde entier, envisagez un CDN global qui met en cache le contenu depuis le conteneur de stockage à des points de présence en périphérie dans le monde entier. L’avantage dépend des emplacements clients, des modèles de requête et des taux d’accès au cache.

• Comparez les coûts de stockage et de transfert avec les coûts de calcul que vous pouvez éviter. Estimer les coûts à l’aide du trafic attendu, des tailles des ressources, des emplacements clients et des taux d’accès au cache. Le déchargement réduit les coûts de calcul uniquement s’il réduit l’utilisation facturée ou vous permet de réduire la capacité de l’hôte.

• Sélectionnez une option de redondance de stockage qui répond à vos exigences de disponibilité et de récupération. Distinguez la protection contre une panne de zone contre une panne régionale. La réplication interrégion peut être asynchrone, de sorte qu’un emplacement secondaire ne dispose pas des ressources les plus récentes.

  Un CDN introduit une autre dépendance de distribution, et son cache peut ne pas contenir toutes les ressources dont les clients ont besoin lors d’une indisponibilité du serveur d’origine.

• Surveillez la disponibilité des actifs, les temps de réponse et les requêtes ayant échoué ou soumises à une limitation de débit sur le stockage et n’importe quel CDN ou proxy. Créez des alertes pour les problèmes de remise.

• Coordonnez les déploiements d’applications et d’actifs. Publiez les ressources modifiées à de nouvelles URL versionnées avant de déployer des pages qui les référencent. Conservez les anciennes ressources pendant que les pages mises en cache, les versions d’application prises en charge ou les procédures de restauration dépendent toujours d’elles.

  Configurez les clés de cache pour distinguer les versions de contenu et les variantes. Choisissez également délibérément les durées de vie du navigateur et du cache CDN. La modification, la suppression ou la restriction de l’accès au contenu d’origine n’invalide pas les copies mises en cache. Vider les caches lorsque vous avez besoin de le faire, mais prendre en compte le temps de propagation et n’oubliez pas que les purges CDN ne effacent pas les caches du navigateur. Pour plus d’informations, consultez le routage et le contrôle de version CDN et vider le cache dans Azure Front Door.

• Définissez et vérifiez les propriétés HTTP telles que Content-Type, Content-Encoding et Cache-Control lors du déploiement des ressources afin que les clients interprètent et mettent en cache les fichiers correctement. Pour obtenir des instructions spécifiques à Azure, consultez les propriétés HTTP d’objet blob.

• Gérez les URL lors du déplacement de fichiers entre les emplacements de stockage. Utilisez le routage ou la réécriture d’URL pour conserver les liens existants lorsque seule la disposition du stockage change. Si une URL publique doit changer, configurez une redirection sur le CDN, le proxy inverse ou un autre composant de service HTTP qui prend en charge les mappages requis. Pour obtenir des conseils connexes, consultez Conserver les liens lorsque le contenu est déplacé.

• Déterminez si les ressources statiques doivent utiliser l’origine publique de l’application ou un nom d’hôte distinct. Un proxy inverse peut router les chemins de même origine vers le stockage. Par conséquent, le stockage distinct ne nécessite pas toujours d’URL absolues distinctes.

  Pour les requêtes de navigateur inter-origines qui nécessitent un partage de ressources inter-origines (CORS), configurez les en-têtes de réponse requis. Pour plus d’informations, consultez Utiliser Azure Front Door avec stockage Azure blobs et la prise en charge de CORS pour stockage Azure.

• Autorisez l’accès en lecture anonyme uniquement pour le contenu que vous envisagez de rendre public. La distribution publique peut utiliser une origine de stockage accessible uniquement par un CDN ou un proxy. Restreindre l’accès direct à l’origine lorsqu’il contourne les contrôles de la couche de distribution.

  Conservez du contenu privé dans des conteneurs qui nécessitent une autorisation. Limitez aux identités de déploiement approuvées les autorisations permettant de charger, remplacer ou supprimer le contenu hébergé. Pour plus d’informations, consultez Sécuriser l'accès aux origines Azure Front Door.

• Utilisez une clé de valet ou un jeton pour contrôler l’accès aux ressources qui ne doivent pas être disponibles de façon anonyme. Pour les téléchargements protégés remis via un CDN, désactivez la mise en cache partagée, à moins que la couche de remise valide les autorisations d’accès sur chaque demande, même lors du traitement d’une réponse mise en cache. Pour plus d’informations, consultez Modèle de clé de valet et Authentification du contenu du stockage Blob remis via Azure Front Door.

Quand utiliser ce modèle

Ce modèle est utile dans les situations suivantes :

• Pour réduire le coût d’hébergement des sites web et des applications qui contiennent certaines ressources statiques.

• Pour réduire le coût d’hébergement des sites web qui comprennent uniquement des ressources et du contenu statiques. En fonction des capacités du système de stockage du fournisseur d’hébergement, il est possible d’héberger intégralement un site web complètement statique dans un compte de stockage.

• Pour exposer du contenu et des ressources statiques pour les applications s’exécutant dans d’autres environnements d’hébergement ou sur des serveurs locaux.

• Distribution d’artefacts prédéfinis, tels que des packages logiciels, que les clients peuvent télécharger sans traitement par demande. Pour les artefacts publics remis sur HTTP, les clients doivent être en mesure de vérifier indépendamment l’authenticité et l’intégrité. Pour obtenir un exemple de cette approche, consultez Sécurité de Windows Update.

• Distribution de contenu dans plusieurs zones géographiques à l’aide d’un réseau de distribution de contenu qui met en cache le contenu du compte de stockage dans plusieurs centres de données du monde entier.

• Pour surveiller les coûts et l’utilisation de la bande passante. Utiliser un compte de stockage distinct pour certains ou l’ensemble des contenus statiques permet de séparer plus facilement les coûts d’exécution et d’hébergement.

Ce modèle peut ne pas convenir lorsque :

• L’application doit traiter ou personnaliser le contenu de chaque requête avant de le livrer. Par exemple, il peut être nécessaire d’insérer des données spécifiques à l’utilisateur dans un document.

• Le volume du contenu statique est très faible. La surcharge liée à la récupération de ce contenu à partir du stockage distinct peut annuler l’avantage en termes de coûts de sa séparation de la ressource de calcul.

Conception de la charge de travail

Évaluez comment utiliser le modèle d'hébergement de contenu statique dans la conception d'une charge de travail pour répondre aux objectifs et principes couverts par les piliers du Azure Well-Architected Framework. Par exemple:

Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.

Example

L’hébergement de sites web statiques Stockage Blob Azure sert des fichiers publics à partir du conteneur $web par le biais de requêtes anonymes en lecture seule. Par défaut, les fichiers ont une URL dans un sous-domaine de core.windows.net, par exemple https://contoso.z4.web.core.windows.net/image.png. Vous pouvez configurer un nom de domaine personnalisé et utiliser Azure Front Door Standard ou Premium pour accéder aux fichiers via HTTPS. Pour plus d’informations, consultez Associer un domaine personnalisé à une terminaison de Stockage Blob Azure.

Le point de terminaison de site web statique ne prend pas en charge l’authentification ou l’autorisation. $web La modification du niveau d’accès du conteneur ou la désactivation de l’accès anonyme aux objets blob sur le compte de stockage ne rend pas ce point de terminaison privé. Ne stockez pas de contenu privé dans $web. Pour plus d’informations, consultez Impact de la définition du niveau d’accès sur le conteneur web.

Pour diffuser du contenu privé, stockez les fichiers dans un conteneur de Stockage Blob privé distinct et utilisez le point de terminaison du service Blob plutôt que le point de terminaison du site web statique. Après avoir autorisé le client, émettez une signature d’accès partagé (SAS) de délégation d’utilisateur à courte durée de vie en lecture seule, limitée aux objets blob requis. Traitez les jetons SAS en tant qu’informations d’identification et distribuez-les uniquement via HTTPS. Pour plus d’informations, consultez Meilleures pratiques lors de l’utilisation du SAS.

Activez le transfert sécurisé requis sur le compte de stockage pour rejeter les requêtes HTTP. Pour plus d’informations, consultez Exiger un transfert sécurisé.

Si les fichiers statiques sont servis à partir d’un domaine différent de la page, créez un lien vers leurs URL complètes, telles que https://static.contoso.com/image.png. Si un proxy inverse sert les fichiers sous le domaine de l’application, vous pouvez utiliser des chemins comme /image.png au lieu de cela. Si la ressource est protégée par un SAS, incluez le jeton SAS dans l’URL de la ressource.

Le point de terminaison de site web statique ne prend pas en charge les règles CORS d’stockage Azure. Si votre scénario de navigateur nécessite un accès inter-origine, utilisez une couche de remise qui fournit les en-têtes CORS requis ou un point de terminaison qui prend en charge la configuration CORS.

L'exemple d’hébergement de contenu statique montre comment un client récupère des ressources statiques directement à partir du stockage Blob. Il utilise Bicep et le Azure CLI pour approvisionner un compte de stockage, activer l’hébergement de sites web statiques et charger une feuille de style et une page 404 personnalisée sur le $web conteneur.

L’exemple génère un fichier local index.html en remplaçant un espace réservé dans un modèle HTML par l’URL du site web statique du compte de stockage. Lorsque vous ouvrez ce fichier dans un navigateur, le navigateur charge la feuille de style directement à partir du stockage. Dans une charge de travail déployée, les ressources de calcul de l’application peuvent fournir des pages qui référencent ces ressources hébergées dans le stockage.

Étape suivante

• Utilisez Azure Front Door avec des objets blob stockage Azure. Appliquez ce modèle avec la mise en cache en périphérie, HTTPS et une origine de stockage restreinte.

Ressource associée

• Modèle de clé de valet. Si les ressources cibles ne doivent pas être disponibles pour les utilisateurs anonymes, utilisez ce modèle pour restreindre l’accès direct.