Bonnes 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’un compte de base de données ou 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
• Frais monétaires pour le transfert de données sortantes entre les régions, comme indiqué dans la page de tarification Azure

La colocalisation est idéale pour les ressources Azure qui composent une solution. Lorsque vous créez des ressources, assurez-vous qu’elles se présentent dans la même région Azure, sauf si vous avez des raisons professionnelles ou de conception spécifiques pour elles. Vous pouvez déplacer une application App Service vers la même région que votre base de données à l’aide de la fonctionnalité de clonage App Service disponible dans les plans App Service Premium.

Épinglage de certificat

L’épinglage de certificats est une pratique dans laquelle une application autorise uniquement une liste spécifique d’autorités de certification acceptables, des clés publiques, des empreintes numériques ou toute partie de la hiérarchie de certificats.

Les applications ne doivent jamais avoir de dépendance ou d’épingler en dur le certificat TLS par défaut carte (*.azurewebsites.net). App Service est une plateforme en tant que service (PaaS), ce certificat peut donc être pivoté à tout moment. Si le service fait pivoter le caractère générique par défaut carte certificat TLS, les applications épinglées par certificat interrompent et interrompent la connectivité pour les applications qui sont codées en dur vers un ensemble spécifique d’attributs de certificat. 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 difficile 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 s’appuient sur des propriétés de certificat 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 vous surveillez ou que les recommandations de service indiquent qu’une application consomme plus de mémoire que prévu, tenez compte de la fonctionnalité de réparation automatique d’App Service. Vous pouvez configurer la réparation automatique à l’aide de web.config.

L’une des options de la fonctionnalité de réparation automatique consiste à effectuer des actions personnalisées en fonction d’un seuil de mémoire. Les actions vont de Notifications par e-mail à l’investigation via le vidage de mémoire à l’atténuation locale en recyclant le processus de travail.

Ressources du processeur

Lorsque des recommandations de surveillance ou de service indiquent qu’une application consomme plus d’UC que prévu ou qu’elle rencontre des pics répétés de processeur, envisagez de monter en puissance ou de faire évoluer le 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 Scale-up d’une application dans Azure App Service.

Ressources de socket

Une raison courante d’épuiser les 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 le maintien en vie HTTP.

Passez en revue la documentation de chaque bibliothèque que les applications de votre plan App Service référencent. 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. Bien que ces enquêtes sur les bibliothèques clientes soient en cours, vous pouvez atténuer l’impact en effectuant un scale-out vers plusieurs instances.

Requêtes HTTP sortantes et Node.js

Lorsque vous travaillez avec Node.js et de nombreuses requêtes HTTP sortantes, le traitement de la conservation HTTP est important. Vous pouvez utiliser le package agentkeepalivenpm 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 correctement la réponse, votre application est finalement bloquée, car aucun autre socket n’est disponible.

Voici un exemple de gestion de la réponse lorsque vous travaillez avec le ou https le http package :

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 bonne 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). Le résultat de l’échec de l’accès à l’une de ces ressources est un échec de sauvegarde cohérent.

Les deux raisons les plus courantes pour lesquelles la sauvegarde d’application échoue 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 après les modifications apportées aux ressources de stockage ou de base de données, ou après les modifications apportées 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, passez en revue les résultats les plus récents pour comprendre le type de défaillance qui se produit. Pour les échecs d’accès au stockage, passez en revue et mettez à jour les paramètres de stockage dans votre configuration de sauvegarde. Pour les échecs d’accès à la base de données, passez en revue et mettez à jour vos chaîne de connexion dans le cadre des paramètres de l’application. Ensuite, passez à la mise à jour de votre configuration de sauvegarde pour inclure correctement les bases de données requises.

Pour plus d’informations sur les sauvegardes d’applications, consultez Sauvegarder et restaurer votre application dans Azure App Service.

Applications Node.js

La configuration par défaut d’Azure App Service pour les applications Node.js est destinée à répondre le mieux aux besoins des applications les plus courantes. Si vous souhaitez personnaliser la configuration par défaut de votre application Node.js afin d’améliorer les performances ou d’optimiser l’utilisation des ressources pour le processeur, la mémoire ou les ressources réseau, consultez le Guide de résolution des problèmes et des meilleures pratiques 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.

Une pratique courante avec les appareils IoT est l’épinglage de certificats. Pour éviter tout temps d’arrêt imprévu en raison des modifications apportées aux certificats managés du service, vous ne devez jamais épingler des certificats au certificat par défaut *.azurewebsites.net ou à 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 dans votre environnement, ne vous fiez pas à un seul point de terminaison 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 à plusieurs applications web, tant que ces applications web sont hébergées dans différentes régions. Cette fonctionnalité garantit que si vous avez besoin d’é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, telles qu’Azure Front Door ou Azure Traffic Manager, pour garantir une haute disponibilité pour vos applications web. Pour plus d’informations, consultez Démarrage rapide : Créer une instance Front Door pour une application web globale hautement disponible ou contrôler le trafic Azure App Service avec Azure Traffic Manager.

Étapes suivantes

Pour obtenir des bonnes pratiques exploitables spécifiques à votre ressource, utilisez les diagnostics App Service :

1. Accédez à votre application web dans le Portail Azure.
2. Ouvrez les diagnostics App Service en sélectionnant Diagnostiquer et résoudre les problèmes dans le volet gauche.
3. Sélectionnez la vignette Meilleures pratiques .
4. Sélectionnez Les meilleures pratiques pour la disponibilité et les performances ou les meilleures pratiques pour une configuration optimale pour 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.