Déployer avec confiance
 Atteindre l’état souhaité du déploiement avec prévisibilité. |
|---|
Créez une chaîne d’approvisionnement de charge de travail qui vous permet d’atteindre de manière cohérente l’objectif de prévisibilité dans tous vos environnements, dans les plateformes d’hébergement, les applications, les données et les ressources de configuration de la charge de travail. Le mécanisme de déploiement doit être capable d’automatisation, de test, de supervision et de contrôle de version. Il doit être modulaire et prêt à s’exécuter à la demande. Elle ne doit pas être représentée comme un processus monolithique de bout en bout. La chaîne d’approvisionnement n’est pas nécessairement pour une exécution plus rapide, mais pour obtenir une cohérence et une auto-documentation sur plusieurs itérations.
L’équipe de charge de travail est responsable de la chaîne d’approvisionnement, car elle est liée à sa propre charge de travail.
Exemple de scénario
Contoso Manufacturing a développé une application Java utilisée pour surveiller et optimiser ses processus de fabrication. La charge de travail a récemment été migrée vers Azure et s’exécute désormais sur Azure Spring Apps, Azure Database pour MySQL et Azure IoT Hub.
Déployer l’infrastructure par le biais du code
Utilisez l’infrastructure en tant que code (IaC) pour définir les aspects reproductibles de la chaîne d’approvisionnement prêts pour la production. Préférer les approches déclaratives aux méthodes impératives.
Les technologies IaC déclaratives sont conçues avec automatisation et réutilisation à l’esprit. Vous pouvez décharger les déploiements d’infrastructure des individus en outils et obtenir une qualité cohérente.
Du point de vue de l’infrastructure, le fait d’avoir moins de choix technologiques supprime la variance des outils et facilite la détection de la dérive de configuration. La maintenance sera également plus facile. Si vous alignez les choix avec l’ensemble de compétences existant de l’équipe, l’équipe peut facilement les adopter.
Problématique de Contoso
- La version locale de la charge de travail a utilisé une combinaison de scripts et d’étapes manuelles pour générer l’infrastructure et déployer l’application dans les environnements. Au début du processus de migration Azure, l’équipe a apporté des modifications aux scripts impératifs existants pour cibler la nouvelle plateforme afin qu’elle puisse réutiliser autant que possible la base de code Automation existante. Cette approche a également été prise en raison d’un manque d’expertise avec les technologies Azure et IaC comme Bicep.
- Au fur et à mesure que la migration a progressé et que l’équipe s’est familiarisée avec la plateforme, ils sont devenus convaincus que l’utilisation d’une approche IaC avec Bicep allait être une meilleure solution à long terme.
Application de l’approche et résultats
- En l’absence de connaissances internes, l’équipe a conclu un contrat pour migrer et étendre les scripts d’automatisation du déploiement pour la charge de travail aux entrepreneurs expérimentés, qui ont travaillé avec l’équipe de développement pendant les phases initiales du projet, tout en fournissant un transfert de connaissances au reste de l’équipe.
- L’implémentation bicep résultante offre un moyen plus fiable, gérable et efficace d’approvisionner l’infrastructure dans Azure. Le code est désormais plus lisible et gérable, avec une prise en charge des outils exceptionnelle dans VSCode. Il est également entièrement idempotent et simplifie la gestion de l’état, qu’ils n’ont jamais pu accomplir pleinement avec la version précédente/impérative.
Traitez votre iaC de la même façon que votre code d’application
Suivez les recommandations logicielles pour le développement et la maintenance IaC : Modulariser en modération, éviter des abstractions personnalisées ou à faible valeur et suivre une approche en couches pour refléter différents cycles de vie. Formez des couches fondamentales où les couches inférieures restent constantes et les couches supérieures changent selon les besoins.
Les artefacts de déploiement, tels que les fichiers binaires d’application, les modèles IaC et les paramètres, font partie de la surface d’attaque. Appliquez des garanties, telles que la gestion des secrets, le contrôle d’accès et d’autres principes du pilier Sécurité.
Les artefacts connaissent le même niveau de rigueur d’ingénierie que le code d’application. Les contrôles de qualité par le biais de révisions d’homologues et de tests vous donnent confiance en déploiement.
Une approche en couches facilite la maintenance et crée des limites qui établissent des lignes claires de responsabilité.
L’ajout de contrôles de sécurité aux artefacts permet de renforcer le système pendant le processus de déploiement.
Problématique de Contoso
- L’équipe du projet avait un budget généreux au début de l’effort de migration, de sorte qu’elle a engagé des entrepreneurs très expérimentés qui ont fourni une haute qualité et dans un court délai. Les sous-traitants ont utilisé un dépôt distinct pour leur développement, et ce dépôt n’a pas été régulièrement audité pour la sécurité alors que le dépôt de code d’application principal est.
- L’équipe est prête à publier une nouvelle conception majeure de la solution, et le code de déploiement a besoin de modifications importantes. En raison d’une pénurie de ressources de développement, le dernier lot de modifications est effectué par deux stagiaires. Lorsqu’un des développeurs principaux de l’équipe est appelé pour aider les stagiaires, il remarque plusieurs validations dans le référentiel qui ne sont pas conformes aux normes de développement de l’équipe’, notamment avoir des secrets d’application tels que des clés API codées en dur dans le codebase.
Application de l’approche et résultats
- L’équipe décide de déplacer la base de code de build et de déploiement vers le même référentiel utilisé pour le code d’application et de commencer à appliquer le même niveau de rigueur d’ingénierie que d’autres domaines de la base de code. Le code est apporté aux normes d’équipe avant la première validation, les secrets d’application sont supprimés, et tous les autres standards et outils de qualité de l’équipe sont appliqués à celui-ci.
- Par conséquent, l’équipe a sécurisé cette section de la base de code tout en augmentant la qualité du code. À l’avenir, les modifications apportées à cette zone de codebase suivront les mêmes normes et tireront parti des mêmes outils utilisés pour la base de code d’application principale, notamment les révisions de code homologues et l’analyse automatisée du code avec des outils de qualité et de sécurité.
Normaliser les déploiements sur un seul manifeste
Développez un manifeste de déploiement commun utilisé dans tous les environnements. Utilisez ce manifeste comme mécanisme par défaut pour les projets greenfield, les mises à jour de charge de travail incrémentielles ou la récupération d’urgence.
L’application de cette approche vous permettra de supprimer la surcharge liée à la maintenance de plusieurs ressources.
En cas de sinistre, la récupération sera rapide et fiable, car vous pouvez déployer un manifeste essayé et testé au lieu de créer un environnement improvisé.
Problématique de Contoso
- Contoso Manufacturing utilise un pipeline entièrement automatisé pour déployer l’infrastructure, le code d’application et les modifications de configuration apportées à l’environnement de développement et de production. L’application est configurée pour être hautement disponible dans une seule région. La plupart des composants d’application sont sans état, à l’exception de la base de données MySQL. La base de données est sauvegardée comme dictée par le RTO/RPO établi et la sauvegarde est répliquée dans une région secondaire.
- Si une défaillance majeure ou catastrophique se produit dans la région primaire, l’équipe prévoit de créer un nouvel environnement pour héberger l’application dans la région secondaire. Pendant une exploration planifiée pour tester les procédures de récupération d’urgence, les scripts de déploiement échouent lors de la tentative de recréation de l’environnement dans la région secondaire en raison de l’absence de disponibilité de plusieurs ressources et d’autres limitations de service.
Application de l’approche et résultats
- L’équipe atténue les problèmes rencontrés lors de la tentative d’approvisionnement dans la région secondaire en remplaçant l’utilisation de certaines ressources par des références SKU équivalentes disponibles dans les deux régions et en rendant certaines options configurables afin qu’une valeur différente, mais valide, puisse être utilisée dans la base de données secondaire.
- L’exercice a accru la confiance de l’équipe dans sa capacité à récupérer des défaillances majeures de l’infrastructure.