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.
Migration von Chef Server zu AWS OpsWorks Stacks
Wichtig
Das Tool AWS OpsWorks Stacks Der 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 AWS Support Team ein AWS Re:post oder
Weil AWS OpsWorks Stacks basiert auf Chef und migriert von Chef Server zu AWS OpsWorks Stacks ist relativ einfach. Dieses Thema enthält Richtlinien zum Ändern des Chef Server-Codes, mit dem Sie arbeiten können AWS OpsWorks Stapel.
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.
Themen
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. Ein AWS OpsWorks Die Stapelebene dient im Wesentlichen demselben Zweck wie eine Chef-Rolle. Eine Ebene ist eine Blaupause für die Erstellung einer Reihe von Amazon Elastic Compute Cloud (AmazonEC2) -Instances mit derselben Konfiguration, den installierten Paketen, dem Verfahren zur Anwendungsbereitstellung usw.
AWS OpsWorks Stacks umfasst eine Reihe integrierter Ebenen für verschiedene Arten von Anwendungsservern, einen Load HAProxy Balancer, einen My SQL Database-Master 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 migrieren AWS OpsWorks Stacks müssen Sie jeder Rolle eine 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 AWS OpsWorks Öffentliches GitHub 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 bescheidenen 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.
Stattdessen verwenden Sie custom, JSON um die Daten Ihrer Datentasche zu verwalten.
-
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. Sie können dann ein benutzerdefiniertes Rezept erstellen, das Amazon SDK for Ruby
verwendet, um die Daten abzurufen. Ein Beispiel finden Sie unter Verwenden von 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. Die Rezepte verwenden die Chef-Suche zum Abrufen dieser Daten. 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, AWS OpsWorks Stacks fügt 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 nicht ändern für AWS OpsWorks Stapel. Da die Chef-Suche mit dem Knotenobjekt arbeitet, das die Stackkonfiguration und die Bereitstellungsattribute enthält, suchen Sie Abfragen in AWS OpsWorks Stacks funktionieren normalerweise genauso wie Chef Server.
Die primäre Ausnahme wird dadurch verursacht, dass die Stackkonfiguration und die Bereitstellungsattribute nur Daten enthalten, die AWS OpsWorks Stacks weiß, wann es die Attribute auf der Instance installiert. Wenn Sie ein Attribut lokal auf einer bestimmten Instanz erstellen oder ändern, werden diese Änderungen nicht zurückübertragen AWS OpsWorks Stacks und sind nicht in die Stack-Konfiguration und die Bereitstellungsattribute integriert, 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 AWS OpsWorks Stacks fügt 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 Stapel:
-
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.
-
Du speicherst AWS OpsWorks Stapelt Kochbücher in einem Remote-Repository, z. B. einem S3-Bucket oder einem Git-Repository.
Weitere Informationen finden Sie unter Speichern von Rezeptbüchern.
-
Du kannst Rezepte manuell ausführen, aber in der Regel musst du AWS OpsWorks Stacks führen Rezepte für Sie als Reaktion auf eine Reihe von Lebenszyklusereignissen aus, die an wichtigen Punkten im Lebenszyklus einer Instance 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.
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, Sie speichern 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 muss den Code aus dem Repository auf die Instanzen eines Stacks herunterladen, 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 Bei Stacks hat jede Ebene eine Reihe von Lebenszyklusereignissen — Setup, Configure, Deployment, 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, AWS OpsWorks Stacks führt die zugehörigen 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 zu AWS OpsWorks In der Stacks-Konsole können Sie das AWSCLIoder verwenden SDKs
In den folgenden Beispielen werden zwei Möglichkeiten beschrieben, den create-deployment CLI Befehl zur Automatisierung der Anwendungsbereitstellung zu verwenden.
-
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 einescron-Auftrags finden Sie unter Ausführen von Cron-Jobs auf Linux-Instances. -
Fügen Sie Ihrer Continuous Integration-Pipeline eine Aufgabe hinzu, die den
create-deploymentCLI Befehl zur Bereitstellung der App verwendet.
Verwenden von Chef-Umgebungen
AWS OpsWorks Stacks unterstützt keine Chef-Umgebungen; kehrt node.chef_environment immer zurück_default.
