Emplacements de déploiement et permutation

Les emplacements de déploiement sont des environnements actifs et distincts pour une application web App Service, chacun possédant son propre nom d’hôte (par exemple, myapp-staging.azurewebsites.net). Les emplacements partagent le même plan App Service et les mêmes ressources que l’emplacement de production, mais s’exécutent indépendamment. Ils permettent les déploiements bleu-vert : vous validez une nouvelle version dans un emplacement de préproduction, puis vous la permutez avec la production sans interruption. Les emplacements sont disponibles à partir du niveau Standard.

Ajoutez un nouvel emplacement de déploiement à votre application web à l’aide du portail Azure ou de CLI. Chaque emplacement possède sa propre URL, ses paramètres d’application et ses chaînes de connexion. Vous pouvez créer jusqu’à 5 emplacements avec le niveau Standard et jusqu’à 20 emplacements avec le niveau Premium. Parmi les noms courants figurent staging, canary, hotfix et integration, qui correspondent aux différentes étapes du pipeline de mise en production.

Avant la permutation, il est essentiel de préparer l’emplacement de préproduction afin que la nouvelle version soit entièrement initialisée. Une instance App Service froide traite lentement les premières requêtes, le temps que l’environnement d’exécution s’initialise, ce qui est inacceptable en production. Activez Auto Swap ou envoyez manuellement des requêtes HTTP de préparation à l’emplacement de préproduction. App Service prend également en charge une configuration applicationInitialization permettant de définir des chemins de préparation qui doivent renvoyer le code 200 avant que l’emplacement soit considéré comme prêt.

Une permutation échange de manière atomique les emplacements de préproduction et de production. Lors d’une permutation, App Service achemine d’abord le trafic vers les instances de préproduction exécutant le nouveau code, attend leur initialisation, puis redirige tout le trafic de production vers les nouvelles instances ; les anciennes instances de production deviennent alors le nouvel emplacement de préproduction. Le retour en arrière est ainsi très simple : il suffit d’effectuer une nouvelle permutation.

Les paramètres d’application peuvent être marqués comme liés (propres à l’emplacement) ou non liés (permutables). Les paramètres non liés suivent l’emplacement de déploiement lors d’une permutation : la chaîne de connexion de votre base de données de préproduction suit donc le code jusque dans la production. Les paramètres liés restent associés à l’emplacement, quelles que soient les permutations : la production conserve toujours sa chaîne de connexion à la base de données de production. Marquez les paramètres comme liés à l’aide de la case « paramètre d’emplacement de déploiement » ou de CLI.

App Service prend en charge la répartition du trafic : il achemine un pourcentage du trafic de production vers un emplacement hors production sans effectuer de permutation complète. Cela permet les mises en production canary, où vous augmentez progressivement le trafic de 5 % à 10 %, puis à 50 %, à mesure que vous gagnez confiance dans la nouvelle version, tout en surveillant les taux d’erreur à chaque étape. Les utilisateurs dirigés vers l’emplacement canary reçoivent un cookie persistant qui les maintient sur la même version pendant leur session.

Auto Swap permute automatiquement un emplacement de préproduction avec la production chaque fois qu’un nouveau code y est déployé. Cette fonctionnalité est idéale pour les pipelines CI/CD lorsque vous souhaitez que chaque déploiement réussi soit immédiatement mis en ligne. Auto Swap attend que les requêtes HTTP de l’emplacement de préproduction renvoient le code 200 avant de terminer la permutation. Activez-la pour chaque emplacement dans le portail ou avec CLI, mais utilisez-la avec prudence, car aucune étape d’approbation manuelle ne sépare le déploiement de la mise en production.

Suivez ces bonnes pratiques pour les emplacements de déploiement : validez toujours en préproduction avant de permuter avec la production, utilisez des paramètres liés pour isoler les connexions à la base de données de production de celles de la préproduction, exécutez des tests de fumée sur l’URL de l’emplacement de préproduction après le déploiement, configurez des chemins de contrôle d’intégrité afin qu’App Service n’achève pas la permutation si la nouvelle version n’est pas saine, et étiquetez vos déploiements pour pouvoir identifier le commit actif dans chaque emplacement.

Dans un pipeline CI/CD classique, l’étape de compilation compile et teste le code, l’étape de déploiement envoie l’artefact vers l’emplacement de préproduction, une étape de test d’intégration exécute des tests automatisés sur l’URL de préproduction, puis l’étape de permutation permute la préproduction avec la production, éventuellement après une approbation manuelle. Ce modèle est pris en charge nativement par Azure Pipelines et GitHub Actions avec l’action de déploiement App Service.

Pendant et après une permutation d’emplacements, surveillez les métriques clés dans Azure Monitor afin de confirmer que la nouvelle version fonctionne correctement. Soyez attentif aux pics d’erreurs HTTP 5xx, au temps de réponse moyen et à l’utilisation du CPU et de la mémoire. Configurez des alertes de métriques qui se déclenchent si les taux d’erreur dépassent un seuil ; vous disposerez ainsi d’un signal pour effectuer rapidement une nouvelle permutation en sens inverse. La détection intelligente d’Application Insights peut vous avertir automatiquement des anomalies après un déploiement.

Les emplacements de déploiement sont préférables à la gestion d’applications App Service entièrement distinctes pour la préproduction et la production, car ils partagent le même plan (sans coût supplémentaire), permettent une permutation en un clic avec retour en arrière, prennent en charge la répartition du trafic et sont gérés dans la même ressource App Service. Utilisez des applications distinctes uniquement lorsque la préproduction nécessite des SKU de plan fondamentalement différents, des exigences d’isolation particulières ou une facturation totalement séparée.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les emplacements de déploiement fournissent des environnements isolés permettant les déploiements bleu-vert, que les paramètres liés à l’emplacement maintiennent la configuration propre à chaque environnement (comme les URL de base de données) associée à l’emplacement plutôt qu’au code, et que la répartition du trafic permet les mises en production canary en acheminant un pourcentage du trafic de production vers une nouvelle version. Nous allons maintenant découvrir la mise à l’échelle automatique et les domaines personnalisés.