„Wir haben die Automatisierung, aber sie muss für jedes Konto separat aufgerufen werden.

Machbar, aber zeitaufwändig und fehleranfällig. Oh, und nur jemand von SRE kann das machen.“

Heute ist es für Unternehmen de facto Standard, in mehreren Regionen und mit mehreren Cloud-Konten zu operieren. Die Gründe dafür sind unterschiedlich und je nachdem, wo Sie in der Organisation sitzen, sind diese Gründe für Sie mehr oder weniger offensichtlich:

• Sicherheit : Durch konkretere Barrieren zwischen Umgebungen haben potenzielle Angreifer Zugriff auf weniger sensible Daten.

• Kostenisolierung : Durch die Segmentierung von Arbeitslasten und Projekten nach Konto können Ausgaben leichter ermittelt und begrenzt werden.

• Ressourceneigentum : Mit Konten, die bestimmten Teams gewidmet sind, kann dem Management innerhalb dieser Abteilungen mehr Autonomie gewährt werden.

• Experimente : Teams können Experimente in Cloud-Konten durchführen, die ein geringeres Risiko für das Unternehmen darstellen, da sie von Konten isoliert sind, die vertrauliche Geschäftsinformationen und Produktions-Workloads enthalten können.

Dies ist zwar keine vollständige Liste, aber sie zeigt, wie viele gute Gründe es gibt, warum ein bestimmtes Unternehmen mehrere – wenn nicht sogar zahlreiche – Cloud-Konten hat. Mehrere Cloud-Konten bieten die Vorteile des Betriebs in der Cloud: Sicherheit, Flexibilität und Geschwindigkeit.

Diese Vorteile haben jedoch ihren Preis, was die Komplexität angeht, und bringen neue Herausforderungen mit sich, wenn es um die Verwaltung von Umgebungen und den Betrieb von Workloads über mehrere Cloud-Konten hinweg geht. Insbesondere die Implementierung von Standardverfahren, die die Interaktion mit den Workloads beinhalten innerhalb Diese Umgebungen werden mühsam, wenn mehrere Regionen oder Cloud-Konten beteiligt sind.

Wie sich herausstellt, gibt es eine große Klasse von Anwendungsfällen, die diese Art der Interaktion beinhalten:

• Revision und Compliance : Es gibt zwangsläufig Zeiten, in denen alle Compute-Instanzen müssen überprüft oder untersucht werden. Einfache Beispiele hierfür können sein, herauszufinden, ob eine bestimmte Version eines Softwarepakets installiert ist oder ob ein bestimmter Benutzer oder Dienstkonto vorhanden ist.

• Konfigurationsverwaltung : Organisationen möchten Standardkonfigurationseinstellungen für Software implementieren und müssen daher Skripts oder Playbooks auf allen Compute-Instanzen ausführen.

• Reaktion auf Vorfälle : Unabhängig davon, ob sich Compute-Instanzen in mehreren Cloud-Konten befinden, wünschen sich Teams einen standardisierten Ansatz für die Diagnose oder das Einleiten von Korrekturmaßnahmen. Dies gilt insbesondere für Softwareunternehmen, die eine Option für die „verwaltete Bereitstellung“ innerhalb von ihre Kunden Cloud-Konten.

Auch hier handelt es sich nicht um eine vollständige Liste, sondern um einige der häufigsten Anwendungsfälle. Um diese Art von Aufgaben über mehrere Cloud-Konten hinweg zu automatisieren, müssen Betriebsingenieure heute entweder Skripte schreiben, die die „Orchestrierungsebene“ für die Verbindung mit jedem Cloud-Konto handhaben, oder sie rufen ihre Automatisierung (z. B. Playbooks) „manuell“ in jedem Konto separat auf. Beide Ansätze sind entweder zeitaufwändig oder fehleranfällig und können normalerweise nur von erfahrenen Ingenieuren durchgeführt werden.

Runbook Automation von PagerDuty löst dieses Problem, indem es als Self-Service- und Orchestrierungsebene über herkömmlichen Automatisierungstools dient. Insbesondere für AWS lässt sich Runbook Automation in Systems Manager (SSM) integrieren, um Befehle und Skripte über Cloud-Konten hinweg an EC2-Instanzen zu senden.

Um dies auf sichere und skalierbare Weise zu erreichen, integriert Runbook Automation zunächst ein „zentrales“ Cloud-Konto und verwendet dabei die branchenübliche Vorgehensweise, kontoübergreifende externe ID um einen SaaS-Anbieter mit einem AWS-Konto zu integrieren. Nach der Integration mit dem zentralen Konto kann Runbook Automation die Rolle übernehmen Funktion von AWS IAM zur Übernahme der IAM-Rolle in einem separate („Remote“) AWS-Konto, wo es dann Systems Manager verwendet, um Befehle und Skripte auf Ziel-EC2-Instanzen auszuführen:

Runbook Automation nutzt die native IAM-Integration zur Automatisierung über mehrere Cloud-Konten hinweg.

Derselbe Anwendungsfall kann mit Process Automation (selbst gehostet) erreicht werden, wobei die Software im Meister AWS-Konto auf EC2, ECS oder EKS. In diesem Fall Prozessautomatisierung „erbt“ die IAM-Berechtigungen die mit den Hosts verknüpft sind, auf denen es installiert ist:

Die im „Master“-Konto selbst gehostete Prozessautomatisierung erbt die IAM-Berechtigungen direkt.

Dieses Verfahren nutzt die Rolle übernehmen in einem „Remote“-Konto kann beliebig oft innerhalb eines einzigen Runbook Automation-Projekts (Arbeitsbereich) implementiert werden und bietet somit einen einfachen Ansatz für die Automatisierungsverteilung an zahlreiche AWS-Konten .

In Kombination mit den nativen Integrationen und der Self-Service-Schnittstelle von Runbook Automation können Benutzer vorab genehmigte Verfahren an Personen mit weniger technischem Fachwissen oder an solche delegieren, die keinen vollständigen Zugriff auf alle Cloud-Umgebungen haben sollten.

Durch die Implementierung von Runbook Automation zur kontenübergreifenden Orchestrierung von Tools wie AWS Systems Manager wird nicht nur Zeit gespart, sondern es können auch mehr Einzelpersonen im gesamten Unternehmen die Leistungsfähigkeit der Automatisierung nutzen.

Um diese Lösung mit Runbook Automation zu implementieren, folgen Sie den in diesem How To Artikel . Eine Demo dieser Lösung wird hier gezeigt:

Wenn Sie noch kein Runbook Automation-Konto haben, registrieren Sie sich für eine kostenlose Testversion Hier .