Que sont les piles de déploiement ?
Une pile de déploiement Azure est un type de ressource Azure vous permettant de gérer le cycle de vie d’une collection de ressources Azure en tant qu’unité atomique unique. Elle permet des déploiements cohérents et reproductibles, tout en simplifiant la gestion et en permettant une mise à l’échelle et une mise à jour efficaces des ressources.
Dans cette leçon, vous allez découvrir l’organisation des ressources dans Azure et comment les piles de déploiement peuvent vous aider à gérer vos ressources mieux qu’avant.
Organisation des ressources
Il existe de nombreuses façons d’organiser vos ressources dans Azure. Vous pouvez choisir d’organiser des ressources en fonction d’un environnement (production, préproduction, développement), du cycle de vie d’une application ou d’une fonction (connectivité ou ressources de calcul par exemple). Les facteurs comme la taille de votre organisation, le nombre d’applications et la résidence des données influencent ces décisions et il existe de meilleures pratiques générales pour chaque scénario.
Pour les environnements de déploiement, vous pouvez les séparer en différents abonnements, voire en groupes d’administration. Tous les composants d’une application peuvent exister dans un unique groupe de ressources, plusieurs groupes de ressources ou même plusieurs abonnements. Pour une organisation des ressources Azure, les meilleures pratiques suggèrent de les organiser en groupes de ressources en fonction du cycle de vie et de la sécurité.
Application avec un unique groupe de ressources
Il est parfois judicieux d’utiliser un unique groupe de ressources pour votre application. Si vous débutez avec Azure et commencez simplement à utiliser un environnement de développement ou à déployer une application de production sans de nombreuses ressources, un unique groupe de ressources suffit.
Un groupe de ressources est fréquemment utilisé comme limite de sécurité pour les autorisations. Vous pouvez gérer une unique affectation de contrôle d’accès en fonction du rôle (RBAC) au niveau de l’étendue du groupe de ressources si vos exigences de sécurité ne sont pas strictes.
Supposons que votre application se compose d’un service d’application, d’insights d’application et d’une base de données SQL déployée sur un unique groupe de ressources. Votre organisation dispose d’équipes distinctes pour la gestion du calcul, des bases de données et des applications web. Si la stratégie de sécurité de votre organisation nécessite un RBAC granulaire, il est nécessaire d’étendre les autorisations à l’étendue de la ressource plutôt qu’à l’étendue du groupe de ressources.
Il est possible avec le temps que des ressources non liées à l’application soient déployées sur le même groupe de ressources. Par exemple, un collègue de votre choix déploie un nouveau Azure Key Vault et choisit accidentellement le groupe de ressources incorrect lors du déploiement. Ce scénario peut complexifier la détermination des ressources appartenant à l’application et occasionner des problèmes comme la suppression accidentelle d’une ressource critique.
Application avec plusieurs groupes de ressources
Que se passe-t-il lorsque votre application est mise à l’échelle jusqu’à nécessiter une modification ? Il peut être nécessaire de prendre des parties de votre application et de les décomposer en groupes de ressources distincts pour simplifier les contrôles de sécurité. Par exemple, vous pouvez placer toutes les ressources de calcul dans le groupe de ressources de calcul, les ressources d’application dans le groupe de ressources d’application et toutes les bases de données dans le groupe de ressources de bases de données.
Ce modèle vous permet d’étendre les autorisations des équipes de calcul, d’application et de bases de données à leurs groupes de ressources adéquats. Bien que cette pratique puisse résoudre un problème, vous avez introduit une gestion décentralisée. La plupart des déploiements dans Azure étant étendus au groupe de ressources, vous n’avez plus la possibilité de gérer les ressources en tant qu’unité simple.
Si les ressources d’application sont déployées sur des groupes de ressources distincts, il peut être difficile d’identifier les ressources faisant partie de l’application. Vous pouvez utiliser des balises Azure pour identifier les ressources d’une application, mais il peut exister une ressource incorrectement étiquetée.
Les opérations de déploiement doivent peut-être être effectuées plusieurs fois dans le modèle à plusieurs groupes de ressources. Lorsque vous déployez des ressources, selon votre méthode de déploiement, il peut être nécessaire d’exécuter plusieurs commandes de déploiement. La plupart des déploiements dans Azure sont étendus au groupe de ressources. Il est donc nécessaire de déployer au préalable vos ressources réseau, puis de vos ressources d’application. Il en va de même pour les opérations de suppression. Si vous devez supprimer tous les groupes de ressources liés à l’application, vous allez peut-être devoir exécuter plusieurs opérations de suppression.
Entrer les piles de déploiement
Les piles de déploiement changent votre approche concernant l’organisation des ressources entre les groupes de ressources et les abonnements. Une pile de déploiement vous permet de regrouper toutes les ressources qui composent votre application, quel que soit leur emplacement dans votre hiérarchie organisationnelle de ressources Azure. Vous pouvez les gérer en tant qu’unité simple. Avec les piles de déploiement, vous pouvez effectuer des opérations de cycle de vie sur la collection des ressources qui composent la pile.
Considérez les piles de déploiement comme une série de pointeurs regroupant les ressources de votre application en une unité simple. Les piles de déploiement peuvent être créées à différentes étendues, comme les groupes de ressources, les abonnements et les groupes d’administration.
Prenons l’exemple ci-dessus. En déployant votre application et ses ressources avec une pile unique, délimitée au niveau de l’abonnement et entre les groupes de ressources, vous pouvez désormais gérer l’application en tant qu’unité simple. Chaque groupe de ressources et ses ressources sont gérés par la pile.
Utilisation des piles de déploiement
Quelles opérations peuvent être effectuées sur les piles de déploiement ? Vous pouvez créer, lister, mettre à jour et supprimer des piles de déploiement. Pour les ressources, vous pouvez afficher les ressources dans la pile, ajouter et supprimer des ressources dans la pile, mais également protéger la pile et ses ressources contre la suppression.
La création et le déploiement d’une pile de déploiement et de ses ressources sont presque identiques à un déploiement Azure standard. Ils se servent des mêmes modèles JSON ARM, fichiers Bicep ou spécifications de modèle. Par exemple :
La commande Azure CLI pour déployer un fichier Bicep dans un groupe de ressources est la suivante :
az deployment group create \
--resource-group rg-depositsApplication \
--template-file ./main.bicep
La commande Azure CLI pour créer une pile de déploiement dans l’étendue du groupe de ressources est la suivante :
az stack group create \
--name stack-deposits \
--resource-group rg-depositsApplication \
--template-file ./main.bicep \
--action-on-unmanage detachAll \
--deny-settings-mode none
Les piles de déploiement permettent un nettoyage efficace de l’environnement. Les piles de déploiement vous permettent de supprimer la pile et toutes ses ressources au moyen d’un unique appel d’API, sans avoir à comprendre les dépendances. Cette fonctionnalité facilite la suppression des ressources d’une manière fiable, ce qui améliore la vitesse de suppression des ressources. Par exemple :
La commande Azure CLI pour supprimer une pile de déploiement (et ses ressources) dans l’étendue du groupe de ressources est la suivante :
az stack group delete \
--name stack-deposits \
--resource-group rg-depositsApplication \
--action-on-unmanage detachAll
Remarque
Vous pouvez déjà utiliser des déploiements en mode complet dans le cadre d’une stratégie de déploiement existante. Si vous le faites, envisagez que les piles de déploiement constituent l’évolution suivante, ainsi qu’une option plus sûre.
Ressources managées
Lorsque vous envoyez un fichier Bicep, un modèle ARM JSON ou une spécification de modèle à une pile de déploiement, la pile devient responsable de la gestion des ressources décrites dans le fichier. Les ressources gérées par la pile sont appelées ressources managées, mais ces ressources sont toujours modifiées au travers des fichiers d’origine du modèle.
Si une ressource ne doit plus être gérée par la pile de déploiement, vous pouvez modifier la pile pour retirer la ressource. L’action sur le comportement non managé d’une pile de déploiement détermine ce qui arrive à une ressource supprimée de la définition de la pile de déploiement. Ce comportement, abordé plus loin dans la leçon, détermine si une ressource, un groupe de ressources ou des groupes d’administration sont détachés ou supprimés de la pile.
Paramètres de refus
En outre, vous pouvez configurer un « paramètre de refus » qui empêchent les modifications non autorisées sur la pile et ses ressources. Ces affectations de refus sont personnalisables. Vous pouvez définir le mode sur aucun indicateur, refuser la suppression ou refuser l’écriture et la suppression, ce qui peut ressembler aux verrous Azure. En outre, vous pouvez exclure des actions ou des principaux de service spécifiques des affectations de refus. Envisagez les paramètres de refus comme une couche supplémentaire de protection contre les modifications et suppressions accidentelles.