Service Catalog Puppet

Service Catalog Puppet est implémenté en Python à l'aide de l'API AWS Boto3. Cet outil propose plusieurs fonctionnalités puissantes pour configurer et approvisionner les produits Service Catalog. Les développeurs peuvent configurer les informations de provisionnement des produits et des portefeuilles de Service Catalog à l'aide de modèles YAML qui servent de manifestes. Les flux de travail de provisionnement de Service Catalog Puppet prennent en charge les produits qui nécessitent des processus de déploiement plus complexes que Service Catalog. Ils permettent également d'optimiser les performances afin de fournir des produits à grande échelle dans des délais serrés.

Service Catalog Puppet accède aux CloudFormation modèles de Service Catalog pour le provisionnement des produits au moment du déploiement. Il appelle CloudFormation directement au déploiement de la pile de modèles de provisionnement pour un produit et contourne les restrictions imposées par le processus de provisionnement des ensembles de piles de Service Catalog. Si le modèle de provisionnement utilise des macros pour inclure d'autres CloudFormation scripts ou utilise des CloudFormation scripts imbriqués, vous devez fournir l'accès à ces scripts dans le compte cible dans la partie d'amorçage du flux de travail de provisionnement.

Pour plus d’informations, consultez:

• Consultez la documentation et le GitHubréférentiel du Service Catalog Puppet.

• Si vous souhaitez utiliser le SDK Service Catalog Puppet pour interagir avec l'outil par programmation afin de lancer le provisionnement de produits et de portefeuilles, consultez la documentation du SDK.

• GitOpsest le mécanisme par défaut pour gérer l'environnement Service Catalog Puppet.

Service Catalog Puppet est assez facile à apprendre pour les développeurs. Il faut être familiarisé avec la mise en œuvre CloudFormation de modèles de provisionnement de produits et de modèles YAML pour implémenter des manifestes. Il existe de bons ateliers pour familiariser les nouveaux développeurs, tels que des ateliers adaptés à leur propre rythme.

Support pour le provisionnement des flux de travail

Service Catalog Puppet utilise le moteur d'orchestration de tâches Python Luigi pour implémenter des flux de travail d'amorçage et de provisionnement. Toutes les étapes de ces flux de travail sont mises en œuvre en tant que tâches de flux de travail Luigi. Pour un aperçu de Luigi et de sa comparaison avec d'autres outils de flux de travail populaires, consultez Airflow vs. Luigi vs. Argo vs. MLFlow vs. KubeFlow sur le blog Data Revenue.

Luigi permet à Service Catalog Puppet de contrôler le nombre de travailleurs associés aux tâches du flux de travail et de contrôler d'autres aspects des flux de travail, pour une meilleure évolutivité et de meilleures performances. Service Catalog Puppet fournit également un mécanisme depends_on pour gérer les dépendances entre les produits et les étapes, et pour orchestrer le provisionnement des produits. Cette fonctionnalité vous aide à implémenter et à gérer de manière opérationnelle des définitions de produits précises et des dépendances complexes.

Modes de provisionnement

Service Catalog Puppet prend en charge trois modes d'exécution : hub, spoke et async. Les trois modes fournissent des produits au sein de portefeuilles déjà définis dans Service Catalog. Ils s'appuient sur le partage des produits Service Catalog avec les comptes cibles et utilisent les rôles d'administrateur et de lancement de Service Catalog pour effectuer le provisionnement sur ces cibles. Service Catalog Puppet exécute les étapes de démarrage au sein de la même organisation en fonction des configurations de rôles fournies dans les fichiers de configuration YAML. L'outil prend également en charge le provisionnement auprès de plusieurs organisations à partir d'un seul compte hub. Dans ce scénario, le démarrage doit être effectué manuellement dans les organisations externes pour permettre à Service Catalog Puppet d'effectuer les actions de provisionnement requises dans les comptes de l'organisation externe.

Dans tous les modes de provisionnement, Service Catalog Puppet implémente le provisionnement des produits directement sans appeler le processus de provisionnement de Service Catalog. Vous pouvez configurer un manifeste de provisionnement pour utiliser les spécifications du rôle et du compte cible dans une contrainte d'ensemble de piles Service Catalog existante. Service Catalog Puppet utilise ces informations pour effectuer son propre provisionnement avec les flux de travail Luigi.

Vous pouvez définir des objectifs pour le provisionnement du portefeuille de produits sur la base d'une approche de marquage des comptes, en plus de spécifier directement OUs les comptes. Dans le cadre du provisionnement basé sur les balises de compte, un produit de portefeuille est fourni à tous les comptes qui possèdent toutes les balises du jeu de balises de provisionnement du manifeste spécifié. Par exemple, si vous souhaitez émettre un produit de portefeuille pour tous les comptes de production institutionnels des régions de l'est des États-Unis, vous pouvez spécifier les balises type:prod partition:us-east, etscope:institutional-client. Vous pouvez également déclarer des exclusions de comptes et d'unités d'organisation afin d'interdire le provisionnement de comptes OUs ou de comptes dotés des balises que vous spécifiez, ou de comptes membres des cibles spécifiées par l'unité d'organisation. Pour plus d'informations sur le balisage des comptes, consultez la documentation des outils Service Catalog.

Mode hub

En mode de provisionnement du hub, tous les flux de travail Luigi pour les comptes Spoke sont gérés à partir du compte central du hub désigné. Le compte du hub assume un rôle IAM qui lui permet d'effectuer des actions dans un compte Spoke, mais la gestion des tâches se fait depuis le compte du hub. Le compte hub attend de manière synchrone que toutes les tâches de provisionnement du compte Spoke soient terminées, avec ou sans succès. Il indique ensuite l'état final. Le mode compte hub est le mode de provisionnement le plus ancien et le plus mature. Cependant, de nombreux utilisateurs sont passés au mode de provisionnement en étoile pour améliorer la simultanéité et la rapidité du provisionnement.

