Partage via

Automation

  • Article

Dans l’infrastructure cloud définie par logiciel, les équipes utilisent différents outils et techniques pour provisionner, configurer et gérer l’infrastructure. À mesure que vos équipes évoluent et grandissent, elles peuvent passer de portails et d’efforts manuels à l’utilisation de code et de l’automatisation pour approvisionner, configurer et gérer l’infrastructure et les services.

Considérations relatives à l’automatisation de la plateforme

  • L’implémentation de la méthodologie Tout en tant que code (EaC) permet à vos équipes de bénéficier d’avantages clés, de créer une culture de développement forte et de permettre à tous les membres de chaque équipe d’examiner comment et quelles ressources sont déployées. L’approche EaC aide également vos équipes de plateforme à adopter des pratiques de développement clés qui améliorent leur agilité et leur efficacité. Vos équipes peuvent suivre les modifications et contrôler celles qui passent en production en hébergeant le code dans des référentiels et en utilisant des systèmes de contrôle de version pour les gérer.
  • Les équipes peuvent suivre le principe des 4 yeux et utiliser la programmation pair à pair ou l’évaluation par les pairs pour s’assurer que les modifications du code ne sont jamais apportées sans vérification. La programmation pair à pair et l’évaluation par les pairs améliorent la qualité du code, permettent aux équipes de partager la responsabilité des modifications et d’accroître les connaissances de l’équipe sur ce qui est convenu et déployé. La révision du code est un excellent moyen pour les membres de l’équipe d’apprendre de nouvelles techniques et méthodes pour le codage et l’automatisation.
  • Les équipes doivent utiliser des systèmes de contrôle de version comme Git, ainsi que des référentiels Git, pour appliquer l’évaluation par les pairs. Les référentiels Git permettent à vos équipes de définir les branches importantes et de les protéger avec des stratégies de branche. Vous pouvez utiliser la stratégie pour exiger que les modifications de code sur ces branches répondent à certains critères, comme un nombre minimal d’approbations des membres de l’équipe, avant de pouvoir les fusionner dans une branche protégée.
  • Les équipes doivent connecter la méthodologie EaC et le processus d’évaluation des modifications avec un processus d’intégration continue et de livraison continue (CI/CD). Chaque modification de code doit déclencher automatiquement un processus CI qui exécute des déploiements statiques d’analyse du code, de validation et de test. L’intégration continue garantit que les développeurs vérifient leur code tôt (souvent appelé échec rapide ou test shift-left) pour les erreurs susceptibles de provoquer des problèmes futurs. Selon la stratégie de branche utilisée par votre équipe, les modifications apportées à toute branche importante doivent déclencher le déploiement dans différents environnements. Une fois les modifications approuvées et fusionnées dans main, le processus CD déploie ces modifications en production. Ce système de gestion du code fournit à votre équipe une source de vérité unique pour ce qui s’exécute dans chaque environnement.
  • Pour vous assurer que votre plateforme est entièrement auto-guérie et fournit un libre-service pour vos équipes de charge de travail, votre équipe de plateforme doit travailler pour automatiser tout (ce qu’on appelle souvent Automatisation extrême) : approvisionnement, configuration et gestion des plateformes, et approvisionnement des abonnements de zone d’atterrissage pour les équipes de charge de travail. L’automatisation extrême permet à votre équipe de plateforme de se concentrer sur la valeur plutôt que sur le déploiement, la configuration et la gestion de votre plateforme. L’automatisation extrême crée également un cycle d’auto-amélioration qui donne à votre équipe plus de temps pour créer plus d’automatisation.
  • À mesure que vos équipes de plateforme automatisent les activités opérationnelles et réduisent l’intervention humaine, elles doivent se concentrer sur les tâches importantes qui favorisent et accélèrent l’innovation de l’équipe de charge de travail sur Azure. Pour ce faire, votre équipe de plateforme doit effectuer une itération à travers plusieurs cycles de création et de développement à mesure qu’elle met en place les outils, scripts et améliorations des fonctionnalités de votre plateforme.
  • Il existe plusieurs options disponibles pour aider votre équipe à bien démarrer avec son déploiement de zone d’atterrissage Azure. Ces options dépendent des capacités actuelles de l’équipe et peuvent évoluer à mesure que votre équipe change. Plus précisément, pour le déploiement de plateformes, vous pouvez choisir entre des expériences basées sur le Portail, Bicep ou Terraform, en fonction respectivement des compétences IaC et des préférences d’outils de Teams.
    • Les nouvelles et émergentes plateforme d’équipes, commençant encore à être connus comme Infrastructure en tant que code (IaC) et qui sont plus familiarisées avec l’utilisation d’un portail pour déployer et gérer des ressources, peuvent utiliser l’accélérateur de zone d’atterrissage Azure pour démarrer, ce qui prend en charge les équipes utilisant toujours une approche ClickOps. ClickOps est le processus d’approvisionnement, de configuration et de gestion des ressources en cliquant sur des portails, des consoles de gestion et des assistants. Cet accélérateur permet à votre équipe d’utiliser le portail comme outil de déploiement initial et, à mesure que la maturité de l’ingénierie de la plateforme augmente progressivement, d’utiliser davantage Azure CLI, PowerShell ou IaC.
    • La solution AzOps permet aux équipes de faire évoluer leurs pratiques d’automatisation et de gestion de la plateforme de ClickOps pour les rendre compatibles DevOps. Votre équipe peut passer de l’utilisation de son compte personnel à l’utilisation des principes et pratiques DevOps en s’appuyant uniquement sur CI/CD avec AzOps et IaC. AzOps permet à votre équipe d’apporter sa propre architecture, d’utiliser l’architecture déployée par l’accélérateur de zone d’atterrissage du Portail Azure (après le déploiement initial basé sur le portail, car l’intégration d’AzOps ne fait pas partie de l’expérience du Portail ALZ), d’intégrer un déploiement brownfield ou d’utiliser des modèles personnalisés (Bicep ou ARM) pour créer et rendre votre plateforme opérationnelle.
    • Les équipes de plateforme disposant de compétences et de capacités établies peuvent adopter une approche codifiée qui suit les principes et pratiques DevOps. Votre équipe doit se baser fortement sur les pratiques de développement IaC et modernes, en cessant l’utilisation de l’accès Azure sur leurs comptes personnels pour exécuter à la place toutes les opérations via votre pipeline CI/CD. Votre équipe doit utiliser des accélérateurs basés sur IaC, comme ALZ-Bicep ou le Module Terraform des zones d’atterrissage Azure afin d’accélérer cette transition.
  • Les accélérateurs basés sur IaC ont une étendue de gestion limitée. Les nouvelles versions offrent davantage de fonctionnalités et une meilleure capacité de gestion des ressources. Si vous utilisez un accélérateur, votre équipe doit envisager une approche en couches qui commence par un accélérateur, puis ajoute une couche d’automatisation. La couche d’automatisation fournit des fonctionnalités dont votre équipe a besoin pour prendre entièrement en charge vos équipes de charge de travail avec des fonctionnalités de plateforme, comme le déploiement de contrôleur de domaine pour les applications héritées.
  • À mesure que votre équipe de plateforme passe à une approche DevOps, elle doit établir un processus de gestion des correctifs d’urgence. Ils peuvent utiliser des autorisations éligibles Privileged Identity Management (PIM) pour demander l’accès pour effectuer des correctifs et les ramener ultérieurement au code afin de limiter les dérives de configuration, ou utiliser du code pour implémenter un correctif rapide. Votre équipe doit toujours inscrire les correctifs rapides dans son backlog afin qu’elle puisse retravailler chaque correctif à un moment ultérieur et limiter sa dette technique. Une dette technique trop importante entraîne une décélération future, car un code de plateforme n’est pas entièrement examiné et ne répond pas aux directives et principes de codage en équipe.
  • Vous pouvez utiliser des stratégies Azure pour ajouter une automatisation à votre plateforme. Envisagez d’utiliser IaC pour déployer et gérer des stratégies Azure, ce qu’on appelle souvent Stratégie en tant que code (PaC). Ces stratégies vous permettent d’automatiser des activités comme la collecte de journaux. De nombreuses infrastructures PaC implémentent également un processus d’exemption. Prévoyez donc que vos équipes de charge de travail demandent des exemptions pour les stratégies.
  • Utilisez la « gouvernance pilotée par la stratégie » pour signaler aux équipes de charge de travail lorsqu’elles tentent de déployer des ressources qui ne répondent pas à un contrôle de sécurité. Envisagez de déployer des stratégies avec l’effet deny pour ces situations, ce qui permet à vos équipes de charge de travail de traiter également Tout en tant que code (EaC) et d’éviter les dérives de configuration où le code déclare une chose et où une stratégie modifie un paramètre au moment du déploiement. Évitez d’utiliser des effets modify, par exemple si une équipe de charge de travail déploie un compte de stockage avec supportOnlyHttpsTraffic = false défini dans son code où une stratégie modify change cela en true au moment du déploiement pour qu’elle reste conforme. Cela entraîne la dérive du code de ce qui est déployé.

