Meilleures pratiques pour Azure App Service
Cet article résume les meilleures pratiques dans l’utilisation de Azure App Service.
Colocalisation
Une solution Azure App Service se compose d’une application web et d’une base de données ou d’un compte de stockage pour contenir du contenu ou des données. Lorsque ces ressources se trouvent dans différentes régions, la situation peut avoir les effets suivants :
- Une latence plus élevée dans la communication entre les ressources
- Des frais pour le transfert de données sortant entre les régions, comme indiqué sur la page de tarification Azure
La colocation est idéale pour les ressources Azure qui font partie d’une solution. Lors de la création de ressources, assurez-vous que celles-ci se trouvent dans la même région Azure, à moins que des motifs commerciaux ou conceptuels spécifiques entravent cette possibilité. Vous pouvez déplacer une application App Service vers la région dans laquelle se trouve votre base de données en utilisant la fonctionnalité de clonage d’App Service, disponible pour les plans App Service Premium.
Épinglage de certificat
L’épinglage des certificat est une pratique selon laquelle une application n’autorise qu’une liste spécifique d’autorités de certification (AC) acceptables, de clés publiques, d’empreintes ou de n’importe quelle partie de la hiérarchie de certificats.
Les applications ne doivent jamais avoir de dépendance ou d’épingle en dur au certificat TLS générique (*.azurewebsites.net) par défaut. App Service est une PaaS (platform as a service). Ce certificat peut donc être pivoté à tout moment. Si le service fait pivoter le certificat TLS générique par défaut, les applications épinglées à un certificat seront interrompues et la connectivité des applications codées en dur pour un ensemble spécifique d’attributs de certificat sera perturbée. La périodicité avec laquelle le certificat est pivoté n’est pas garantie, car la fréquence de rotation peut changer à tout moment.
Les applications qui s’appuient sur l’épinglage de certificat ne doivent pas non plus avoir de dépendance en dur sur un certificat managé App Service. Les certificats managés App Service peuvent être pivotés à tout moment, ce qui entraîne des problèmes similaires pour les applications qui dépendent de propriétés de certificats stables. Il est recommandé de fournir un certificat TLS personnalisé pour les applications qui s’appuient sur l’épinglage de certificat.
Si votre application doit s’appuyer sur le comportement d’épinglage de certificat, nous vous recommandons d’ajouter un domaine personnalisé à une application web et de fournir un certificat TLS personnalisé pour le domaine. L’application peut ensuite s’appuyer sur le certificat TLS personnalisé pour l’épinglage de certificat.
Ressources mémoire
Lorsque les analyses ou les recommandations de service indiquent qu’une application consomme plus de mémoire que prévu, envisagez d’utiliser la fonctionnalité auto-curative d’App Service. Vous pouvez configurer la fonctionnalité auto-curative à l’aide de web.config.
Une des options de la fonctionnalité auto-curative consiste à prendre des actions personnalisées en fonction d’un seuil de mémoire. Les actions vont des notifications par courrier électronique à la prévention immédiate des risques par recyclage du processus Worker, en passant par l’examen via le vidage de la mémoire.
Ressources du processeur
Lorsque les analyses ou les recommandations de service indiquent qu’une application consomme plus d’UC que prévu ou qu’elle provoque des pics de consommation d’UC répétés, envisagez un scale-up ou un scale-out du plan App Service. Si votre application est avec état, le scale-up est la seule option. Si votre application est sans état, le scale-out vous offre une plus grande flexibilité et un potentiel de mise à l’échelle plus élevé.
Pour plus d’informations sur les options de mise à l’échelle et de mise à l’échelle automatique d’App Service, consultez Effectuer un scale-up d’une application dans Azure App Service.
Ressources de socket
Une raison courante d’épuisement des connexions TCP sortantes est l’utilisation de bibliothèques clientes qui ne réutilisent pas les connexions TCP ou qui n’utilisent pas de protocole de niveau supérieur, tel que HTTP keep-alive.
Passez en revue la documentation de chaque bibliothèque référencée par les applications de votre plan App Service. Vérifiez que les bibliothèques sont configurées ou accessibles dans votre code pour une réutilisation efficace des connexions sortantes. Suivez également les instructions de la documentation des bibliothèques pour une création et une mise en production appropriées ainsi que pour un nettoyage servant à éviter la fuite des connexions. Tandis que ces enquêtes sur les bibliothèques clientes sont en cours, vous pouvez atténuer l’impact en effectuant un scale-out vers plusieurs instances.
Node.js et requêtes HTTP sortantes
Quand vous utilisez Node.js avec de nombreuses requêtes HTTP sortantes, il est important de traiter le protocole HTTP keep-alive. Vous pouvez utiliser le package agentkeepalive npm pour en faciliter l’utilisation dans votre code.
Gérez toujours la réponse http, même si vous n’effectuez aucune opération dans le gestionnaire. Si vous ne gérez pas la réponse correctement, votre application finit par se bloquer, car aucun socket supplémentaire n’est disponible.
Voici un exemple de gestion de la réponse lorsque vous travaillez avec le package http ou https :
const request = https.request(options, function(response) {
response.on('data', function() { /* do nothing */ });
});
Si vous exécutez votre application App Service sur une machine Linux qui a plusieurs cœurs, une autre meilleure pratique consiste à utiliser PM2 pour démarrer plusieurs processus Node.js pour exécuter votre application. Pour ce faire, il suffit de spécifier une commande de démarrage à votre conteneur.
Par exemple, utilisez cette commande pour démarrer quatre instances :
pm2 start /home/site/wwwroot/app.js --no-daemon -i 4
Sauvegarde d’application
En général, les sauvegardes s'exécutent de façon planifiée et requièrent l’accès au stockage (pour générer les fichiers sauvegardés) et aux bases de données (pour copier et lire le contenu à inclure dans la sauvegarde). Un problème d’accès à l’une de ces ressources entraîne une erreur de sauvegarde permanente.
Les deux raisons les plus courantes qui entraînent l’échec de la sauvegarde d’une application sont des paramètres de stockage non valides et une configuration de base de données non valide. Ces échecs se produisent généralement à la suite de modifications apportées aux ressources de stockage ou de base de données, ou aux informations d’identification pour accéder à ces ressources. Par exemple, les informations d’identification peuvent être mises à jour pour la base de données que vous avez sélectionnée dans les paramètres de sauvegarde.
Lorsque des échecs de sauvegarde se produisent, veuillez consulter les résultats les plus récents pour comprendre quel type d’échec se produit. Pour les problèmes d’accès au stockage, passez en revue et mettez à jour les paramètres de stockage dans la configuration de votre sauvegarde. Pour les échecs d’accès à la base de données, passez en revue et mettez à jour vos chaînes de connexion dans le cadre des paramètres de l’application. Ensuite, mettez à jour la configuration de votre sauvegarde pour inclure correctement les bases de données requises.
Pour plus d’informations sur les sauvegardes d’application, consultez Sauvegarder et restaurer votre application dans Azure App Service.
Applications Node.js
La configuration Azure App Service par défaut pour les applications Node.js vise à mieux répondre aux besoins des applications les plus courantes. Si vous souhaitez personnaliser la configuration par défaut de votre application Node.js pour améliorer les performances ou optimiser l’utilisation des ressources au niveau du processeur, de la mémoire et du réseau, consultez Meilleures pratiques et guide de dépannage pour les applications Node sur Azure App Service. Cet article décrit les paramètres iisnode que vous devrez peut-être configurer pour votre application Node.js. Il explique également comment résoudre des scénarios ou des problèmes avec votre application.
Appareils IoT
Vous pouvez améliorer votre environnement lorsque vous exécutez des appareils IoT (Internet des objets) connectés à App Service.
L’épinglage de certificat est une pratique courante avec les appareils IoT. Pour éviter tout temps d'arrêt imprévu lié à des modifications des certificats managés du service, vous ne devez jamais épingler les certificats au certificat *.azurewebsites.net par défaut ni à un certificat managé App Service. Si votre système doit s’appuyer sur le comportement d’épinglage de certificat, nous vous recommandons d’ajouter un domaine personnalisé à une application web et de fournir un certificat TLS personnalisé pour le domaine. L’application peut ensuite s’appuyer sur le certificat TLS personnalisé pour l’épinglage de certificat. Pour plus d’informations, consultez la section Épinglage de certificat de cet article.
Pour augmenter la résilience au sein de votre environnement, ne vous appuyez pas sur un point de terminaison unique pour tous vos appareils. Hébergez vos applications web dans au moins deux régions pour éviter un point de défaillance unique et être prêt à basculer le trafic.
Dans App Service, vous pouvez ajouter des domaines personnalisés identiques à différentes applications web tant que ces applications web sont hébergées dans des régions distinctes. Ainsi, s’il vous faut épingler des certificats, vous pouvez également épingler le certificat TLS personnalisé que vous avez fourni.
Une autre option consiste à utiliser un équilibreur de charge devant les applications web, comme Azure Front Door ou Traffic Manager, pour garantir une haute disponibilité pour vos applications web. Pour plus d’informations, consultez Guide de démarrage rapide : Créer une instance Front Door pour une application web globale hautement disponible ou Contrôle du trafic Azure App Service avec Azure Traffic Manager.
Étapes suivantes
Pour connaître les meilleures pratiques exploitables spécifiques à votre ressource, utilisez les diagnostics App Service :
- Accédez à votre application web sur le Portail Azure.
- Ouvrez les diagnostics App Service en sélectionnant Diagnostiquer et résoudre les problèmes dans le volet gauche.
- Sélectionnez la vignette Meilleures pratiques.
- Sélectionnez Meilleures pratiques pour la disponibilité et les performances ou Meilleures pratiques pour une configuration optimale afin d’afficher l’état actuel de votre application en ce qui concerne ces meilleures pratiques.
Vous pouvez également utiliser ce lien pour ouvrir directement les diagnostics App Service pour votre ressource : https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.