Migration von Chef Server zu Stacks AWS OpsWorks

Wichtig

Der AWS OpsWorks Stacks Dienst hat am 26. Mai 2024 das Ende seiner Lebensdauer erreicht und wurde sowohl für neue als auch für bestehende Kunden deaktiviert. Wir empfehlen Kunden dringend, ihre Workloads so bald wie möglich auf andere Lösungen zu migrieren. Wenn Sie Fragen zur Migration haben, wenden Sie sich an das AWS Support Team auf AWS re:POST oder über den AWS Premium-Support.

Da AWS OpsWorks Stacks auf Chef basiert, ist die Migration von Chef Server zu AWS OpsWorks Stacks relativ einfach. Dieser Abschnitt enthält Leitlinien zum Anpassen von Chef-Server-Code auf AWS OpsWorks Stacks.

Anmerkung

Wir raten davon ab, eine Migration auf Stacks mit Chef-Versionen niedriger als 11.10, die auf Chef-Solo basieren und keine Suche oder Data Bags unterstützen, durchzuführen.

Zuweisen von Rollen an Layer

Chef-Server verwendet Rollen für die Darstellung und Verwaltung von Instances mit demselben Zweck und derselben Konfiguration, wie zum Beispiel eine Gruppe von Instances, die jeweils einen Java-Anwendungsserver hosten. Eine AWS OpsWorks Stacks-Ebene erfüllt im Wesentlichen denselben Zweck wie eine Chef-Rolle. Eine Ebene ist eine Blaupause für die Erstellung einer Reihe von Amazon Elastic Compute Cloud (Amazon EC2) -Instances mit derselben Konfiguration, denselben installierten Paketen, demselben Anwendungsbereitstellungsverfahren usw.

AWS OpsWorks Stacks umfasst eine Reihe integrierter Ebenen für verschiedene Arten von Anwendungsservern, einen HAProxy-Loadbalancer, einen MySQL-Datenbankmaster und einen Ganglia-Monitoring-Master. Die integrierte Java App Server-Ebene ist beispielsweise eine Blaupause für die Erstellung von Instanzen, die einen Tomcat-Server hosten.

Um zu AWS OpsWorks Stacks zu migrieren, müssen Sie jede Rolle einer Ebene zuordnen, die entsprechende Funktionen bietet. Für einige Rollen können Sie einfach eines der integrierten Layer verwenden. Für andere Rollen ist ggf. eine mehr oder weniger umfangreiche Anpassung erforderlich. Beginnen Sie mit der Prüfung der Funktionalität der integrierten Layer, einschließlich der jeweils zugeordneten Rezepte, um festzustellen, ob mindestens einer über die Funktionalität Ihrer Rolle verfügt. Weitere Informationen zu den integrierten Layern finden Sie unter Ebenen und AWS OpsWorks Stacks-Ebenenreferenz. Informationen zu den integrierten Rezepten finden Sie im öffentlichen AWS OpsWorks GitHub Stacks-Repository.

Die Vorgehensweise hängt davon ab, wie gut Sie ein Layer für die jeweilige Rolle anpassen können.

Ein integrierter Layer unterstützt sämtliche Funktionen der Rolle

Sie können den integrierten Layer direkt, ggf. mit geringfügigen Anpassungen, verwenden. Wenn eine Rolle beispielsweise einen Tomcat-Server unterstützt, übernehmen die Rezepte der Java App Server-Schicht möglicherweise bereits alle Aufgaben der Rolle, möglicherweise mit einigen geringfügigen Anpassungen. Sie können beispielsweise veranlassen, dass die integrierten Rezepte der Ebene Tomcat- oder Apache-Konfigurationseinstellungen verwenden, indem die entsprechenden Attribute oder Vorlagen überschrieben werden.

Ein integrierter Layer unterstützt einige, aber nicht alle Funktionalitäten einer Rolle