Recommandation de conception d’automatisation de la plateforme

  • Suivez une approche Tout en tant que code pour une transparence et un contrôle de configuration complets de la plateforme Azure, de la documentation, du déploiement et du processus de test.
  • Utilisez la gestion de version pour gérer tous vos référentiels de code, notamment :
    • Infrastructure en tant que code
    • Stratégie en tant que code
    • Configuration sous forme de code
    • Déploiement en tant que code
    • Documentation en tant que code
  • Implémentez le principe des 4 yeux et un processus pour la programmation pair à pair ou l’évaluation par les pairs pour vous assurer que toutes les modifications de code sont examinées par votre équipe avant d’être déployées en production.
  • Adoptez une stratégie de branche pour votre équipe et définissez des stratégies de branche pour les branches que vous souhaitez protéger. Avec les stratégies de branche, les équipes doivent utiliser des demandes de tirage pour apporter des modifications de fusion.
  • Utilisez l’intégration continue et la livraison continue (CI/CD) pour automatiser les tests de code et le déploiement dans différents environnements.
  • Travaillez pour automatiser tout, comme l’approvisionnement, la configuration et la gestion de votre plateforme, et l’approvisionnement des abonnements de zone d’atterrissage pour vos équipes de charge de travail.
  • Utilisez l’un des accélérateurs disponibles qui correspondent aux capacités de votre équipe pour commencer à déployer des zones d’atterrissage Azure.
  • Prévoyez d’utiliser une approche de déploiement en couches pour ajouter des fonctionnalités qui ne sont pas couvertes par un accélérateur, mais qui sont nécessaires pour prendre entièrement en charge vos équipes de charge de travail.
  • Établissez un processus d’utilisation du code pour implémenter des correctifs rapides. Inscrivez toujours des correctifs rapides dans le backlog de votre équipe afin que chaque correctif puisse être retravaillé ultérieurement et pour limiter la dette technique.
  • Utilisez l’infrastructure en tant que code pour déployer et gérer des stratégies Azure (souvent appelées « stratégies en tant que code »)
  • Implémentez un processus d’exemption pour les stratégies. Planifiez que vos équipes de charge de travail demandent des exemptions pour les stratégies et préparez-vous à débloquer les équipes si nécessaire.
  • Utilisez la « gouvernance pilotée par les stratégies » pour bloquer les équipes de charge de travail lorsqu’elles tentent de déployer des ressources qui ne répondent pas à un contrôle de sécurité. Cela permet de réduire la dérive de configuration, où le code déclare un état différent de celui qui finit par être déployé.

En savoir plus