Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Beispiel 1: Erstellen von über- und untergeordneten Runbooks
Das folgende Beispiel erläutert, wie Sie zwei Runbooks erstellen, die getaggte Gruppen von Amazon Elastic Compute Cloud (Amazon EC2)-Instances stufenweise patchen. Diese Runbooks werden in einer Untergeordnet–Übergeordnet-Beziehung mit dem übergeordneten Runbook verwendet, das verwendet wird, um eine Kurssteuerungsautomatisierung des untergeordneten Runbooks zu initiieren. Weitere Informationen über die Ratenregelung-Automatisierungen finden Sie unter Automatisierte Abläufe in großem Umfang ausführen. Weitere Informationen zu den hier verwendeten Automation-Aktionen finden Sie unter Systems Manager Automation Aktionen-Referenz.
Erstellen des untergeordneten Runbooks
In diesem Beispiel-Runbook wird das folgende Szenario behandelt. Emily ist Systemingenieurin bei AnyCompany Consultants, LLC. Sie muss Patches für Gruppen von Amazon Elastic Compute Cloud (Amazon EC2)-Instances konfigurieren, die primäre und sekundäre Datenbanken hosten. Anwendungen greifen 24 Stunden am Tag auf diese Datenbanken zu, sodass eine der Datenbankinstances immer verfügbar sein muss.
Sie entscheidet, dass das Patchen der Instances stufenweise der beste Ansatz ist. Die primäre Gruppe von Datenbankinstances wird zuerst gepatcht, gefolgt von der sekundären Gruppe von Datenbankinstances. Um zusätzliche Kosten zu vermeiden, indem Instances ausgeführt werden, die zuvor gestoppt wurden, möchte Emily außerdem, dass die gepatchten Instances in ihren ursprünglichen Zustand zurückversetzt werden, bevor das Patchen stattgefunden hat.
Emily identifiziert die primären und sekundären Gruppen von Datenbankinstances anhand der Tags, die den Instances zugeordnet sind. Sie beschließt, ein übergeordnetes Runbook zu erstellen, das eine Automatisierung der Ratenkontrolle eines untergeordneten Runbooks startet. Auf diese Weise kann sie die Tags ausrichten, die mit den primären und sekundären Gruppen von Datenbank-Instances verknüpft sind, und die Parallelität der untergeordneten Automatisierungen verwalten. Nachdem sie die verfügbaren Systems Manager (SSM)-Dokumente zum Patchen überprüft hat, wählt sie das AWS-RunPatchBaseline
-Document. Mithilfe dieses SSM-Dokuments können ihre Kollegen die zugehörigen Patch-Compliance-Informationen überprüfen, nachdem der Patch-Vorgang abgeschlossen ist.
Um mit der Erstellung ihrer Runbook-Inhalte zu beginnen, überprüft Emily die verfügbaren Automatisierungsaktionen und beginnt mit der Erstellung des Inhalts für das untergeordnete Runbook wie folgt:
-
Zunächst stellt sie Werte für das Schema und die Beschreibung des Runbooks bereit und definiert die Eingabeparameter für das untergeordnete Runbook.
Durch die Verwendung des
AutomationAssumeRole
-Parameters können Emily und ihre Kollegen eine vorhandene IAM-Rolle verwenden, die der Automatisierung erlaubt, die Aktionen im Runbook für sie auszuführen. Emily verwendet dasInstanceId
-Parameter, um die Instance zu bestimmen, die gepatcht werden soll. Optional können dieOperation
-,RebootOption
- , undSnapshotId
-Parameter verwendet werden, um Werte für Dokumentparameter fürAWS-RunPatchBaseline
bereitzustellen. Um zu verhindern, dass für diese Dokumentparameter ungültige Werte bereitgestellt werden, definiert sie dieallowedValues
nach Bedarf. -
Wenn die Elemente der obersten Ebene definiert sind, arbeitet Emily mit der Erstellung der Aktionen, welche die
mainSteps
des Runbooks melden. Der erste Schritt gibt den aktuellen Status der Ziel-Instance aus, die imInstanceId
-Eingabeparameter mit deraws:executeAwsApi
-Aktion angegeben ist. Die Ausgabe dieser Aktion wird in späteren Aktionen verwendet. -
Anstatt den ursprünglichen Zustand jeder Instance, die gepatcht werden muss, manuell zu starten und zu verfolgen, verwendet Emily die Ausgabe der vorherigen Aktion, um die Automatisierung basierend auf dem Status der Ziel-Instance zu verzweigen. Auf diese Weise kann die Automatisierung verschiedene Schritte ausführen, abhängig von den Bedingungen, die in der
aws:branch
-Aktion angegeben sind und verbessert die Gesamteffizienz der Automatisierung ohne manuellen Eingriff.Wenn der Instance-Status bereits
running
ist, schreitet die Automatisierung mit dem Patchen der Instance mit demAWS-RunPatchBaseline
-Dokument unter Verwendung deraws:runCommand
-Aktion fort.Wenn der Instancestatus
stopping
ist, fragt die Automatisierung ab, ob die Instance den Statusstopped
mit der Aktionaws:waitForAwsResourceProperty
erreicht, startet die Instance mit der AktionexecuteAwsApi
und fragt die Instance ab, um den Statusrunning
zu erreichen, bevor die Instance gepatcht wird.Wenn der Status der Instance
stopped
ist, startet die Automatisierung die Instance und fragt die Instance ab, einenrunning
-Status vor dem Patchen der Instance unter Verwendung der gleichen Aktionen zu erreichen. -
Nach Abschluss des Patching-Vorgangs möchte Emily, dass die Automatisierung die Ziel-Instance in denselben Zustand versetzt, in dem sie sich vor dem Automatisierungsstart befanden. Sie tut dies, indem sie erneut die Ausgabe der ersten Aktion verwendet. Die Automatisierung verzweigt sich basierend auf dem ursprünglichen Zustand der Ziel-Instance unter Verwendung der
aws:branch
-Aktion. Wenn sich die Instance zuvor in einem anderen Zustand alsrunning
befand, wird die Instance angehalten. Lautet der Status der Instancerunning
, stoppt die Automatisierung. -
Emily überprüft den abgeschlossenen untergeordneten Runbook-Inhalt und erstellt das Runbook im selben AWS-Konto und der selben AWS-Region als Ziel-Instances. Jetzt ist sie bereit, mit der Erstellung des übergeordneten Runbooks fortzufahren. Im Folgenden finden Sie den vollständigen untergeordneten Runbook-Inhalt.
Weitere Informationen zu den hier verwendeten Automation-Aktionen finden Sie unter Systems Manager Automation Aktionen-Referenz.
Erstellen des übergeordneten Runbooks
In diesem Beispiel-Runbook wird das Szenario fortgesetzt, das im vorherigen Abschnitt beschrieben wird. Nachdem Emily nun das untergeordnete Runbook erstellt hat, beginnt sie mit der Erstellung des Inhalts für das übergeordnete Runbook wie folgt:
-
Zunächst stellt sie Werte für das Schema und die Beschreibung des Runbooks bereit und definiert die Eingabeparameter für das übergeordnete Runbook.
Durch die Verwendung des
AutomationAssumeRole
-Parameters können Emily und ihre Kollegen eine vorhandene IAM-Rolle verwenden, die der Automatisierung erlaubt, die Aktionen im Runbook für sie auszuführen. Emily verwendet diePatchGroupPrimaryKey
- undPatchGroupPrimaryValue
-Parameter, um das Tag anzugeben, das mit der primären Gruppe von Datenbankinstances verknüpft ist, die gepatcht werden sollen. Sie verwendet denPatchGroupSecondaryKey
- undPatchGroupSecondaryValue
-Parameter, um das Tag anzugeben, das mit der sekundären Gruppe von Datenbankinstances verknüpft ist, die gepatcht werden sollen. -
Wenn die Elemente der obersten Ebene definiert sind, arbeitet Emily mit der Erstellung der Aktionen, welche die
mainSteps
des Runbooks melden.Bei der ersten Aktion wird eine Ratensteuerungsautomatisierung mit dem soeben erstellten untergeordneten Runbook gestartet, das Instances betrifft, die mit dem Tag verknüpft sind, das in den
PatchGroupPrimaryKey
- undPatchGroupPrimaryValue
-Eingabeparametern angegeben ist. Sie verwendet die Werte, die den Eingabeparametern zur Verfügung gestellt werden, um den Schlüssel und den Wert des Tags anzugeben, welcher der primären Gruppe von Datenbankinstances zugeordnet ist, die sie patchen möchte.Nach der Fertigstellung der ersten Automatisierung, startet die zweite Aktion eine andere Ratensteuerungsautomatisierung unter Verwendung des untergeordneten Runbooks, das Instances betrifft, die mit dem Tag verknüpft sind, das in den
PatchGroupSecondaryKey
- undPatchGroupSecondaryValue
-Eingabeparametern angegeben ist. Sie verwendet die Werte, die den Eingabeparametern zur Verfügung gestellt werden, um den Schlüssel und den Wert des Tags anzugeben, welcher der sekundären Gruppe von Datenbankinstances zugeordnet ist, die sie patchen möchte. -
Emily überprüft den abgeschlossenen übergeordneten Runbook-Inhalt und erstellt das Runbook im selben AWS-Konto und der selben AWS-Region als Ziel-Instances. Jetzt ist sie bereit, ihre Runbooks zu testen, um sicherzustellen, dass die Automatisierung wie gewünscht funktioniert, bevor sie in ihre Produktionsumgebung implementiert werden. Im Folgenden finden Sie den vollständigen übergeordneten Runbook-Inhalt.
Weitere Informationen zu den hier verwendeten Automation-Aktionen finden Sie unter Systems Manager Automation Aktionen-Referenz.