Service Catalog Puppet

Service Catalog Puppet wird mithilfe der AWS Boto3-API in Python implementiert. Dieses Tool bietet mehrere leistungsstarke Funktionen für die Konfiguration und Bereitstellung von Service Catalog-Produkten. Entwickler können die Produkt- und Portfoliobereitstellungsinformationen von Service Catalog mithilfe von YAML-Vorlagen konfigurieren, die als Manifeste dienen. Die Bereitstellungsworkflows von Service Catalog Puppet unterstützen Produkte, die komplexere Bereitstellungsprozesse erfordern als Service Catalog. Sie unterstützen auch Leistungsoptimierungen, um Produkte in großem Umfang innerhalb aggressiver Zeitfenster bereitzustellen.

Service Catalog Puppet greift bei der Bereitstellung auf die Service CloudFormation Catalog-Vorlagen für die Produktbereitstellung zu. Es ruft CloudFormation direkt auf, um den Bereitstellungsvorlagenstapel für ein Produkt bereitzustellen, und umgeht die Einschränkungen, die durch den eigenen Stackset-Bereitstellungsprozess von Service Catalog auferlegt werden. Wenn die Bereitstellungsvorlage Makros verwendet, um andere CloudFormation Skripts einzubeziehen, oder wenn sie CloudFormation verschachtelte Skripts verwendet, müssen Sie im Bootstrapping-Teil des Bereitstellungsworkflows Zugriff auf diese Skripts im Zielkonto gewähren.

Weitere Informationen:

• Weitere Informationen finden Sie in der Service Catalog Puppet-Dokumentation und im GitHubRepository.

• Wenn Sie das Service Catalog Puppet SDK verwenden möchten, um programmgesteuert mit dem Tool zu interagieren und die Produkt- und Portfoliobereitstellung zu initiieren, finden Sie weitere Informationen in der SDK-Dokumentation.

• GitOpsist der Standardmechanismus für die Verwaltung der Service Catalog Puppet-Umgebung.

Service Catalog Puppet ist für Entwickler relativ einfach zu erlernen. Es erfordert Vertrautheit mit der Implementierung von Vorlagen CloudFormation für die Produktbereitstellung und mit YAML-Vorlagen zur Implementierung von Manifesten. Es gibt gute Workshops, um neue Entwickler auf den neuesten Stand zu bringen, z. B. Workshops zum Selbststudium.

Support für Bereitstellungsworkflows

Service Catalog Puppet verwendet die Python Luigi Task Orchestration Engine, um Bootstrapping- und Bereitstellungsworkflows zu implementieren. Alle Schritte in diesen Workflows werden als Luigi-Workflow-Aufgaben implementiert. Einen Überblick über Luigi und dessen Vergleich mit anderen beliebten Workflow-Tools finden Sie unter Airflow vs. Luigi vs. Argo MLFlow vs. im Data KubeFlow Revenue-Blog.

Luigi ermöglicht es Service Catalog Puppet, die Anzahl der Mitarbeiter zu kontrollieren, die mit Workflow-Aufgaben verknüpft sind, und andere Aspekte der Workflows zu kontrollieren, um eine bessere Skalierung und Leistung zu erzielen. Service Catalog Puppet bietet auch einen depends_on-Mechanismus für die Verwaltung von Produkt- und Schrittabhängigkeiten sowie für die Orchestrierung der Produktbereitstellung. Diese Funktion unterstützt Sie bei der Implementierung und operativen Verwaltung detaillierter Produktdefinitionen und komplexer Abhängigkeiten.

Bereitstellungsmodi

Service Catalog Puppet unterstützt drei Ausführungsmodi: Hub, Spoke und Async. In allen drei Modi werden Produkte innerhalb von Portfolios bereitgestellt, die bereits im Service Catalog definiert sind. Sie verlassen sich auf die gemeinsame Nutzung von Service Catalog-Produkten für die Zielkonten und verwenden Service Catalog-Administrator- und Startrollen, um die Bereitstellung in diesen Zielen zu realisieren. Service Catalog Puppet führt die Bootstrapping-Schritte innerhalb derselben Organisation auf der Grundlage der in den YAML-Konfigurationsdateien bereitgestellten Rollenkonfigurationen durch. Das Tool unterstützt auch die Bereitstellung für mehrere Organisationen von einem einzigen Hub-Konto aus. In diesem Szenario muss das Bootstrapping in den externen Organisationen manuell durchgeführt werden, damit Service Catalog Puppet die erforderlichen Bereitstellungsaktionen in den Konten der externen Organisation durchführen kann.

