Self-healing StackSets auf Unternehmensebene

Die folgenden Voraussetzungen sind notwendig, um den Inhalt dieses Beitrags zu verstehen:

• Zwei existierende AWS Accounts
• Einige AWS StackSets

Die folgende Architektur zeigt die gesamte Lösung der Self Healing StackSets:

Abbildung 1: Architektur einer vollautomatischen Self Healing Lösung mit Integration in Confluence

Die Lösung benötigt eine JSON-Datei im AWS-Parameter-Store. Am einfachsten ist es, diese automatisch auf Basis der StackSet-Konfigurationen und der dort vergebenen Tags zu erstellen. Darauf gehen wir im nächsten Abschnitt des Artikels StackSet-Konfiguration automatisch erstellen Parameter Store näher ein. Im Folgenden beschreiben wir, welche Tags wir in unser StackSet eingeführt haben und wofür wir diese Tags benötigen.

⚠️ AWS-Tags erlauben keine Kommas im Wert, daher ":" als Trennzeichen für Arrays

Die automatische Generierung der Stackset-Konfiguration über JSON im ParameterStore ist ein vielseitiges Hilfsmittel:

• Die manuelle Konfiguration eines JSON-Dokuments entfällt
• Sicherstellen, dass die Account-Automaten wissen, was sie in welcher Reihenfolge einsetzen sollen
• Unterstützung der selbstheilenden StepFunction über die zu erwartende Einrichtung der Member-Accounts

Der für diese Aufgabe zuständige Lambda wird über eine Events-Rule aufgerufen:
Immer dann, wenn eine Stackset-Operation mit dem Status "succeeded" abgeschlossen wurde.
Das liegt daran, dass die Tags auf einem Stackset Teil des Stackset sind, nicht zusätzliche Elemente, die ein Stackset beschreiben, daher führt eine Änderung der Tags immer zu einer Stackset-Update-Operation.

In Bezug auf die Informatik ist Lambda recht interessant, da das primäre Problem darin bestand, einen nicht gewichteten Baum auf der Grundlage der Tags "dependson" und "antidependson" zu erstellen und dann eine geordnete eindimensionale Liste zu kompilieren, wie beim guten alten "travelling salesmen"-Problem.

AWS Step Functions ist ein Cloud-Service, mit dem ihr die Komponenten von verteilten Anwendungen und Microservices mithilfe visueller Workflows koordinieren können. Damit könnt ihr die Ausführung komplexer Prozesse und Aufgaben über mehrere AWS-Services hinweg erstellen und automatisieren, indem ihr eine visuelle Schnittstelle zur Definition und Ausführung eures Workflows verwendet. Da die Self Healing Solutions einen komplexen Workflow benötigen, haben wir uns entschieden, Step Functions für diesen Usecase zu verwenden. Im Folgenden erklären wir Ihnen den Workflow der Selbstheilung.

Abbildung 2: StepFunction Workflow

Während der Entwicklung der Lösung stießen wir auf mehrere Einschränkungen. Hier sind unsere Erkenntnisse:

🚨 StackSets Instanzoperationen: Die maximale Anzahl von Stack-Instanzen über alle StackSets hinweg, auf denen ihr in jeder Region gleichzeitig Operationen ausführen könnt, ist pro Administratorkonto auf 10.000 Operationen begrenzt.

✅ Wir haben einen Zähler implementiert, um die laufenden StackSets-Operationen zu zählen, außerdem fangen wir auch die Ausnahme von CloudFormation ab und warten einige Sekunden, um die Operation erneut zu versuchen.

🚨 Parameter Overwrites Caching: Beim Entfernen einer gedrifteten StackSet-Instanz mit Parameter Overwrite gehen die einzelnen Parameter der Instanz verloren.

✅ Vor dem Löschen der gedrifteten StackSet Instance werden die Parameter Overwrites gecached und die StackSet Instance nach erfolgreichem Löschen wieder mit den gecachten Parameter Overwrites bereitgestellt.

🚨 AWS Step Functions Payload Größe: AWS Step Functions unterstützt Payload-Größen bis zu 256KB. Für unsere Lösung benötigen wir mehr Payloads zwischen den States, insbesondere wenn wir unser Log oder die gleichzeitigen Parameter Overwrites pro StackSet weitergeben wollen.

✅ Wir speichern unsere Zustände in einem S3-Bucket, um den Zustand zu übergeben. Am Ende der Ausführung löschen wir den Status aus S3, um die nächste Step Function Ausführung nicht mit einem falschen Status zu beeinflussen.

Nach jeder Ausführung der StackSet Health StepFunction möchten wir unser GAS-Team über die während des vorherigen Laufs durchgeführten Aktionen informieren. Daher haben wir eine Teams-Benachrichtigung implementiert, die eine Statusaktualisierung, einen Link zum generierten Dashboard und einen Link zur Protokolldatei enthält.

Der folgende Screenshot veranschaulicht ein Beispiel für eine Teams-Benachrichtigung. Sie bietet einen zusammenfassenden Bericht und verweist auf das Dashboard und die Protokolldatei für weitere Details.

Abbildung 3: Status Updates über MS Teams

Unser StackSet Health Dashboard ist eine einfache HTML-Datei, die über eine Lambda-Funktion erzeugt, in S3 gespeichert und über einen CloudFrount verteilt wird. Ihr könnt dieses Dashboard in euer Confluence oder jedes andere interne Wiki integrieren. Dieses Dashboard wird über eine CloudFormation Funktion gesichert - zusätzlich könnt ihr auch eine Firewall hinzufügen, um den Zugriff auf eine bestimmte CIDR oder geographische Region zu beschränken und den Zugriff von Dritten zu verhindern. Der folgende Screenshot zeigt ein Beispiel für den Gesamtstatus von StackSet Health für eine ganze AWS-Organisation.

Abbildung 4: Dashboard