Sie können ggf. einen integrierte Ebene mithilfe einer Ebenenerweiterung verwenden. Dazu ist normalerweise die Implementierung von benutzerdefinierten Rezepten zur Unterstützung der fehlenden Funktionalität und die Zuweisung der Rezepte auf die Lebenszyklusereignisse des Layers erforderlich. Angenommen, Ihre Rolle installiert einen Redis-Server auf derselben Instance, die einen Tomcat-Server hostet. Sie könnten die Java App Server-Ebene so erweitern, dass sie der Funktionalität der Rolle entspricht, indem Sie ein benutzerdefiniertes Rezept für die Installation von Redis auf den Instanzen der Ebene implementieren und das Rezept dem Setup-Ereignis der Ebene zuweisen.

Die Funktionalität der Rolle wird von keinem integrierten Layer ausreichend unterstützt

Implementieren Sie einen benutzerdefinierten Layer. Angenommen, Ihre Rolle unterstützt einen MongoDB-Datenbank-Server, der von keinem der integrierten Layer unterstützt wird. Sie können diese Unterstützung herstellen, indem Sie die Rezepte implementieren, um die erforderlichen Pakete zu installieren, den Server zu konfigurieren usw. und um die Rezepte einem Lebenszyklusereignis eines benutzerdefinierten Layers zuzuweisen. In der Regel können Sie hierfür mindestens einige der Rezepte der Rolle verwenden. Weitere Informationen zum Implementieren eines benutzerdefinierten Layers finden Sie unter Erstellen eines benutzerdefinierten Tomcat-Server-Layers.

Verwenden von Data Bags

Chef-Server ermöglicht die Übermittlung von benutzerdefinierten Daten an Ihre Rezepte mithilfe von Data Bags.

• Speichern Sie die Daten mit Ihren Rezeptbüchern und Chef installiert diese auf jeder Instance.

• Sie können verschlüsselte Data Bags für vertrauliche Daten verwenden, wie z. B. Passwörter.

AWS OpsWorks Stacks unterstützt Datenbeutel; Rezepte können die Daten mit genau demselben Code wie bei Chef Server abrufen. Die Unterstützung hat jedoch folgende Einschränkungen und Unterschiede:

• Data Bags werden nur von Chef 11.10 Linux und höheren Stacks unterstützt.

  Windows-Stacks und Linux-Stacks unter niedrigeren Versionen von Chef unterstützen Data Bags nicht.

• Speichern Sie keine Data Bags in Ihrem Rezeptbuch-Repository.

  Verwenden Sie stattdessen ein benutzerdefiniertes JSON-Objekt zur Verwaltung der Daten des Data Bags.

• AWS OpsWorks Stacks unterstützt keine verschlüsselten Datenbeutel.

  Wenn Sie vertrauliche Daten in verschlüsselter Form, wie z. B. Passwörter oder Zertifikate, speichern müssen, empfehlen wir, diese in einem privaten S3-Bucket zu speichern. Anschließend können Sie ein benutzerdefiniertes Rezept erstellen, das zum Abrufen der Daten das Amazon SDK für Ruby verwendet. Ein Beispiel finden Sie unter Verwenden des -SDK for Ruby.

Weitere Informationen finden Sie unter Verwenden von Data Bags.

Verwenden der Chef-Suchfunktion

Chef-Server speichert Stack-Konfigurationsinformationen wie IP-Adressen und Rollen-Konfigurationen auf dem Server. Rezepte verwenden die Chef-Suche, um diese Daten abzurufen. AWS OpsWorks Stacks verwendet einen etwas anderen Ansatz. Zum Beispiel basieren Chef 11.10 Linux-Stacks auf dem Chef-Client-Lokal-Modus, eine Chef-Client-Option, die eine abgespeckte Chef-Server-Version (oft als Chef Zero bezeichnet) lokal auf der Instance ausführt. Chef Zero unterstützt die Suche von Daten, die im Knotenobjekt der Instance gespeichert sind.

Anstatt Stack-Daten auf einem Remote-Server zu speichern, fügt AWS OpsWorks Stacks dem Knotenobjekt jeder Instanz für jedes Lebenszyklusereignis eine Reihe von Stackkonfigurations- und Bereitstellungsattributen hinzu. Diese Attribute stellen einen Snapshot der Stack-Konfiguration dar. Sie verwenden dieselbe Syntax wie der Chef-Server und enthalten die meisten Daten, die von den Rezepten vom Server abgerufen werden müssen.