Mode Spoke

En mode Spoke, le compte Hub Service Catalog lance les flux de travail Luigi à exécuter dans les comptes Spoke bootstrap désignés. Le compte hub est averti lorsque les flux de travail parlés sont terminés. Les défaillances d'un compte Spoke se répercutent sur le compte hub. Le compte hub interroge le compte Spoke pour voir s'il est terminé et pour déterminer son statut.

Le mode Spoke est le moins susceptible de nécessiter des augmentations de Service AWS quotas, car presque tout fonctionne dans des comptes Spoke distincts. Le mode Spoke offre également une simultanéité bien supérieure à celle du mode hub tout en conservant le contrôle central. Il peut améliorer la vitesse de provisionnement de 800 % par rapport au mode hub. Le mode Spoke prend en charge le chaînage des produits grâce aux DependsOn relations entre les produits, ce qui garantit qu'un produit dont on dépend a déjà été approvisionné. Un produit qui comprend des produits enchaînés peut également fournir un produit chaîné de composants. Vous pouvez également utiliser des appels de AWS Lambda fonctions spécialisés pour effectuer les étapes requises. Les défauts d'un rayon sont isolés des autres rayons.

Le mode Spoke est utilisé par les entreprises qui possèdent plus de 980 comptes dans un maximum de 7 régions. Ces entreprises sont généralement en mesure de fournir un produit à toutes les régions et à tous les comptes de leur infrastructure en une heure.

Note

Ces résultats peuvent varier en fonction de facteurs tels que l'infrastructure réseau, la charge de travail et les quotas mis en place pour les comptes hub et spoke de AWS l'organisation. Ils dépendent également des ressources du produit mises en service, de leur temps de création inhérent et de leur dépendance à l'égard d'autres ressources.

Mode asynchrone

Le mode asynchrone lance les flux de travail de provisionnement dans les comptes satellites, mais il n'attend ni ne reçoit de réponses de fin de la part des rayons.

mise en cache

Un autre mécanisme utilisé par Service Catalog Puppet pour optimiser la vitesse des flux de travail consiste à mettre en cache les tâches courantes qui représentent les étapes du flux de travail. Lorsqu'une tâche mise en cache est terminée, elle écrit sa sortie dans Amazon Simple Storage Service (Amazon S3). La prochaine fois que la tâche est appelée dans la même session avec les mêmes paramètres, Service Catalog Puppet utilise les valeurs mises en cache au lieu de réexécuter la tâche. Pour plus d'informations, consultez la section Mise en cache dans la documentation de Service Catalog Puppet.

DevSecOps support du cycle de vie

Service Catalog Puppet inclut un support pour la gestion du DevSecOps pipeline. Vous pouvez utiliser les actions des outils Service Catalog (comme illustré dans la présentation de Service Catalog Puppet) pour automatiser les tests et promouvoir les produits sur l'ensemble de vos comptes de AWS cycle de vie, y compris le compte Canary recommandé. Pour plus d'informations, consultez la section Gestion de vos environnements dans la documentation de Service Catalog Puppet.

Pour garantir que tout problème lié à une modification du produit est détecté avant une utilisation généralisée en production, Service Catalog Puppet nécessite au moins un compte Canary pour le déploiement initial. Après avoir testé la nouvelle version et gagné en confiance, vous pouvez la promouvoir sur des comptes de production autres que Canary. Si vous identifiez des problèmes, vous pouvez annuler la version et la réintroduire une fois les problèmes résolus. Lorsque vous utilisez cette approche, des problèmes de production peuvent survenir si vous publiez une version de Canary présentant un problème avec les comptes de production. Comme autre approche, vous pouvez exécuter des tests de régression complets pour chaque modification de produit avant de passer la modification à la production. Cela introduit une surcharge supplémentaire dans le processus CI/CD, mais permet d'éviter les problèmes de production. Il est de la responsabilité de l' DevSecOps administrateur de déterminer les meilleurs scénarios et approches de publication des fonctionnalités pour ses équipes de développement.

Service Catalog Puppet permet à plusieurs équipes de développer et de tester simultanément le provisionnement des solutions de produits Service Catalog. En tant que bonne pratique, un produit ne doit pas être modifié par plusieurs développeurs en même temps. Au lieu de cela, vous pouvez diviser les produits en composants plus fins pour des modifications distinctes et simultanées.

Service Catalog Puppet permet également d'automatiser les tests grâce à une instruction d'assertion qui fournit des fonctionnalités de test statique et unitaire. Vous pouvez tester les politiques de contrôle des services (SCPs) et les politiques IAM à l'aide de simulateurs de politiques. Il s'agit de end-to-end tests techniques, mais ils peuvent être utilisés dans des environnements de test d'intégration de systèmes (SIT). Pour plus d'informations, consultez les sections Utilisation de simulations de politiques et Application de politiques de contrôle de service dans la documentation Service Catalog Puppet.

Maturité, exhaustivité et support

Bien que Service Catalog Puppet ne soit pas officiellement pris en charge Service AWS, il a été largement adopté. Cet outil a été utilisé par de grandes entreprises au cours des dernières années pour fournir avec succès et de manière centralisée des produits à des centaines de comptes UO dans les délais de provisionnement souhaités. Il s'est avéré capable de fournir des produits tolérants aux pannes à grande échelle. Les utilisateurs qui rencontrent des problèmes avec Service Catalog Puppet peuvent les enregistrer dans le GitHub référentiel afin que les contributeurs à cette solution AWS Labs les résolvent.