Présentation du cache local d’Azure App Service
Notes
Le cache local n’est pas pris en charge dans les applications de fonction ni dans les applications App Service conteneurisées, telles que dans Conteneurs Windows ou sur App Service sur Linux. Une version du cache local disponible pour ces types d’applications est App Cache.
Le contenu Azure App Service est stocké dans le Stockage Azure et est exposé de manière durable en tant que partage de contenu. Destinée à fonctionner avec de nombreuses applications, cette conception présente les caractéristiques suivantes :
- Le contenu est partagé entre plusieurs instances de machine virtuelle de l’application.
- Le contenu est durable et peut être modifié en exécutant des applications.
- Les fichiers journaux et les fichiers de données de diagnostic sont disponibles sous le même dossier de contenu partagé.
- La publication d’un nouveau contenu met directement à jour le dossier de contenu, que vous pouvez consulter tout de suite via le site web SCM et l’application en cours d’exécution (pour obtenir le contenu le plus récent, certaines technologies, comme ASP.NET, lancent généralement un redémarrage de l’application quand des changements sont apportés aux fichiers).
Tandis que de nombreuses applications utilisent une seule ou la totalité de ces fonctionnalités, certaines autres ont uniquement besoin d’un magasin de contenu en lecture seule très performant à partir duquel elles peuvent s’exécuter avec une haute disponibilité. Ces applications peuvent tirer profit d’une instance de machine virtuelle sur un cache local spécifique.
La fonctionnalité de cache local d’Azure App Service fournit une vue de rôle web de votre contenu. Ce contenu est un cache d’écriture avec rejet de votre contenu de stockage qui est créé de façon asynchrone au démarrage du site. Quand le cache est prêt, le site est basculé pour s’exécuter sur le contenu mis en cache. Les applications qui s’exécutent sur le cache local bénéficient des avantages suivants :
- Elles sont protégées contre les latences qui se produisent quand elles accèdent au contenu sur Azure Storage.
- Elles ne sont pas affectées par les problèmes de connexion au stockage, car la copie en lecture seule est mise en cache sur le rôle de travail.
- Elles ne redémarrent pas systématiquement après des modifications du partage de stockage.
Notes
Si vous utilisez Java (Java SE, Tomcat ou JBoss EAP), les artefacts Java (fichiers .jar, .war et .ear) sont copiés localement dans le rôle de travail. Si votre application Java dépend également de l’accès en lecture seule à d’autres fichiers, définissez JAVA_COPY_ALL
sur true
pour que ces fichiers soient également copiés. Si le cache local est activé, il est prioritaire par rapport à cette amélioration spécifique à Java.
Comment le cache local change le comportement d’App Service
- D:\home pointe vers le cache local, qui est créé sur l’instance de machine virtuelle au démarrage de l’application. D:\local continue de pointer vers le stockage propre à la machine virtuelle temporaire.
- Le cache local contient une copie unique des dossiers /site et /siteextensions du magasin de contenu partagé dans D:\home\site et D:\home\siteextensions, respectivement. Les fichiers sont copiés dans le cache local, au démarrage de l’application. La taille des deux dossiers pour chaque application est limitée à 1 Go par défaut, mais vous pouvez l’augmenter à 2 Go. Notez que le temps de chargement du cache s’allonge proportionnellement à l’augmentation de la taille du cache. Si vous avez augmenté la limite du cache local à 2 Go et que les fichiers copiés dépassent la taille maximale de 2 Go, App Service ignore silencieusement le cache local et lit à partir du partage de fichiers distant.
Important
Lorsque les fichiers copiés dépassent la limite de taille du cache local définie ou lorsqu'aucune limite n'est définie, les opérations de déploiement et d'échange peuvent échouer avec une erreur. Consultez la FAQ pour plus d'informations.
- Le cache local est en lecture-écriture. Toutefois, toute modification est ignorée quand l’application change de machine virtuelle ou est redémarrée. N’utilisez pas le cache local pour des applications qui stockent des données stratégiques dans le magasin de contenu.
- D:\home\LogFiles et D:\home\Data contiennent des fichiers journaux et des données d’application. Les deux sous-dossiers sont stockés localement sur l’instance de machine virtuelle et sont copiés régulièrement dans le magasin de contenu partagé. Les applications peuvent conserver des fichiers journaux et des données en les écrivant dans ces dossiers. Toutefois, la copie dans le magasin de contenu partagé est une technique de « meilleur effort », vous n’êtes donc pas à l’abri d’une perte des fichiers journaux et des données en cas d’incident soudain sur une instance de machine virtuelle.
- Le streaming des journaux est affecté par la copie de « meilleur effort ». Vous pouvez observer jusqu’à une minute de délai dans les journaux d’activité diffusés en continu.
- Dans le magasin de contenu partagé, la structure des dossiers LogFiles et Data change pour les applications qui utilisent le cache local. Ces dossiers contiennent maintenant des sous-dossiers dont le nom est formé d’un « identificateur unique » et d’un horodatage. Chaque sous-dossier correspond à une instance de machine virtuelle sur laquelle l’application est en cours d’exécution ou s’est exécutée.
- Les autres dossiers de D:\home restent dans le cache local et ne sont pas copiés dans le magasin de contenu partagé.
- Le déploiement d’applications par n’importe quelle méthode prise en charge publie directement dans le magasin de contenu partagé durable. Pour actualiser les dossiers D:\home\site et D:\home\siteextensions dans le cache local, l’application doit être redémarrée. vous pouvez rendre le cycle de vie transparent. Pour plus d’informations, consultez la suite de cet article.
- L’affichage de contenu par défaut du site SCM continue à être celui du magasin de contenu partagé.
Activer le cache local dans App Service
Notes
Le cache local n’est pas pris en charge pour les niveaux F1 et D1.
Configurez le cache local à l’aide d’une combinaison de paramètres d’application réservés. Pour configurer ces paramètres d’application, vous pouvez utiliser les méthodes suivantes :
Configurer le cache local à l’aide du portail Azure
Activez le cache local pour chaque application web en utilisant ce paramètre d’application : WEBSITE_LOCAL_CACHE_OPTION
= Always
Configurer le cache local à l’aide d’Azure Resource Manager
...
{
"apiVersion": "2015-08-01",
"type": "config",
"name": "appsettings",
"dependsOn": [
"[resourceId('Microsoft.Web/sites/', variables('siteName'))]"
],
"properties": {
"WEBSITE_LOCAL_CACHE_OPTION": "Always",
"WEBSITE_LOCAL_CACHE_SIZEINMB": "1000"
}
}
...
Modifier le paramètre de taille dans le cache local
Par défaut, la taille du cache local est de 1 Go. Elle inclut les dossiers /site et /siteextensions qui sont copiés à partir du magasin de contenu, ainsi que tous les dossiers de journaux d’activité et de données créés localement. Pour augmenter cette limite, utilisez le paramètre d’application WEBSITE_LOCAL_CACHE_SIZEINMB
. Vous pouvez augmenter la taille jusqu’à 2 Go (2000 Mo) par application. Notez que le temps de chargement du cache s’allonge proportionnellement à l’augmentation de sa taille.
Bonnes pratiques pour utiliser le cache local d’App Service
Nous vous recommandons d’utiliser le cache local conjointement avec la fonctionnalité Environnements de préproduction .
- Ajoutez le paramètre d’application associé
WEBSITE_LOCAL_CACHE_OPTION
avec la valeurAlways
à votre emplacement de production. Si vous utilisez le paramètre d’applicationWEBSITE_LOCAL_CACHE_SIZEINMB
, ajoutez-le également comme paramètre associé à votre emplacement de production. - Créez un emplacement de préproduction pour la publication. En règle générale, si vous utilisez le cache local pour l’emplacement de production, vous n’avez pas à définir l’emplacement de préproduction pour utiliser le cache local en vue d’implémenter un cycle de vie build-déploiement-test transparent.
- Testez votre site par rapport à votre emplacement de préproduction.
- Quand vous êtes prêt, lancez une opération d’échange entre vos emplacements de préproduction et de production.
- Les paramètres associés incluent un nom et sont rattachés à un emplacement. Ainsi, quand l’emplacement de préproduction est échangé avec l’emplacement de production, il hérite des paramètres d’application du cache local. L’emplacement de production qui vient d’être échangé s’exécute sur le cache local après quelques minutes. Il est ensuite initialisé dans le cadre de l’initialisation des emplacements après l’échange. Une fois l’échange des emplacements terminé, votre emplacement de production s’exécute sur le cache local.
Forum aux questions (FAQ)
Que se passe-t-il si la limite de taille du cache local est dépassée ?
Lorsque les fichiers copiés dépassent la limite de taille du cache local, l’application lit à partir du partage distant. Toutefois, les opérations de déploiement et d’échange peuvent échouer avec une erreur. Consultez le tableau ci-dessous pour connaître les limites de taille et les résultats.
Taille du cache local | Fichiers copiés | Résultat |
---|---|---|
≤ 2 GO | ≤ Taille du cache local | Lit à partir du cache local. |
≤ 2 GO | > Taille du cache local | Lit à partir du partage distant. Remarque : Déploiement et les opérations d’échange peuvent échouer avec une erreur. |
Comment savoir si mon application peut bénéficier de la fonctionnalité de cache local ?
Utilisez la fonctionnalité de cache local si votre application a besoin d’un magasin de contenu fiable et très performant, si elle n’utilise pas le magasin de contenu pour écrire des données stratégiques au moment de l’exécution et si elle a une taille totale inférieure à 2 Go. Vous pouvez obtenir la taille totale de vos dossiers /site et /siteextensions en utilisant l’extension de site Utilisation du disque d’Azure Web Apps.
Comment savoir si mon site a basculé pour utiliser le cache local ?
Si vous utilisez la fonctionnalité de cache local avec des environnements de préproduction, l’opération d’échange prend fin seulement après l’initialisation du cache local. Pour vérifier si votre site s’exécute sur le cache local, examinez la variable d’environnement de processus de travail WEBSITE_LOCALCACHE_READY
. Suivez les instructions fournies dans la page de la variable d’environnement de processus de travail pour accéder à cette variable sur plusieurs instances.
Je viens de publier de nouvelles modifications, mais mon application ne semble pas les avoir intégrées. Pourquoi ?
Si votre application utilise le cache local, vous devez redémarrer votre site pour voir les dernières modifications. Si vous ne voulez pas publier les modifications sur un site de production, consultez les options d’emplacement décrites dans la section sur les bonnes pratiques, plus haut dans cet article.
Notes
L’option de déploiement exécuter à partir du package n’est pas compatible avec un cache local.
Où sont mes journaux d’activité ?
Avec le cache local, vos dossiers de données et de journaux d’activité se présentent un peu différemment. Toutefois, la structure de vos sous-dossiers reste la même, excepté que les sous-dossiers se trouvent sous un sous-dossier dont le nom est formé d’un identificateur de machine virtuelle unique et d’un horodatage.
J’ai activé le cache local, mais mon application redémarre systématiquement. Pourquoi ? Je pensais que le cache local évitait les redémarrages d’application fréquents.
En effet, le cache local contribue à limiter les redémarrages d’application liés au stockage. Toutefois, des redémarrages de votre application peuvent toujours être nécessaires pendant les mises à niveau planifiées de l’infrastructure de la machine virtuelle. Quand le cache local est activé, les redémarrages d’application globaux sont normalement moins nombreux.
Le cache local exclut-il des répertoires de la copie vers le disque local plus rapide ?
Durant l’étape de copie du contenu du stockage, tous les dossiers étant des référentiels nommés sont exclus. Cela est utile pour les scénarios où le contenu de votre site peut contenir un dépôt de contrôle de code source qui n’est pas nécessaire dans une utilisation quotidienne de l’application.
Comment vider les journaux du cache local après une opération de gestion de site ?
Pour vider les journaux du cache local, arrêtez et redémarrez l’application. Cette action efface l’ancien cache.
Pourquoi App Service démarre-t-il en affichant des fichiers précédemment déployés après un redémarrage lorsque le cache local est activé ?
Si App Service commence à montrer des fichiers précédemment déployés à un redémarrage, vérifiez la présence du paramètre d’application - 'WEBSITE_DISABLE_SCM_SEPARATION=true'. Après l’ajout de ce paramètre, tous les déploiements via KUDU commencent à écrire sur la machine virtuelle locale au lieu du stockage persistant. Les meilleures pratiques mentionnées plus haut dans cet article doivent être appliquées ; les déploiements doivent toujours être effectués sur l’emplacement intermédiaire pour lequel le cache local n’est pas activé.
Plus de ressources
Informations de référence sur les variables d’environnement et les paramètres d’application