Oft müssen Sie den suchabhängigen Code Ihrer Rezepte für Stacks nicht ändern. AWS OpsWorks Da die Chef-Suche auf dem Knotenobjekt basiert, das die Stackkonfiguration und die Bereitstellungsattribute enthält, funktionieren Suchanfragen in AWS OpsWorks Stacks normalerweise genauso wie bei Chef Server.

Die Hauptausnahme wird durch die Tatsache verursacht, dass die Stack-Konfiguration und die Bereitstellungsattribute nur Daten enthalten, die AWS OpsWorks Stacks bei der Installation der Attribute auf der Instanz bekannt sind. Wenn Sie ein Attribut lokal auf einer bestimmten Instance erstellen oder ändern, werden diese Änderungen nicht an AWS OpsWorks Stacks weitergegeben und werden nicht in die Stack-Konfiguration und die Bereitstellungsattribute übernommen, die auf den anderen Instances installiert sind. Sie können die Suchfunktion nur zum Abrufen eines Attributwertes auf dieser Instance verwenden. Weitere Informationen finden Sie unter Verwenden der Chef-Suchfunktion.

Aus Gründen der Kompatibilität mit Chef Server fügt AWS OpsWorks Stacks dem Knotenobjekt eine Reihe von role Attributen hinzu, von denen jedes eines der Layer-Attribute des Stacks enthält. Wenn Ihr Rezept roles als Such-Schlüssel verwendet, müssen Sie den Such-Code nicht ändern. Die Abfrage gibt automatisch die Daten für den entsprechenden Layer zurück. Die beiden folgenden Abfragen geben beispielsweise die php-app-Attribute des Layers zurück.

phpserver = search(:node, "layers:php-app").first

phpserver = search(:node, "roles:php-app").first

Verwalten von Rezeptbüchern und Rezepten

AWS OpsWorks Stacks und Chef Server behandeln Kochbücher und Rezepte etwas anders. Chef Server:

• Sie stellen alle Rezeptbücher zur Verfügung, indem Sie sie entweder selbst oder mithilfe von Community-Rezeptbüchern implementieren.

• Speichern Sie Ihre Rezeptbücher auf dem Server.

• Führen Sie die Rezepte manuell oder planmäßig aus.

Mit AWS OpsWorks Stacks:

• AWS OpsWorks Stacks bietet ein oder mehrere Kochbücher für jede der integrierten Ebenen. Diese Rezeptbücher verarbeiten Standardaufgaben, wie z. B. das Installieren und Konfigurieren einer integrierten Layer-Software und Bereitstellen von Anwendungen.

  Zum Verarbeiten von Aufgaben, die nicht von den integrierten Rezeptbüchern durchgeführt werden, fügen Sie benutzerdefinierte Rezeptbücher zu Ihrem Stack hinzu oder verwenden Sie Community-Rezeptbücher.

• Sie speichern AWS OpsWorks Stacks-Kochbücher in einem Remote-Repository, z. B. in einem S3-Bucket oder einem Git-Repository.

  Weitere Informationen finden Sie unter Speichern von Rezeptbüchern.

• Sie können Rezepte manuell ausführen, aber normalerweise lassen Sie AWS OpsWorks Stacks Rezepte für Sie als Reaktion auf eine Reihe von Lebenszyklusereignissen ausführen, die an wichtigen Punkten im Lebenszyklus einer Instanz auftreten.

  Weitere Informationen finden Sie unter Ausführen von Rezepten.

• AWS OpsWorks Stacks unterstützt Berkshelf nur auf Chef 11.10-Stacks. Wenn Sie die Rezeptbuch-Abhängigkeiten mit Berkshelf verwalten, können Sie keine Stacks mit Chef 11.4 oder niedriger verwenden.

  Weitere Informationen finden Sie unter Verwenden von Berkshelf.