In allen Bereitstellungsmodi implementiert Service Catalog Puppet die Produktbereitstellung direkt, ohne den Bereitstellungsprozess von Service Catalog aufrufen zu müssen. Sie können ein Bereitstellungsmanifest so konfigurieren, dass die Rollen- und Zielkontospezifikationen in einer vorhandenen Service Catalog-Stack-Set-Einschränkung verwendet werden. Service Catalog Puppet verwendet diese Informationen, um seine eigene Bereitstellung mit Luigi-Workflows durchzuführen.

Sie können Ziele für die Bereitstellung von Produktportfolios auf der Grundlage eines Konten-Tagging-Ansatzes definieren und Konten auch direkt angeben. OUs Bei der Bereitstellung auf Konto-Tag-Basis wird ein Portfolioprodukt für alle Konten bereitgestellt, die über alle Tags im angegebenen Tagsatz für die Manifest-Bereitstellung verfügen. Wenn Sie beispielsweise ein Portfolioprodukt für alle institutionellen Produktionskonten in den östlichen Regionen der USA ausgeben möchten, können Sie die Tagstype:prod, und angeben. partition:us-east scope:institutional-client Sie können auch Konten- und Organisationsausschlüsse festlegen, um die Bereitstellung für Konten OUs oder Konten, die über die von Ihnen angegebenen Stichwörter verfügen, oder für Konten, die Mitglieder der von der OU angegebenen Ziele sind, zu verbieten. Weitere Informationen zur Kontenkennzeichnung finden Sie in der Dokumentation zu den Service Catalog Tools.

Hub-Modus

Im Hub-Bereitstellungsmodus werden alle Luigi-Workflows für die Spoke-Konten vom dafür vorgesehenen zentralen Hub-Konto aus verwaltet. Das Hub-Konto nimmt eine IAM-Rolle an, die es ihm ermöglicht, Aktionen in einem Spoke-Konto auszuführen. Die Verwaltung der Aufgaben erfolgt jedoch vom Hub-Konto aus. Das Hub-Konto wartet synchron, bis alle Aufgaben zur Bereitstellung von Spoke-Konten entweder erfolgreich oder erfolglos abgeschlossen sind. Anschließend wird der endgültige Status gemeldet. Der Hub-Kontomodus ist der älteste und ausgereifteste Bereitstellungsmodus. Viele Benutzer sind jedoch auf den Spoke-Bereitstellungsmodus umgestiegen, um eine größere Parallelität und Geschwindigkeit der Bereitstellung zu erreichen.

Spoke-Modus

Im Spoke-Modus initiiert das Service Catalog-Hub-Konto die Ausführung der Luigi-Workflows in den angegebenen Spoke-Konten mit Bootstrapping. Das Hub-Konto wird benachrichtigt, wenn die Spoke-Workflows abgeschlossen sind. Fehler in einem Spoke-Konto gehen auf das Hub-Konto zurück. Das Hub-Konto fragt das Spoke-Konto ab, um festzustellen, ob der Vorgang abgeschlossen ist, und um den Status zu ermitteln.

Im Spoke-Modus ist es am wenigsten wahrscheinlich, dass AWS-Service Kontingenterhöhungen erforderlich sind, da fast alles in den separaten Spoke-Konten ausgeführt wird. Der Spoke-Modus bietet außerdem eine weitaus größere Parallelität als der Hub-Modus, wobei die zentrale Steuerung erhalten bleibt. Er kann die Bereitstellungsgeschwindigkeit gegenüber dem Hub-Modus um 800 Prozent verbessern. Der Spoke-Modus unterstützt die Produktverkettung durch DependsOn Beziehungen zwischen Produkten, wodurch sichergestellt wird, dass ein Produkt, von dem abhängig ist, bereits bereitgestellt wurde. Ein Produkt, das verkettete Produkte umfasst, kann auch ein verkettetes Produkt mit Komponenten bereitstellen. Sie können die erforderlichen Schritte auch mit speziellen AWS Lambda Funktionsaufrufen ausführen. Fehler in einer Speiche sind von anderen Speichen isoliert.

Der Spoke-Modus wird von Unternehmen mit über 980 Konten in bis zu 7 Regionen verwendet. Diese Unternehmen sind in der Regel in der Lage, innerhalb einer Stunde ein Produkt für alle Regionen und Konten in ihrer Infrastruktur bereitzustellen.

Anmerkung

Diese Ergebnisse können je nach Faktoren wie der Netzwerkinfrastruktur, der Arbeitslast und den für die Hub-and-Spoke-Konten der AWS Organisation geltenden Kontingente variieren. Sie hängen auch von den bereitgestellten Produktressourcen, ihren jeweiligen Erstellungszeiten und ihren Abhängigkeiten von anderen Ressourcen ab.

