Partager via

Automatisation

Dans l’infrastructure cloud définie par logiciel, les équipes utilisent différents outils et techniques pour approvisionner, configurer et gérer l’infrastructure. À mesure que vos équipes évoluent et évoluent, elles peuvent passer des portails et des efforts manuels à l’utilisation du 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 déverrouiller les principaux avantages, de créer une culture de développement forte et de permettre à tous les membres de chaque équipe d’inspecter comment et quelles ressources sont déployées. 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 du code dans les référentiels et à l’aide de systèmes de contrôle de version pour les gérer.
  • Les équipes peuvent suivre le principe des 4 yeux et utiliser la programmation en binôme ou révision de code entre pairs pour s'assurer que les modifications du code ne sont jamais apportées seules. La programmation des pairs et l’examen des 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.
  • Teams doit utiliser des systèmes de contrôle de version comme Git, avec des référentiels Git, pour appliquer la révision des pairs. Les dépôts Git permettent à vos équipes de définir des branches importantes et de les protéger avec des stratégies de branche. Vous pouvez utiliser la stratégie pour exiger des modifications de code sur ces branches pour répondre à certains critères, comme un nombre minimal d’approbations des membres de l’équipe, avant de pouvoir fusionner dans une branche protégée.
  • Les équipes doivent relier ensemble la méthodologie EaC et le processus d’examen 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. CI garantit que les développeurs vérifient leur code tôt (souvent appelé échouer rapidement ou test anticipé) pour détecter les erreurs susceptibles de provoquer des problèmes futurs. Selon la stratégie de branche utilisée par votre équipe, les modifications apportées à n’importe quelle 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 de CD déploie ces modifications en production. Ce système de gestion du code fournit à votre équipe une seule source de vérité pour ce qui s’exécute dans chaque environnement.
  • Pour vous assurer que votre plateforme est entièrement auto-réparatrice et fournit des services en libre-service pour vos équipes responsables de charges de travail, votre équipe de plateforme doit travailler pour tout automatiser (souvent appelé Extreme Automation) de l'approvisionnement, de la configuration et de la gestion des plateformes à la gestion d'abonnements de zones d'accueil pour les équipes responsables de charges de travail. L’automatisation extrême permet à votre équipe de plateforme de se concentrer sur la fourniture de 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’amélioration automatique 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 des tâches importantes qui permettent 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 dans plusieurs cycles de création et de développement au fur et à mesure qu’elle met en place les outils, scripts et améliorations des fonctionnalités de votre plateforme.
  • Plusieurs options sont disponibles pour aider votre équipe à prendre en main son déploiement de zone d’atterrissage Azure. Ces options dépendent des fonctionnalités actuelles de votre équipe et peuvent croître à mesure que votre équipe évolue. Plus précisément, pour Platform Deployment, vous pouvez choisir entre Portail, Bicep ou Terraform, en fonction des compétences en matière d'infrastructure en tant que code (IaC) et des préférences en matière d'outils des équipes respectives.
    • Les nouvelles équipes de plateforme émergentes qui connaissent toujours IaC et qui sont familiarisées avec l’utilisation d’un portail pour déployer et gérer des ressources peuvent utiliser l’accélérateur du portail de zone d’atterrissage Azure. Cet accélérateur prend en charge les équipes qui utilisent actuellement une approche ClickOps . ClickOps est le processus d’approvisionnement, de configuration et de gestion des ressources en cliquant sur les portails, les consoles de gestion et les Assistants. Cet accélérateur permet à votre équipe d’utiliser le portail comme outil de déploiement initial. À mesure que la maturité de l’ingénierie de plateforme augmente, votre équipe peut incorporer progressivement Azure CLI, PowerShell ou IaC.
    • 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 s'appuyer fortement sur les pratiques IaC et de développement modernes, en délaissant l'utilisation des accès Azure sur leurs comptes personnels au profit de l'exécution de toutes les opérations via votre pipeline CI/CD. Votre équipe doit utiliser des accélérateurs basés sur IaC, comme l’accélérateur IaC (Azure Landing Zone Infrastructure as Code).
  • Les accélérateurs basés sur IaC ont une étendue de gestion limitée. De nouvelles versions offrent davantage de fonctionnalités et une capacité accrue 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 Automation 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 telles que 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 les permissions éligibles de Privileged Identity Management (PIM) pour demander l’accès afin d’effectuer des correctifs et les intégrer ultérieurement au code pour limiter la dérive de configuration, ou utiliser du code pour implémenter un correctif rapide. Votre équipe doit toujours inscrire des correctifs rapides dans son backlog afin qu’elle puisse retravailler chaque correctif à un moment ultérieur et limiter sa dette technique. Trop de dettes techniques 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 d’é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, souvent appelées Stratégie en tant que code (PaC). Ces stratégies vous permettent d’automatiser des activités telles que la collecte de logs. De nombreux cadres PaC implémentent également un processus d’exemption. Prévoyez donc que vos équipes de travail demandent des exemptions de politiques.
  • 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 responsables des charges de travail de considérer tout comme du code et d’éviter la dérive de configuration, où le code déclare une chose et la politique modifie un paramètre au moment du déploiement. Évitez d'utiliser les effets de modify, par exemple si une équipe de charges de travail déploie un compte de stockage avec supportOnlyHttpsTraffic = false défini dans leur code, où une stratégie de modify modifie cela en true au moment du déploiement pour qu'il reste conforme. Cela conduit à un décalage entre le code et 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 le contrôle 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 4 yeux et un processus pour la programmation d’homologues ou la révision d’homologue 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 branchement 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 pull requests 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 fonctionnalité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 vous pouvez limiter la dette technique.
  • Utiliser l’infrastructure en tant que code pour déployer et gérer des stratégies Azure (souvent appelées stratégie en tant que code)
  • Implémentez un processus d’exemption pour les stratégies. Planifiez que vos équipes de travail demandent des exemptions des politiques et soyez prêt à débloquer les équipes si nécessaire.
  • Utilisez la « gouvernance pilotée par la stratégie » 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

  • Last updated on