Themen

• Speichern von Rezeptbüchern
• Ausführen von Rezepten

Speichern von Rezeptbüchern

Mit dem Chef-Server speichern Sie Ihre Rezeptbücher auf dem Server und stellen Sie vom Server für die Instances bereit. Mit AWS OpsWorks Stacks speichern Sie Kochbücher in einem Repository — einem S3- oder HTTP-Archiv oder einem Git- oder Subversion-Repository. Sie geben die Informationen an, die AWS OpsWorks Stacks benötigt, um den Code aus dem Repository auf die Instanzen eines Stacks herunterzuladen, wenn Sie Cookbooks installieren.

Für die Migration vom Chef-Server müssen Sie Ihre Rezeptbücher in einem dieser Repositorys ablegen. Weitere Informationen zur Struktur eines Rezeptbuch-Repositorys finden Sie unter Rezeptbuch-Repositorys.

Ausführen von Rezepten

In AWS OpsWorks Stacks hat jede Ebene eine Reihe von Lebenszyklusereignissen — Setup, Configure, Deploy, Undeploy und Shutdown —, die jeweils an einem wichtigen Punkt im Lebenszyklus einer Instanz auftreten. Um ein benutzerdefiniertes Rezept auszuführen, weisen Sie es in der Regel dem entsprechenden Ereignis auf dem zugehörigen Layer zu. Wenn das Ereignis eintritt, führt AWS OpsWorks Stacks die entsprechenden Rezepte aus. Beispielsweise findet das Einrichtungsereignis nach Abschluss eines Bootvorgangs einer Instance statt. Daher weisen Sie normalerweise diesem Ereignis Rezepte zu, die Aufgaben wie das Installieren und Konfigurieren von Paketen und Starten von Services ausführen.

Sie können Rezepte mit dem Stack-Befehl "Execute Recipes" ausführen. Dieser Befehl ist zum Entwickeln und Testen hilfreich, aber Sie können ihn auch zum Ausführen von Rezepten verwenden, die nicht zu einem Lebenszyklusereignis zugewiesen sind. Sie können auch den Befehl zum Ausführen von Rezepten verwenden, um Einrichtungs- und Konfigurationsereignisse manuell auszulösen.

Zusätzlich zur AWS OpsWorks Stacks-Konsole können Sie die AWS-CLI oder SDKs verwenden, um Rezepte auszuführen. Diese Tools unterstützen sämtliche AWS OpsWorks Stacks-API-Aktionen, sind aber einfacher zu verwenden als die API. Verwenden Sie den CLI-Befehl „create-deployment“, um ein Lebenszyklusereignis auszulösen, das alle zugeordneten Rezepte ausführt. Mit diesem Befehl können Sie auch eine oder mehrere Rezepte ausführen, ohne ein Ereignis auszulösen. Der entsprechende SDK-Code hängt von der spezifischen Sprache ab, ist aber in der Regel dem CLI-Befehl ähnlich.

Die folgenden Beispiele beschreiben zwei Möglichkeiten zur Nutzung des CLI-Befehls create-deployment, um die Anwendungsbereitstellung zu automatisieren.

• Stellen Sie Ihre App planmäßig bereit, indem Sie einen benutzerdefinierten Layer mit einer einzelnen Instance auf Ihrem Stack hinzufügen.

  Fügen Sie ein benutzerdefiniertes Einrichtungsrezept hinzu, das einen cron-Auftrag in der Instance erstellt, um den Befehl nach einem bestimmten Zeitplan auszuführen. Ein Beispiel für die Verwendung eines Rezepts zum Erstellen eines cron-Auftrags finden Sie unter Ausführen von Cron-Jobs auf Linux-Instances.

• Fügen Sie zur Ihrer laufenden Integrationspipeline eine Aufgabe hinzu, die den CLI-Befehl create-deployment zur Bereitstellung der Anwendung verwendet.

Verwenden von Chef-Umgebungen

AWS OpsWorks Stacks unterstützt keine Chef-Umgebungen; node.chef_environment kehrt immer zurück. _default