« Nous avons l’automatisation, mais elle devra être invoquée séparément pour chaque compte.

C'est faisable, mais cela prend du temps et peut entraîner des erreurs. Oh, et seul un membre du service SRE peut le faire.

Il est désormais devenu de facto la norme pour les entreprises d'opérer dans de nombreuses régions et avec de nombreux comptes cloud. Les raisons de ce phénomène varient et, selon votre position dans l'entreprise, ces raisons peuvent vous sembler plus ou moins évidentes :

• Sécurité :avec des barrières plus concrètes entre les environnements, les attaquants potentiels ont accès à moins de volume de données sensibles.

• Isolation des coûts :en segmentant les charges de travail et les projets par compte, il est plus facile d'identifier et de limiter les dépenses.

• Propriété des ressources :avec des comptes dédiés à des équipes spécifiques, plus d'autonomie peut être donnée au management au sein de ces départements.

• Expériences :les équipes peuvent exécuter des expériences dans des comptes cloud qui présentent moins de risques pour l’organisation, car ils sont isolés des comptes pouvant contenir des informations commerciales sensibles et des charges de travail de production.

Bien que cette liste ne soit en aucun cas exhaustive, elle met en évidence le nombre de raisons valables pour lesquelles une entreprise donnée doit posséder plusieurs, voire de nombreux, comptes cloud. Le fait de posséder plusieurs comptes cloud permet de bénéficier des avantages du fonctionnement dans le cloud : sécurité, flexibilité et rapidité.

Mais ces avantages ont un coût en termes de complexité et introduisent de nouveaux défis en matière de gestion des environnements et d'exploitation des charges de travail sur plusieurs comptes cloud. Plus précisément, la mise en œuvre de procédures standard impliquant l'interaction avec les charges de travail dans ces environnements deviennent pénibles lorsque plusieurs régions ou comptes cloud sont impliqués.

Il s’avère qu’il existe une large classe de cas d’utilisation qui impliquent ce type d’interaction :

• Audit et conformité :inévitablement, il y a des moments où tous Les instances de calcul doivent être auditées ou étudiées. Il peut s'agir par exemple de vérifier si une version particulière d'un package logiciel est installée ou si un utilisateur ou un compte de service spécifique existe.

• Gestion de la configuration :les organisations souhaitent mettre en œuvre des paramètres de configuration standard pour les logiciels et doivent donc exécuter des scripts ou des playbooks sur toutes les instances de calcul.

• Réponse aux incidents : que les instances de calcul résident ou non dans plusieurs comptes cloud, les équipes souhaitent une approche standardisée pour obtenir des diagnostics ou invoquer des mesures correctives. Cela est particulièrement vrai pour les sociétés de logiciels qui proposent une option de « déploiement géré » au sein de leurs clients comptes cloud.

Encore une fois, cette liste n’est pas exhaustive, mais elle met en évidence certains des cas d’utilisation les plus courants. Aujourd’hui, l’automatisation de ces types de tâches sur plusieurs comptes cloud nécessite que les ingénieurs d’exploitation écrivent des scripts qui gèrent la « couche d’orchestration » pour la connexion à chaque compte cloud, ou qu’ils invoquent « manuellement » leur automatisation (par exemple, des manuels) dans chaque compte séparément. Ces deux approches prennent du temps ou sont sujettes aux erreurs et ne peuvent généralement être mises en œuvre que par des ingénieurs expérimentés.

PagerDuty's Runbook Automation résout ce problème en servant de couche d'orchestration et de libre-service sur les outils d'automatisation traditionnels. Pour AWS en particulier, Runbook Automation s'intègre à Systems Manager (SSM) pour envoyer des commandes et des scripts aux instances EC2 sur les comptes cloud.

Pour y parvenir de manière sécurisée et évolutive, Runbook Automation s'intègre d'abord à un compte cloud « central » en utilisant la pratique standard du secteur consistant à disposer d'un ID externe inter-comptes pour intégrer un fournisseur SaaS à un compte AWS. Une fois intégré au compte central, Runbook Automation peut utiliser le Assumer un rôle fonction d'AWS IAM pour adopter le rôle IAM dans un séparé Compte AWS (« distant ») où il utilise ensuite Systems Manager pour exécuter des commandes et des scripts sur les instances EC2 cibles :

Runbook Automation utilise l'intégration IAM native pour automatiser plusieurs comptes cloud.

Ce même cas d'utilisation peut être réalisé avec Process Automation (auto-hébergé), où le logiciel est installé dans le maître Compte AWS sur EC2, ECS ou EKS. Dans ce cas, L'automatisation des processus « hérite » des droits IAM qui sont associés aux hôtes sur lesquels il est installé :

L'automatisation des processus auto-hébergée dans le compte « Maître » héritera directement des droits IAM.

Cette procédure qui utilise le Assumer un rôle dans un compte « distant » peut être implémenté autant de fois que nécessaire dans un seul projet Runbook Automation (espace de travail), offrant ainsi une approche simple pour la répartition de l'automatisation vers de nombreux comptes AWS .

Associés aux intégrations natives et à l'interface en libre-service de Runbook Automation, les utilisateurs peuvent déléguer des procédures pré-approuvées à des personnes ayant moins d'expertise technique ou à celles qui ne devraient pas avoir un accès complet à tous les environnements cloud.

En mettant en œuvre Runbook Automation pour orchestrer des outils tels qu'AWS Systems Manager sur plusieurs comptes, non seulement le temps est économisé, mais davantage de personnes peuvent également exploiter la puissance de l'automatisation dans toute l'organisation.

Pour mettre en œuvre cette solution avec Runbook Automation, suivez les étapes décrites dans ce Comment rédiger un article Une démonstration de cette solution est présentée ici :

Si vous n'avez pas encore de compte Runbook Automation, inscrivez-vous pour un essai gratuit ici .