Async-Modus

Der asynchrone Modus initiiert Bereitstellungsworkflows in Spoke-Konten, wartet aber nicht auf Abschlussantworten der Spokes oder empfängt keine Antworten von diesen.

Caching

Ein weiterer Mechanismus, den Service Catalog Puppet verwendet, um die Geschwindigkeit von Workflows zu optimieren, besteht darin, allgemeine Aufgaben zwischenzuspeichern, die Schritte im Workflow darstellen. Wenn eine zwischengespeicherte Aufgabe abgeschlossen ist, schreibt sie ihre Ausgabe in Amazon Simple Storage Service (Amazon S3). Wenn die Aufgabe das nächste Mal in derselben Sitzung mit denselben Parametern aufgerufen wird, verwendet Service Catalog Puppet die zwischengespeicherten Werte, anstatt die Aufgabe erneut auszuführen. Weitere Informationen finden Sie unter Caching in der Service Catalog Puppet-Dokumentation.

DevSecOps Unterstützung über den gesamten Lebenszyklus

Service Catalog Puppet bietet Unterstützung für die Verwaltung der DevSecOps Pipeline. Sie können die Aktionen der Service Catalog Tools (wie in der Service Catalog Puppet-Übersicht dargestellt) verwenden, um Tests zu automatisieren und Produkte in Ihren AWS Lebenszykluskonten zu bewerben, einschließlich des empfohlenen Canary-Kontos. Weitere Informationen finden Sie in der Service Catalog Puppet-Dokumentation unter Verwalten Ihrer Umgebungen.

Um sicherzustellen, dass alle Probleme im Zusammenhang mit einer Produktänderung erkannt werden, bevor sie in großem Umfang in der Produktion eingesetzt werden, benötigt Service Catalog Puppet mindestens ein Canary-Konto für die erste Bereitstellung. Nachdem Sie die neue Version getestet haben und Vertrauen in sie gewonnen haben, können Sie sie auch für Produktionskunden bewerben, die nicht auf Canary spezialisiert sind. Wenn Sie Probleme feststellen, können Sie die Version rückgängig machen und sie erneut einführen, sobald die Probleme behoben sind. Wenn Sie diesen Ansatz verwenden, können Produktionsprobleme auftreten, wenn Sie eine kanarische Version veröffentlichen, bei der es Probleme mit den Produktionskonten gibt. Als Alternative können Sie für jede Produktänderung vollständige Regressionstests durchführen, bevor Sie die Änderung für die Produktion freigeben. Dies führt zu zusätzlichem Aufwand im CI/CD-Prozess, hilft aber, Produktionsprobleme zu vermeiden. Es liegt in der Verantwortung des DevSecOps Administrators, die besten Feature-Release-Szenarien und Herangehensweisen für seine Entwicklungsteams zu ermitteln.

Service Catalog Puppet ermöglicht es mehreren Teams, die Bereitstellung von Service Catalog-Produktlösungen gleichzeitig zu entwickeln und zu testen. Als bewährte Methode sollte ein Produkt nicht von mehreren Entwicklern gleichzeitig geändert werden. Stattdessen können Sie Produkte für separate, gleichzeitige Änderungen in feinkörnige Komponenten aufteilen.

Service Catalog Puppet hilft auch bei der Automatisierung von Tests durch eine Assertion-Anweisung, die statische Testfunktionen und Unit-Testfunktionen bereitstellt. Sie können Dienststeuerungsrichtlinien (SCPs) und IAM-Richtlinien mithilfe von Richtliniensimulatoren testen. Dabei handelt es sich um technische end-to-end Tests, die jedoch in Systemintegrationstest-Umgebungen (SIT) verwendet werden können. Weitere Informationen finden Sie unter Verwenden von Richtliniensimulationen und Anwenden von Dienststeuerungsrichtlinien in der Service Catalog Puppet-Dokumentation.

Reife, Vollständigkeit und Unterstützung

Service Catalog Puppet wird zwar nicht offiziell unterstützt AWS-Service, ist aber weit verbreitet. Dieses Tool wurde in den letzten Jahren von großen Unternehmen verwendet, um erfolgreich und zentral Produkte für Hunderte von OU-Konten innerhalb der gewünschten Bereitstellungszeitfenster bereitzustellen. Es hat sich als skalierbare, fehlertolerante Produktbereitstellung erwiesen. Benutzer, bei denen Probleme mit Service Catalog Puppet auftreten, können diese im GitHub Repository protokollieren, damit sie von den Mitwirkenden an dieser AWS Labs-Lösung behoben werden können.