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.
# Cookbooks und Rezepte
**Wichtig**
Der AWS OpsWorks Stacks Dienst hat am 26. Mai 2024 das Ende seiner Lebensdauer erreicht und wurde sowohl für Neu- als auch für Bestandskunden 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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
OpsWorks Stacks verwendet Chef-Kochbücher, um Aufgaben wie die Installation und Konfiguration von Paketen und die Bereitstellung von Apps zu erledigen. In diesem Abschnitt wird beschrieben, wie Kochbücher mit Stacks verwendet werden. OpsWorks Weitere Informationen finden Sie unter [Chef](http://www.opscode.com/).
**Anmerkung**
OpsWorks Stacks unterstützt derzeit die Chef-Versionen 12, 11.10.4, 11.4.4 und 0.9.15.5. Chef 0.9.15.5 ist jedoch veraltet und sollte für neue Stacks daher nicht mehr verwendet werden. Der Einfachheit halber wird auf sie nur mit den Haupt- und Nebenversionsnummern verwiesen. Stacks, auf denen Chef 0.9 oder 11.4 ausgeführt wird, verwenden [Chef Solo](https://docs.chef.io/chef_solo.html). Auf Stacks mit Chef 12 oder 11.10 wird [Chef Client](http://www.getchef.com/blog/2013/10/31/chef-client-z-from-zero-to-chef-in-8-5-seconds/) im lokalen Modus ausgeführt. Für Linux-Stacks können Sie mit dem Configuration Manager angeben, welche Chef-Version verwendet werden soll, wenn Sie [einen Stack erstellen](workingstacks-creating.md). Windows Stacks müssen Chef 12.2 verwenden. Weitere Informationen, einschließlich Richtlinien zum Migrieren von Stacks auf aktuelle Chef-Versionen, finden Sie unter [Chef-Versionen](workingcookbook-chef11.md).
**Topics**
+ [Rezeptbuch-Repositorys](workingcookbook-installingcustom-repo.md)
+ [Chef-Versionen](workingcookbook-chef11.md)
+ [Ruby-Versionen](workingcookbook-ruby.md)
+ [Installieren von benutzerdefinierten Rezeptbüchern](workingcookbook-installingcustom-enable.md)
+ [Aktualisieren von benutzerdefinierten Rezeptbüchern](workingcookbook-installingcustom-enable-update.md)
+ [Ausführen von Rezepten](workingcookbook-executing.md)
# Rezeptbuch-Repositorys
**Wichtig**
Der AWS OpsWorks Stacks Service 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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Ihre benutzerdefinierten Rezeptbücher müssen in einem Online-Repository gespeichert sein, entweder in einem Archiv, wie z. B. einer ZIP-Datei, oder in einem Source Control Manager wie Git. Ein Stack kann nur ein benutzerdefiniertes Rezeptbuch-Repository haben. Das Repository kann jedoch eine beliebige Anzahl von Rezeptbüchern enthalten. Wenn Sie die Kochbücher installieren oder aktualisieren, installiert OpsWorks Stacks das gesamte Repository in einem lokalen Cache auf jeder der Instanzen des Stacks. Wenn eine Instance z. B. ein oder mehrere Rezepte ausführen muss, verwendet sie den Code aus dem lokalen Cache.
Im Folgenden wird beschrieben, wie Sie Ihr Rezeptbuch-Repository strukturieren, was abhängig vom Typ ist. Der kursive Text in den Abbildungen stellt benutzerdefinierte Verzeichnis- und Dateinamen dar, darunter der Repository- und Archivname.
**Source Control Manager**
OpsWorks Stacks unterstützt die folgenden Quellcodeverwaltungsmanager:
+ Linux-Stacks — Git und Subversion
+ Windows-Stapel — Git
Im Folgenden sehen Sie das erforderliche Verzeichnis und die Dateistruktur:
![\[Obligatorische Struktur für SCM-Rezeptbuch-Repositorys\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/cookbook_folders.png)
+ Die Rezeptbuch-Verzeichnisse müssen sich alle auf der obersten Ebene befinden.
**Archiv**
OpsWorks Stacks unterstützt die folgenden Archive:
+ Linux-Stacks — Zip-, Gzip-, Bzip2- oder Tarball-Dateien, gespeichert auf Amazon S3 oder einer Website (HTTP-Archiv).
OpsWorks Stacks unterstützt keine unkomprimierten Tarballs.
+ Windows-Stacks — Zip- und TGZ-Dateien (GZIP-komprimiertes Tar), gespeichert auf Amazon S3.
Im Folgenden wird das erforderliche Verzeichnis und die Dateistruktur angezeigt, was davon abhängt, ob Sie einen Linux- oder Windows-Stack ausführen. Die Rezeptbuch-Struktur ist die gleiche wie für SCM-Repositorys, sie wird also durch Auslassungszeichen dargestellt (...).
![\[Obligatorische Struktur für Archive\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/cookbook_folders_archive.png)
+ Linux-Stacks — Die Kochbuchverzeichnisse müssen in einem Stammverzeichnis enthalten sein.
+ Windows-Stacks — Die Kochbücher müssen sich auf der obersten Ebene des Archivs befinden.
Wenn Sie nur ein Rezeptbuch haben, können Sie optional das Rezeptbuch-Verzeichnis weglassen und die Rezeptbuch-Dateien auf der obersten Ebene platzieren. In diesem Fall erhält OpsWorks Stacks den Namen des Rezeptbuchs von metadata.rb.
Jedes Rezeptbuch-Verzeichnis verfügt über mindestens ein und in der Regel über alle der folgenden Standardverzeichnisse und Dateien, die Standardnamen verwenden müssen:
+ `attributes`— Die Attributdateien des Kochbuches.
+ `recipes`— Die Rezeptdateien des Kochbuches.
+ `templates`— Die Vorlagendateien des Kochbuches.
+ *other*— Optionale benutzerdefinierte Verzeichnisse, die andere Dateitypen wie Definitionen oder Spezifikationen enthalten.
+ `metadata.rb`— Die Metadaten des Kochbuches.
Für Chef 11.10 und höher: Wenn Ihre Rezepte von anderen Rezeptbüchern abhängen, müssen Sie entsprechende `depends` Anweisungen in die Rezeptbuch-Datei `metadata.rb` einfügen. Wenn Ihr Rezeptbuch beispielsweise ein Rezept mit einem Statement wie `include_recipe anothercookbook::somerecipe` enthält, muss Ihre Rezeptbuch-Datei `metadata.rb` die folgende Zeile enthalten: `depends "anothercookbook"`. Weitere Informationen finden Sie unter [About Cookbook Metadata](http://docs.chef.io/cookbook_repo.html#about-cookbook-metadata).
Vorlagen müssen in einem Unterverzeichnis des `templates`-Verzeichnisses gespeichert sein. Dieses enthält mindestens eine und optional mehrere Unterverzeichnisse. Diese Unterverzeichnisse können optional auch Unterverzeichnisse haben.
+ Vorlagen haben in der Regel ein `default`-Unterverzeichnis. Dieses enthält die Vorlagendateien, die Chef standardmäßig benutzt.
+ *andere* repräsentiert optionale Unterverzeichnisse, die für betriebssystemspezifische Vorlagen benutzt werden können.
+ Chef verwendet automatisch die Vorlage aus dem entsprechenden Unterverzeichnis, basierend auf Benennungskonventionen, welche in [File Specificity](http://docs.chef.io/templates.html#file-specificity) beschrieben werden. Für die Linux- und Ubuntu-Betriebssysteme können Sie beispielsweise betriebssystemspezifische Vorlagen in Unterverzeichnissen mit dem Namen `amazon`amazon oder `ubuntu` hinzufügen.
Die Details, wie Sie mit benutzerdefinierten Rezeptbüchern umgehen, hängen von Ihrem bevorzugten Repository-Typ ab.
**So benutzen Sie ein S3-Archiv**
1. Implementieren Sie Ihre Rezeptbücher mithilfe der im vorigen Abschnitt gezeigten Ordnerstruktur.
1. Erstellen Sie ein komprimiertes Archiv und laden Sie es in einen Amazon S3 S3-Bucket oder eine Website hoch.
Wenn Sie Ihre Rezeptbücher aktualisieren, müssen Sie eine neue Archivdatei erstellen und hochladen. Inhalte, die an Amazon-S3-Buckets geliefert werden, können Kundeninhalte enthalten. Weitere Informationen zum Entfernen sensibler Daten finden Sie unter [Wie entleere ich einen S3 Bucket?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/empty-bucket.html) oder [Wie lösche ich einen S3 Bucket?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html).
**So verwenden Sie eine SCM**
1. Richten Sie ein Git- oder Subversion-Repository ein, indem Sie die bereits gezeigte Struktur verwenden.
1. Optional können Sie die Kontrollfunktionen der Repository-Version benutzen, um mehrere Branches oder Versionen zu implementieren.
Wenn Sie Ihre Kochbücher aktualisieren, können Sie dies in einer neuen Filiale tun und einfach direkt OpsWorks die neue Version verwenden. Sie können auch bestimmte getaggte Versionen angeben. Details hierzu finden Sie unter [Festlegen eines benutzerdefinierten Rezeptbuch-Repositorys](workingcookbook-installingcustom-enable.md#workingcookbook-installingcustom-enable-repo).
[Installieren von benutzerdefinierten Rezeptbüchern](workingcookbook-installingcustom-enable.md)beschreibt, wie OpsWorks Stacks dein Kochbuch-Repository auf den Instanzen des Stacks installieren lässt.
**Wichtig**
Nachdem Sie die vorhandenen Kochbücher im Repository aktualisiert haben, müssen Sie den Befehl `update_cookbooks` stack ausführen, um OpsWorks Stacks anzuweisen, den lokalen Cache jeder Online-Instanz zu aktualisieren. Weitere Informationen finden Sie unter [Ausführen von Stack-Befehlen](workingstacks-commands.md).
# Chef-Versionen
**Wichtig**
Der AWS OpsWorks Stacks Service 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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
OpsWorks Stacks unterstützt mehrere Versionen von Chef. Sie wählen die Version aus, wenn Sie [den Stack erstellen](workingstacks-creating.md). OpsWorks Stacks installiert dann diese Version von Chef auf allen Instanzen des Stacks zusammen mit einer Reihe von integrierten Rezepten, die mit dieser Version kompatibel sind. Wenn Sie benutzerdefinierte Rezepte installieren, müssen diese mit der Chef-Version des Stacks kompatibel sein.
OpsWorks Stacks unterstützt derzeit die Chef-Versionen 12, 11.10, 11.4 und 0.9 für Linux-Stacks und Chef 12.2 (derzeit Chef 12.22) für Windows-Stacks. Der Einfachheit halber wird auf sie nur mit den Haupt- und Nebenversionsnummern verwiesen. Für Linux-Stacks können Sie mit dem Configuration Manager angeben, welche Chef-Version verwendet werden soll, wenn Sie [einen Stack erstellen](workingstacks-creating.md). Windows Stacks müssen Chef 12.2 verwenden. Weitere Informationen, einschließlich Richtlinien zum Migrieren von Stacks auf aktuelle Chef-Versionen, finden Sie unter [Chef-Versionen](#workingcookbook-chef11). Vollständige Versionsinformationen finden Sie unter [OpsWorks Stacks-Betriebssysteme](workinginstances-os.md).
**Chef 12.2**
Die Unterstützung von Chef 12.2 wurde im Mai 2015 eingeführt und wird nur von Windows-Stacks verwendet. Die aktuelle Version von Chef auf Windows-Stacks ist Chef 12.22. Der Support läuft mit Ruby 2.3.6 und verwendet den [Chef-Client im lokalen Modus](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode). Dieser startet einen lokalen In-Memory-Chef-Server mit dem Namen [chef-zero](https://docs.chef.io/ctl_chef_client.html#about-chef-zero). Dieser Server ermöglicht Rezepten die Nutzung der Chef-Suchfunktion und Data Bags. Der Support hat einige Einschränkungen, die in [Rezepte implementieren: Chef 12.2](workingcookbook-chef12.md) beschrieben sind. Sie können jedoch viele Community-Rezeptbücher ohne Änderung ausführen.
**Chef 12**
Der Chef 12-Support wurde im Dezember 2015 eingeführt und wird nur für Linux-Stacks verwendet. Er läuft mit Ruby 2.1.6 oder 2.2.3 und verwendet den [Chef-Client im lokalen Modus](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode). Rezepte können so die Chef-Suchfunktion und Data Bags verwenden. Weitere Informationen finden Sie unter [OpsWorks Stacks-Betriebssysteme](workinginstances-os.md).
**Chef 11.10**
Der Chef 11.10-Support wurde im März 2014 eingeführt und wird nur für Linux-Stacks verwendet. Er läuft mit Ruby 2.0.0 und verwendet den [Chef-Client im lokalen Modus](https://docs.chef.io/ctl_chef_client.html#run-in-local-mode). Rezepte können so die Chef-Suchfunktion und Data Bags verwenden. Der Support hat einige Einschränkungen, die in [Implementieren von Rezepten: Chef 11.10](workingcookbook-chef11-10.md) beschrieben sind. Sie können jedoch viele Community-Rezeptbücher ohne Änderung ausführen. Sie können auch [Berkshelf](http://berkshelf.com/) verwenden, um Ihre Rezeptbuchabhängigkeiten zu verwalten. Die unterstützten Berkshelf-Versionen hängen vom Betriebssystem ab. Weitere Informationen finden Sie unter [OpsWorks Stacks-Betriebssysteme](workinginstances-os.md). Sie können keine CentOS-Stacks erstellen, die Chef 11.10 verwenden.
**Chef 11.4**
Der Chef 11.4-Support wurde im Juli 2013 eingeführt und wird nur für Linux-Stacks verwendet. Er läuft mit Ruby 1.8.7 und verwendet [chef-solo](https://docs.chef.io/chef_solo.html). Hiermit werden die Chef-Suchfunktion oder Data Bags nicht unterstützt. Mit OpsWorks Stacks können Sie häufig Community-Kochbücher verwenden, die von diesen Funktionen abhängen, aber Sie müssen sie wie unter beschrieben ändern. [Migrieren auf eine neue Chef-Version](workingcookbook-chef11-migrate.md) Sie können keine CentOS-Stacks erstellen, die Chef 11.4 verwenden. Chef 11.4-Stacks werden auf regionalen Endpunkten außerhalb der Region USA Ost (Nord-Virginia) nicht unterstützt.
**Chef 0.9**
Chef 0.9 wird nur für Linux-Stacks verwendet und nicht mehr unterstützt. Beachten Sie die folgenden Informationen:
+ Mit der Konsole können Sie keinen neuen Chef 0.9-Stack erstellen.
Sie müssen die Befehlszeilen-Schnittstelle (CLI) bzw. eine API verwenden oder einen Stack mit einer anderen Chef-Version erstellen und anschließend die Stack-Konfiguration bearbeiten.
+ Neue OpsWorks Stacks-Funktionen sind für Chef 0.9-Stacks nicht verfügbar.
+ Neue Betriebssystemversionen bieten nur begrenzten Support für Chef 0.9-Stacks.
Insbesondere Amazon Linux 2014.09 und spätere Versionen unterstützen Chef 0.9-Stacks mit Rails App Server-Layern, die von Ruby 1.8.7 abhängen, nicht.
+ Neue AWS-Regionen, einschließlich Europa (Frankfurt), unterstützen Chef 0.9-Stacks nicht.
Wir empfehlen, Chef 0.9 nicht für neue Stacks zu verwenden. Sie sollten bestehende Stacks so bald wie möglich auf die neueste Chef-Version migrieren.
Wenn Sie Community-Kochbücher mit OpsWorks Stacks verwenden möchten, empfehlen wir [Ihnen, Chef 12 für neue Linux-Stacks anzugeben](workingstacks-creating.md) und Ihre vorhandenen Linux-Stacks auf Chef 12 zu migrieren. Sie können die OpsWorks Stacks-Konsole, API oder CLI verwenden, um Ihre vorhandenen Stacks auf eine neuere Chef-Version zu migrieren. Weitere Informationen finden Sie unter [Migrieren auf eine neue Chef-Version](workingcookbook-chef11-migrate.md).
**Topics**
+ [Implementierung von Rezepten für Chef 12.2 Stacks](workingcookbook-chef12.md)
+ [Implementieren von Rezepten für Chef 12-Stacks](workingcookbook-chef12-linux.md)
+ [Implementieren von Rezepten für Chef 11.10-Stacks](workingcookbook-chef11-10.md)
+ [Implementieren von Rezepten für Chef 11.4-Stacks](workingcookbook-chef11-4.md)
+ [Migrieren eines vorhandenen Linux-Stacks auf eine neue Chef-Version](workingcookbook-chef11-migrate.md)
# Implementierung von Rezepten für Chef 12.2 Stacks
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Chef 12.2 (derzeit Chef 12.22) steht nur auf Windows-Stacks zur Verfügung, die diese Chef-Version ausführen müssen.
+ Rezepte müssen Windows-spezifische Attribute und Ressourcen für einige Zwecke verwenden.
Weitere Informationen finden Sie unter [Chef für Microsoft Windows](https://docs.chef.io/windows.html).
+ Da Chef-Läufe Ruby 2.3.6 verwenden, können Ihre Rezepte die neue Ruby-Syntax nutzen.
+ Rezepte können die Chef-Suchfunktion und Data Bags verwenden.
Chef 12.2 Stacks können viele Community-Kochbücher ohne Änderung verwenden. Weitere Informationen erhalten Sie unter [Verwenden der Chef-Suchfunktion](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search) und [Verwenden von Data Bags](workingcookbook-chef11-10.md#workingcookbook-chef11-10-databag).
+ Die meisten der in [OpsWorks Referenz für Stacks Data Bag](data-bags.md) und [Integrierte Rezeptbuchattribute](attributes-recipes.md) beschriebenen Stack-Konfigurations- und Bereitstellungsattribute sind für Windows-Rezepte verfügbar.
Sie können diese Attributwerte mit der Chef-Suchfunktion abrufen. Ein Beispiel finden Sie unter [Abrufen von Attributwerten mit der Chef-Suche](cookbooks-101-opsworks-opsworks-stack-config-search.md). Eine Liste von Attributen finden Sie unter [OpsWorks Referenz für Stacks Data Bag](data-bags.md).
# Implementieren von Rezepten für Chef 12-Stacks
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Chef 12-Stacks bieten die folgenden Vorteile gegenüber Chef 11.10-Stacks:
+ Da Chef-Läufe Ruby 2.1.6 verwenden, können Ihre Rezepte die neue Ruby-Syntax nutzen.
+ Chef 12-Stacks können noch mehr Community-Rezeptbücher ohne Änderung verwenden. Ohne integrierte Rezeptbücher kann es nicht mehr zu Namenskonflikten zwischen integrierten und benutzerdefinierten Rezeptbüchern kommen.
+ Sie sind nicht mehr auf die Berkshelf-Versionen beschränkt, für die OpsWorks Stacks vorgefertigte Pakete bereitgestellt hat. Berkshelf ist in Chef 12 nicht mehr auf OpsWorks Stacks-Instanzen installiert. Stattdessen können Sie eine beliebige Berkshelf-Version auf Ihrer lokalen Workstation verwenden.
+ Es gibt jetzt eine klare Trennung zwischen den integrierten Kochbüchern, die OpsWorks Stacks mit Chef 12 (Elastic Load Balancing, Amazon RDS und Amazon ECS) bereitstellt, und benutzerdefinierten Kochbüchern. Dadurch ist die Fehlerbehebung bei fehlgeschlagenen Chef-Läufen einfacher.
# Implementieren von Rezepten für Chef 11.10-Stacks
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Chef 11.10-Stacks bieten die folgenden Vorteile gegenüber Chef 11.4-Stacks:
+ Da Chef-Läufe Ruby 2.0.0 verwenden, können Ihre Rezepte die neue Ruby-Syntax nutzen.
+ Rezepte können die Chef-Suchfunktion und Data Bags verwenden.
Chef 11.10-Stacks können viele Community-Rezeptbücher ohne Änderung nutzen.
+ Sie können Berkshelf zum Verwalten von Rezeptbüchern verwenden.
Berkshelf bietet eine flexiblere Möglichkeit zum Verwalten Ihrer benutzerdefinierten Rezeptbücher und zum Verwenden von Community-Rezeptbüchern in einem Stack.
+ Rezeptbücher müssen Abhängigkeiten in `metadata.rb` deklarieren.
Wenn Ihr Rezeptbuch von einem anderen Rezeptbuch abhängt, müssen Sie diese Abhängigkeit in die Datei `metadata.rb` Ihres Rezeptbuchs aufnehmen. Wenn Ihr Rezeptbuch beispielsweise ein Rezept mit einem Statement wie `include_recipe anothercookbook::somerecipe` enthält, muss Ihre Rezeptbuch-Datei `metadata.rb` die folgende Zeile enthalten: `depends "anothercookbook"`.
+ OpsWorks Stacks installiert einen MySQL-Client nur dann auf den Instanzen eines Stacks, wenn der Stack eine MySQL-Schicht enthält.
+ OpsWorks Stacks installiert einen Ganglia-Client nur dann auf den Instanzen eines Stacks, wenn der Stack eine Ganglia-Schicht enthält.
+ Wenn eine Bereitstellung `bundle install` ausführt und bei der Installation ein Fehler auftritt, kann die Bereitstellung auch nicht verarbeitet werden.
**Wichtig**
Verwenden Sie keine Namen der integrierten Rezeptbücher für benutzerdefinierte oder Community-Rezeptbücher. Bei benutzerdefinierten Rezeptbüchern mit demselben Namen wie integrierte Rezeptbücher kann ein Fehler auftreten. [Eine vollständige Liste der integrierten Kochbücher, die mit den Stacks Chef 11.10, 11.4 und 0.9 verfügbar sind, finden Sie im Opsworks-Cookbooks-Repository unter. GitHub](https://github.com/aws/opsworks-cookbooks)
Bei Rezeptbüchern mit Nicht-ASCII-Zeichen, die in Chef 0.9- und 11.4-Stacks erfolgreich ausgeführt werden, kann auf einem Chef 11.10-Stack ein Fehler auftreten. Der Grund ist, dass Chef 11.10-Stacks Ruby 2.0.0 für Chef-Ausführungen verwenden, bei dem die Kodierungsrichtlinien viel strenger sind als bei Ruby 1.8.7. Um sicherzustellen, dass diese Rezeptbücher auf Chef 11.10-Stacks erfolgreich ausgeführt werden, sollte jede Datei mit Nicht-ASCII-Zeichen oben mit einem Kommentar, der einen Hinweis zur Kodierung enthält, versehen sein. Für die UTF-8-Kodierung würde der Kommentar z. B. `# encoding: UTF-8` lauten. Weitere Informationen zur Ruby 2.0.0-Kodierung finden Sie unter [Kodierung](http://www.ruby-doc.org/core-2.0.0/Encoding.html).
**Topics**
+ [Installation und Vorrang von Rezeptbüchern](#workingcookbook-chef11-10-override)
+ [Verwenden der Chef-Suchfunktion](#workingcookbook-chef11-10-search)
+ [Verwenden von Data Bags](#workingcookbook-chef11-10-databag)
+ [Verwenden von Berkshelf](#workingcookbook-chef11-10-berkshelf)
## Installation und Vorrang von Rezeptbüchern
Das Verfahren zur Installation von OpsWorks Stacks-Kochbüchern funktioniert für Chef 11.10-Stacks etwas anders als für frühere Chef-Versionen. Bei Chef 11.10-Stacks werden die integrierten, benutzerdefinierten und Berkshelf-Kochbücher nach der Installation von OpsWorks Stacks in der folgenden Reihenfolge zu einem gemeinsamen Verzeichnis zusammengeführt:
1. Integrierte Rezeptbücher.
1. Berkshelf-Rezeptbücher, sofern vorhanden.
1. Benutzerdefinierte Rezeptbücher, sofern vorhanden.
Wenn OpsWorks Stacks diese Zusammenführung durchführt, kopiert es den gesamten Inhalt der Verzeichnisse, einschließlich der Rezepte. Wenn Duplikate vorhanden sind, gelten die folgenden Regeln:
+ Der Inhalt der Berkshelf-Rezeptbücher hat Vorrang vor den integrierten Rezeptbüchern.
+ Der Inhalt der benutzerdefinierten Rezeptbücher hat Vorrang vor den Berkshelf-Rezeptbüchern.
Um zu veranschaulichen, wie dieser Vorgang funktioniert, sehen Sie sich das folgende Szenario an, in dem alle drei Rezeptbuchverzeichnisse ein Rezeptbuch mit dem Namen `mycookbook` enthalten:
+ Integrierte Kochbücher — `mycookbook` enthält eine Attributdatei mit dem Namen`someattributes.rb`, eine Vorlagendatei mit dem Namen `sometemplate.erb` und ein Rezept mit dem Namen. `somerecipe.rb`
+ Berkshelf-Kochbücher — beinhaltet und. `mycookbook` `sometemplate.erb` `somerecipe.rb`
+ Benutzerdefinierte Kochbücher — beinhaltet. `mycookbook` `somerecipe.rb`
Das zusammengeführte Rezeptbuch enthält Folgendes:
+ `someattributes.rb` aus dem integrierten Rezeptbuch.
+ `sometemplate.erb` aus dem Berkshelf-Rezeptbuch.
+ `somerecipe.rb` aus dem benutzerdefinierten Rezeptbuch.
**Wichtig**
Sie sollten Ihren Chef 11.10-Stack nicht anpassen, indem Sie ein komplettes integriertes Rezeptbuch in Ihr Repository kopieren und dann Teile des Rezeptbuchs ändern. Dabei wird das gesamte integrierte Rezeptbuch, einschließlich der Rezepte, überschrieben. Wenn OpsWorks Stacks dieses Kochbuch aktualisiert, kann dein Stack nicht von diesen Updates profitieren, es sei denn, du aktualisierst deine private Kopie manuell. Weitere Informationen zum Anpassen von Stacks finden Sie unter [Stacks anpassen OpsWorks](customizing.md).
## Verwenden der Chef-Suchfunktion
Sie können die Chef-[`search`-Methode](http://docs.chef.io/dsl_recipe.html#search) in Ihren Rezepten verwenden, um Stack-Daten abzufragen. Sie verwenden dieselbe Syntax wie für den Chef-Server, aber OpsWorks Stacks bezieht die Daten vom lokalen Knotenobjekt, anstatt einen Chef-Server abzufragen. Diese Daten umfassen Folgendes:
+ Die [Stack-Konfigurations- und Bereitstellungsattribute](workingstacks-json.md) der Instance.
+ Die Attribute aus den Attributdateien der integrierten und benutzerdefinierten Rezeptbücher der Instance.
+ Von Ohai gesammelte Systemdaten.
Die Stack-Konfiguration und die Bereitstellungsattribute enthalten die meisten Informationen, die Rezepte normalerweise durch Suchen abrufen, einschließlich Daten wie Hostnamen und IP-Adressen für jede Online-Instanz im Stack. OpsWorks Stacks aktualisiert diese Attribute für jedes [Lebenszyklusereignis](workingcookbook-events.md), wodurch sichergestellt wird, dass sie den aktuellen Stack-Status genau wiedergeben. Das bedeutet, dass Sie suchabhängige Community-Rezepte in Ihrem Stack häufig ohne Änderung verwenden können. Die Suchmethode gibt weiterhin die entsprechenden Daten zurück. Sie stammen nur aus den Stack-Konfigurations- und Bereitstellungsattributen statt von einem Server.
Die Haupteinschränkung der OpsWorks Stacks-Suche besteht darin, dass nur die Daten im lokalen Knotenobjekt verarbeitet werden, insbesondere die Stack-Konfiguration und die Bereitstellungsattribute. Aus diesem Grund sind die folgenden Arten von Daten über die Suche möglicherweise nicht verfügbar:
+ Lokal definierte Attribute auf anderen Instances.
Wenn ein Rezept ein Attribut lokal definiert, werden diese Informationen nicht an den OpsWorks Stacks-Dienst zurückgemeldet, sodass Sie mit der Suche nicht von anderen Instanzen aus auf diese Daten zugreifen können.
+ Benutzerdefinierte `deploy`-Attribute.
Sie können das benutzerdefinierte JSON-Objekt bei der [Bereitstellung einer App](workingapps-deploying.md) angeben. Die entsprechenden Attribute werden auf den Instances des Stacks für diese Bereitstellung installiert. Wenn Sie die Bereitstellung jedoch nur für ausgewählte Instances vornehmen, werden die Attribute nur auf diesen Instances installiert. Abfragen für diese benutzerdefinierten JSON-Attribute schlagen auf allen anderen Instances fehl. Darüber hinaus sind die benutzerdefinierten Attribute in der Stack-Konfigurations- und Bereitstellungs-JSON nur für die jeweilige Bereitstellung enthalten. Auf die Attribute kann erst zugegriffen werden, wenn das nächste Lebenszyklusereignis eine neue Reihe von Stack-Konfigurations- und Bereitstellungsattributen installiert. Hinweis: Wenn Sie ein [benutzerdefiniertes JSON-Objekt für den Stack angeben](workingstacks-json.md), werden die Attribute auf allen Instances für jedes Lebenszyklusereignis installiert und können immer über die Suche gefunden werden.
+ Ohai-Daten von anderen Instances.
Das Chef-[Ohai-Tool](http://docs.chef.io/resource_ohai.html) ruft eine Vielzahl von Daten auf einer Instance ab und fügt sie dem Knotenobjekt hinzu. Diese Daten werden lokal gespeichert und nicht dem OpsWorks Stacks-Service gemeldet, sodass die Suchfunktion nicht auf Ohai-Daten von anderen Instances zugreifen kann. Einige dieser Daten können jedoch in die Stack-Konfigurations- und Bereitstellungsattribute aufgenommen werden.
+ Offline-Instances.
Die Stack-Konfigurations- und Bereitstellungsattribute enthalten nur Daten für Online-Instances.
Der folgende Rezeptauszug zeigt, wie die private IP-Adresse einer PHP-Layer-Instance mit der Suchfunktion abgerufen wird.
```
appserver = search(:node, "role:php-app").first
Chef::Log.info("The private IP is '#{appserver[:private_ip]}'")
```
**Anmerkung**
Wenn OpsWorks Stacks dem Node-Objekt die Stack-Konfiguration und die Bereitstellungsattribute hinzufügt, werden tatsächlich zwei Sätze von Layer-Attributen mit jeweils denselben Daten erstellt. Ein Satz befindet sich im `layers` Namespace, in dem OpsWorks Stacks die Daten speichert. Die andere Gruppe wird im `role`-Namespace abgelegt, d. h. so speichert der Chef Server die entsprechenden Daten. Der Zweck des `role` Namespace besteht darin, dass Suchcode, der für den Chef-Server implementiert wurde, auf einer OpsWorks Stacks-Instanz ausgeführt werden kann. Wenn Sie Code speziell für OpsWorks Stacks schreiben, könnten Sie entweder `layers:php-app` oder `role:php-app` im vorherigen Beispiel verwenden und `search` würden dasselbe Ergebnis zurückgeben.
## Verwenden von Data Bags
Sie können die Chef-[`data_bag_item`-Methode](http://docs.chef.io/dsl_recipe.html#data-bag-item) in Ihren Rezepten für die Abfrage von Informationen in einem Data Bag verwenden. Sie verwenden die gleiche Syntax wie für einen Chef-Server. OpsWorks Stacks erhält die Daten allerdings aus den Stack-Konfigurations- und Bereitstellungsattributen der Instance. OpsWorks Stacks unterstützt derzeit jedoch keine Chef-Umgebungen und kehrt daher `node.chef_environment` immer zurück. `_default`
Sie erstellen ein Data Bag mit einer benutzerdefinierten JSON, um dem `[:opsworks][:data_bags]`-Attribut ein oder mehrere Attribute hinzuzufügen. Das folgende Beispiel zeigt das allgemeine Format zum Erstellen eines Data Bags in einer benutzerdefinierten JSON.
**Anmerkung**
Sie können kein Data Bag erstellen, indem Sie es Ihrem Rezeptbuch-Repository hinzufügen. Sie müssen ein benutzerdefiniertes JSON-Objekt verwenden.
```
{
"opsworks": {
"data_bags": {
"bag_name1": {
"item_name1: {
"key1" : “value1”,
"key2" : “value2”,
...
}
},
"bag_name2": {
"item_name1": {
"key1" : “value1”,
"key2" : “value2”,
...
}
},
...
}
}
}
```
Sie [geben das benutzerdefinierte JSON-Objekt normalerweise für den Stack an](workingstacks-json.md), der die benutzerdefinierten Attribute auf jede Instance für jedes folgende Lebenszyklusereignis installiert. Sie können ein benutzerdefiniertes JSON-Objekt auch beim Bereitstellen einer Anwendung angeben. Diese Attribute werden jedoch nur für diese Bereitstellung installiert und zwar möglicherweise nur für eine bestimmte Gruppe von Instances. Weitere Informationen finden Sie unter [Bereitstellen von Anwendungen](workingapps-deploying.md).
Das folgende Beispiel zeigt, wie ein benutzerdefiniertes JSON-Objekt ein Data Bag mit dem Namen `myapp` erstellt. Die JSON verfügt über ein Element, `mysql`, mit zwei Schlüssel-Wert-Paaren.
```
{ "opsworks": {
"data_bags": {
"myapp": {
"mysql": {
"username": "default-user",
"password": "default-pass"
}
}
}
}
}
```
Um die Daten in Ihrem Rezept zu verwenden, können Sie `data_bag_item` aufrufen und das Data Bag und die Wertenamen übergeben, wie im folgenden Auszug dargestellt.
```
mything = data_bag_item("myapp", "mysql")
Chef::Log.info("The username is '#{mything['username']}' ")
```
Zum Ändern der Daten im Data Bag modifizieren Sie nur das benutzerdefinierte JSON-Objekt. Die Installation erfolgt dann auf den Instances des Stacks für das nächste Lebenszyklusereignis.
## Verwenden von Berkshelf
Mit Chef 0.9- und Chef 11.4-Stacks können Sie nur ein benutzerdefiniertes Rezeptbuch-Repository installieren. Mit Chef 11.10-Stacks können Sie [Berkshelf](http://berkshelf.com/) für die Verwaltung Ihrer Rezeptbücher und deren Abhängigkeiten verwenden. So können Sie Rezeptbücher aus mehreren Repositorys installieren. (Weitere Informationen finden Sie unter [Lokales Verpacken von Rezeptbuch-Abhängigkeiten](best-practices-packaging-cookbooks-locally.md).) Insbesondere können Sie mit Berkshelf OpsWorks Stacks-kompatible Community-Kochbücher direkt aus ihren Repositorys installieren, anstatt sie in Ihr benutzerdefiniertes Kochbuch-Repository kopieren zu müssen. Die unterstützten Berkshelf-Versionen hängen vom Betriebssystem ab. Weitere Informationen finden Sie unter [OpsWorks Stacks-Betriebssysteme](workinginstances-os.md).
Zum Verwenden von Berkshelf müssen Sie eine Aktivierung vornehmen, wie in [Installieren von benutzerdefinierten Rezeptbüchern](workingcookbook-installingcustom-enable.md) beschrieben. Nehmen Sie dann eine `Berksfile`-Datei in das Stammverzeichnis Ihres Rezeptbuch-Repositorys auf, das die zu installierenden Rezeptbücher festlegt.
Um eine externe Rezeptbuchquelle in einer Berksfile-Datei festzulegen, geben Sie ein Quellattribut oben in der Datei an, das die Standard-Repository-URL festlegt. Berkshelf sucht in der Quelle nach den Kochbüchern, sofern Sie nicht explizit ein Repository angeben. URLs Fügen Sie dann eine Zeile für die einzelnen Rezeptbücher hinzu, die Sie installieren möchten. Verwenden Sie dazu folgendes Format:
```
cookbook 'cookbook_name', ['>= cookbook_version'], [cookbook_options]
```
Die Felder nach `cookbook` geben das jeweilige Rezeptbuch an.
+ *cookbook\$1name*— (Erforderlich) Gibt den Namen des Kochbuches an.
Wenn Sie keine anderen Felder angeben, installiert Berkshelf das Kochbuch aus der angegebenen Quelle. URLs
+ *cookbook\$1version*— (Optional) Gibt die Version oder die Versionen des Kochbuchs an.
Sie können ein Präfix festlegen, wie z. B. `=` oder `>=`, um eine bestimmte Version oder eine Reihe gültiger Versionen anzugeben. Wenn Sie keine Version angeben, installiert Berkshelf die aktuelle Version.
+ *cookbook\$1options*— (Optional) Das letzte Feld ist ein Hash, der ein oder mehrere Schlüssel-Wert-Paare enthält, die Optionen wie den Speicherort des Repositorys angeben.
Sie können beispielsweise einen `git`-Schlüssel angeben, um auf ein bestimmtes Git-Repository zu verweisen, und einen `tag`-Schlüssel für eine bestimmte Repository-Branch festlegen. Die Angabe der Repository-Branch ist in der Regel der beste Weg, um sicherzustellen, dass Sie Ihr bevorzugtes Rezeptbuch installieren.
**Wichtig**
Deklarieren Sie keine Rezeptbücher, indem Sie eine `metadata`-Zeile in Ihrer Berksfile-Datei einfügen und die Rezeptbuchabhängigkeiten in der Datei `metadata.rb` deklarieren. Damit dies einwandfrei funktioniert, müssen beide Dateien im selben Verzeichnis gespeichert sein. Bei OpsWorks Stacks muss sich das Berksfile im Stammverzeichnis des Repositorys befinden, aber die `metadata.rb` Dateien müssen sich in ihren jeweiligen Kochbuchverzeichnissen befinden. Deklarieren Sie stattdessen externe Rezeptbücher explizit in der Berksfile-Datei.
Es folgt ein Beispiel für eine Berksfile-Datei, das die verschiedenen Möglichkeiten zum Angeben von Rezeptbüchern veranschaulicht. Weitere Informationen zum Erstellen einer Berksfile-Datei finden Sie unter [Berkshelf](http://berkshelf.com/).
```
source "https://supermarket.chef.io"
cookbook 'apt'
cookbook 'bluepill', '>= 2.3.1'
cookbook 'ark', git: 'git://github.com/opscode-cookbooks/ark.git'
cookbook 'build-essential', '>= 1.4.2', git: 'git://github.com/opscode-cookbooks/build-essential.git', tag: 'v1.4.2'
```
Mit dieser Datei werden die folgenden Rezeptbücher installiert:
+ Die aktuelle Version von `apt` aus dem Repository der Community-Rezeptbücher.
+ Die aktuelle Version von `bluepill` der Community-Rezeptbücher, sofern es sich um Version 2.3.1 oder höher handelt.
+ Die aktuelle Version von `ark` aus einem angegebenen Repository.
Die URL für dieses Beispiel ist für ein öffentliches Community-Kochbuch-Repository aktiviert GitHub, aber Sie können Kochbücher aus anderen Repositorys installieren, auch aus privaten Repositorys. Weitere Informationen finden Sie unter [Berkshelf](http://berkshelf.com/).
+ Das `build-essential`-Rezeptbuch aus der v1.4.2-Branch des angegebenen Repositorys.
Ein benutzerdefiniertes Rezeptbuch-Repository kann zusätzlich zu einer Berksfile-Datei benutzerdefinierte Rezeptbücher enthalten. In diesem Fall installiert OpsWorks Stacks beide Gruppen von Kochbüchern, was bedeutet, dass eine Instanz über bis zu drei Kochbuch-Repositorys verfügen kann.
+ Die integrierten Rezeptbücher werden im Verzeichnis `/opt/aws/opsworks/current/cookbooks` installiert.
+ Wenn Ihr benutzerdefiniertes Rezeptbuch-Repository Rezeptbücher enthält, werden sie in das Verzeichnis `/opt/aws/opsworks/current/site-cookbooks` installiert.
+ Wenn Sie Berkshelf aktiviert haben und Ihr benutzerdefiniertes Rezeptbuch-Repository eine Berksfile-Datei enthält, werden die angegebenen Rezeptbücher im Verzeichnis `/opt/aws/opsworks/current/berkshelf-cookbooks` installiert.
[**Die integrierten Kochbücher und Ihre benutzerdefinierten Kochbücher werden während der Einrichtung auf jeder Instanz installiert und anschließend nicht aktualisiert, es sei denn, Sie führen den Stack-Befehl „Benutzerdefinierte Kochbücher aktualisieren“ manuell aus.**](workingstacks-commands.md) OpsWorks Stacks läuft `berks install` bei jedem Koch-Lauf, sodass Ihre Berkshelf-Kochbücher für jedes [Lebenszyklusereignis](workingcookbook-events.md) gemäß den folgenden Regeln aktualisiert werden:
+ Bei einer neuen Version im Repository wird mit diesem Vorgang das Rezeptbuch aus dem Repository aktualisiert.
+ Andernfalls aktualisiert dieser Vorgang die Berkshelf-Rezeptbücher aus einem lokalen Cache.
**Anmerkung**
Mit dem Vorgang werden die Berkshelf-Rezeptbücher überschrieben. Wenn Sie die lokalen Kopien der Rezeptbücher geändert haben, werden die Änderungen hiermit überschrieben. Weitere Informationen finden Sie unter [Berkshelf](http://berkshelf.com/).
Sie können Ihre Berkshelf-Rezeptbücher auch aktualisieren, indem Sie den Stack-Befehl **Benutzerdefinierte Rezeptbücher aktualisieren** ausführen. Mit diesem Befehl werden sowohl die Berkshelf-Rezeptbücher als auch Ihre benutzerdefinierten Rezeptbücher aktualisiert.
# Implementieren von Rezepten für Chef 11.4-Stacks
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
**Wichtig**
Verwenden Sie keine Namen der integrierten Rezeptbücher für benutzerdefinierte oder Community-Rezeptbücher. Bei benutzerdefinierten Rezeptbüchern mit demselben Namen wie integrierte Rezeptbücher kann ein Fehler auftreten. [Eine vollständige Liste der integrierten Kochbücher, die mit den Chef-Stacks 11.10, 11.4 und 0.9 verfügbar sind, finden Sie im opsworks-cookbooks-Repository unter. GitHub](https://github.com/aws/opsworks-cookbooks)
Die primäre Einschränkung von Chef 11.4-Stacks besteht darin, dass Rezepte weder die Chef-Suchfunktion noch Data Bags verwenden können. OpsWorks Stacks installiert jedoch [Stackkonfigurations- und Bereitstellungsattribute](workingcookbook-json.md) auf jeder Instanz, die viele der Informationen enthalten, die Sie mit der Suche erhalten würden, einschließlich der folgenden:
+ Benutzerdefinierte Daten von der Konsole, wie z. B. Host- oder App-Namen.
+ Vom OpsWorks Stacks-Dienst generierte Stack-Konfigurationsdaten, wie z. B. die Ebenen, Apps und Instanzen des Stacks, sowie Details zu jeder Instanz, wie z. B. die IP-Adresse.
+ Benutzerdefinierte JSON-Attribute, die vom Benutzer bereitgestellte Daten enthalten und nahezu denselben Zweck erfüllen können wie Data Bags.
OpsWorks Stacks installiert für jedes Lebenszyklusereignis eine aktuelle Version der Stack-Konfiguration und der Bereitstellungsattribute auf jeder Instanz, bevor der Chef-Lauf des Events gestartet wird. Die Daten werden den Rezepten mit der Standardsyntax `node[:attribute][:child_attribute][...]` zur Verfügung gestellt. Die Stack-Konfigurations- und Bereitstellungsattribute enthalten z. B. den Stack-Namen `node[:opsworks][:stack][:name]`.
Der folgende Auszug aus einem der integrierten Rezepte erhält den Stack-Namen und verwendet ihn zum Erstellen einer Konfigurationsdatei.
```
template '/etc/ganglia/gmetad.conf' do
source 'gmetad.conf.erb'
mode '0644'
variables :stack_name => node[:opsworks][:stack][:name]
notifies :restart, "service[gmetad]"
end
```
Viele der Stack-Konfigurations- und Bereitstellungsattributwerte enthalten mehrere Attribute. Sie müssen diese Attribute schrittweise durchlaufen, um die benötigten Informationen zu erhalten. Das folgende Beispiel zeigt einen Auszug aus den Stack-Konfigurations- und Bereitstellungsattributen, die der Einfachheit halber als JSON-Objekt dargestellt werden. Es enthält ein Top-Level-Attribut, `deploy`, mit einem Attribut für jede App des Stacks, die mit dem Kurznamen der App bezeichnet wird.
```
{
...
"deploy": {
"app1_shortname": {
"document_root": "app1_root",
"deploy_to": "deploy_directory",
"application_type": "php",
...
},
"app2_shortname": {
"document_root": "app2_root",
...
}
},
...
}
```
Jedes App-Attribut enthält eine Gruppe von Attributen, die die Merkmale der Anwendung angeben. Das `deploy_to`-Attribut stellt z. B. das Bereitstellungsverzeichnis der App dar. Mit dem folgenden Auszug werden Benutzer, Gruppe und Pfad für das Bereitstellungsverzeichnis der einzelnen Apps festgelegt.
```
node[:deploy].each do |application, deploy|
opsworks_deploy_dir do
user deploy[:user]
group deploy[:group]
path deploy[:deploy_to]
end
...
end
```
Weitere Informationen zu den Stack-Konfigurations- und Bereitstellungsattributen finden Sie unter [Stacks anpassen OpsWorks](customizing.md). Weitere Informationen zu den Bereitstellungsverzeichnissen finden Sie unter [Bereitstellungsrezepte](create-custom-deploy.md).
Chef 11.4-Stacks unterstützen keine Data Bags. Sie können den Stack-Konfigurations- und Bereitstellungsattributen jedoch beliebige Daten hinzufügen, indem Sie eine [benutzerdefinierte JSON](workingstacks-json.md) angeben. Ihre Rezepte können dann mit der standardmäßigen Chef-Knotensyntax auf die Daten zugreifen. Weitere Informationen finden Sie unter [Nutzen eines benutzerdefinierten JSON-Objekts](workingcookbook-json-override.md).
Wenn Sie die Funktionalität einer verschlüsselten Datentasche benötigen, besteht eine Möglichkeit darin, vertrauliche Attribute an einem sicheren Ort wie einem privaten Amazon S3 S3-Bucket zu speichern. Ihre Rezepte können dann das [AWS Ruby SDK](https://aws.amazon.com/documentation/sdkforruby/) verwenden, das auf allen OpsWorks Stacks-Instances installiert ist, um die Daten aus dem Bucket herunterzuladen.
**Anmerkung**
Jede OpsWorks Stacks-Instance hat ein Instance-Profil. Die zugehörige [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html) gibt an, auf welche AWS-Ressourcen von Anwendungen zugegriffen werden kann, die auf der Instance ausgeführt werden. Damit Ihre Rezepte auf einen Amazon S3 S3-Bucket zugreifen können, muss die Richtlinie der Rolle eine Aussage ähnlich der folgenden enthalten, die die Berechtigung zum Abrufen von Dateien aus einem bestimmten Bucket erteilt.
```
"Action": ["s3:GetObject"],
"Effect": "Allow",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
```
Weitere Informationen zu Instance-Profilen finden Sie unter [Angeben von Berechtigungen für Apps, die auf Instanzen ausgeführt werden EC2](opsworks-security-appsrole.md).
# Migrieren eines vorhandenen Linux-Stacks auf eine neue Chef-Version
**Wichtig**
Der AWS OpsWorks Stacks Service 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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Sie können die OpsWorks Stacks-Konsole, die API oder die CLI verwenden, um Ihre Linux-Stacks auf eine neuere Chef-Version zu migrieren. Für Ihre Rezepte ist jedoch möglicherweise eine Änderung erforderlich, damit sie mit der neueren Version kompatibel sind. Beachten Sie im Vorfeld der Migration eines Stacks die folgenden Hinweise.
+ Sie können die OpsWorks Stacks-Stack-Versionen nicht von Chef 11 auf Chef 12 ändern, indem Sie den Stack bearbeiten oder klonen. Ein Upgrade der Chef-Hauptversion kann mit dem in diesem Abschnitt beschriebenen Verfahren nicht durchgeführt werden. Weitere Informationen zur Umstellung von Chef 11.10 auf Chef 12 finden Sie unter [Implementieren von Rezepten: Chef 12](workingcookbook-chef12-linux.md).
+ Die Umstellung von einer Chef-Version auf eine andere beinhaltet eine Reihe von Änderungen, die zum Teil grundlegend sind.
Weitere Informationen zur Umstellung von Chef 0.9 auf Chef 11.4 finden Sie unter [Migrieren auf eine neue Chef-Version](#workingcookbook-chef11-migrate). Weitere Informationen zur Umstellung von Chef 11.4 auf Chef 11.10 finden Sie unter [Implementieren von Rezepten: Chef 11.10](workingcookbook-chef11-10.md). Weitere Informationen zur Umstellung von Chef 11.10 auf Chef 12 finden Sie unter [Implementieren von Rezepten: Chef 12](workingcookbook-chef12-linux.md).
+ Chef-Läufe verwenden eine andere Ruby-Version auf Chef 0.9- und Chef 11.4-Stacks (Ruby 1.8.7), Chef 11.10-Stacks (Ruby 2.0.0) und Chef 12-Stacks (Ruby-2.1.6).
Weitere Informationen finden Sie unter [Ruby-Versionen](workingcookbook-ruby.md).
+ Chef 11.10-Stacks nehmen die Rezeptbuchinstallation von Chef 0.9- oder Chef 11.4-Stacks unterschiedlich vor.
Dieser Unterschied kann zu Problemen führen, wenn Sie Stacks mit benutzerdefinierten Rezeptbüchern auf Chef 11.10 migrieren. Weitere Informationen finden Sie unter [Installation und Vorrang von Rezeptbüchern](workingcookbook-chef11-10.md#workingcookbook-chef11-10-override).
Die folgenden Richtlinien werden für das Migrieren eines Chef-Stacks auf eine neuere Chef-Version empfohlen:
**Migrieren eines Stacks auf eine neuere Chef-Version**
1. [Klonen Sie Ihren Produktions-Stack](workingstacks-cloning.md). Klicken Sie auf der Seite **Clone Stack** auf **Advanced >>**, um den Abschnitt **Configuration Management** anzuzeigen, und ändern Sie **Chef version** auf die nächste höhere Version.
**Anmerkung**
Wenn Sie mit einem Chef 0.9-Stack beginnen, können Sie kein Upgrade direkt auf Chef 11.10 durchführen. Sie müssen zunächst ein Upgrade auf Chef 11.4 vornehmen. Wenn Sie Ihren Stack auf Chef 11.10 migrieren möchten, bevor Sie Ihre Rezepte testen, warten Sie 20 Minuten, bis die Aktualisierung ausgeführt wird, und führen Sie dann ein Upgrade des Stacks von 11.4 auf 11.10 durch.
1. Fügen Sie den Layern Instances hinzu und testen Sie die geklonten Stack-Anwendungen und Rezeptbücher auf einem Test- oder Staging-System. Weitere Informationen finden Sie unter [All about Chef ...](https://docs.chef.io/index.html).
1. Wenn die Testergebnisse zufriedenstellend sind, führen Sie einen der folgenden Schritte aus:
+ Wenn dies die gewünschte Chef-Version ist, können Sie den geklonten Stack als Produktions-Stack verwenden oder die Chef-Version auf Ihrem Produktions-Stack zurücksetzen.
+ Wenn Sie einen Chef 0.9-Stack auf Chef 11.10 in zwei Phasen migrieren, wiederholen Sie den Prozess, um den Stack von Chef 11.4 auf Chef 11.10 zu migrieren.
**Anmerkung**
Wenn Sie Rezepte testen, können Sie [über SSH eine Verbindung mit](workinginstances-ssh.md) der Instance herstellen und dann den [Instance-Agenten-CLI](agent.md)-Befehl [run\$1command](agent-run.md) zum Ausführen der mit den verschiedenen Lebenszyklusereignissen verbundenen Rezepte ausführen. Die Agenten-CLI ist besonders nützlich zum Testen von Einrichtungsrezepten, da Sie sie sogar verwenden können, wenn die Einrichtung fehlschlägt und die Instance nicht online ist. Sie können auch den [Setup-Stack-Befehl](workingstacks-commands.md) verwenden, um Einrichtungsrezepte neu zu starten. Dieser Befehl ist jedoch nur verfügbar, wenn die Einrichtung erfolgreich war und die Instance online ist.
Es ist möglich, einen laufenden Stack auf eine neue Chef-Version zu aktualisieren.
**Aktualisieren eines laufenden Stacks auf eine neue Chef-Version**
1. [Bearbeiten Sie den Stack](workingstacks-edit.md), um die Stack-Einstellung **Chef version** zu ändern.
1. Speichern Sie die neuen Einstellungen und warten Sie, bis OpsWorks Stacks die Instanzen aktualisiert hat. Dies dauert normalerweise 15 bis 20 Minuten.
**Wichtig**
OpsWorks Stacks synchronisiert das Chef-Versionsupdate nicht mit Lebenszyklusereignissen. Wenn Sie die Chef-Version auf einem Produktions-Stack aktualisieren möchten, müssen Sie sicherstellen, dass die Aktualisierung abgeschlossen ist, bevor das nächste [Lebenszyklusereignis](workingcookbook-events.md) eintritt. Wenn ein Ereignis eintritt — in der Regel ein Deploy- oder Configure-Ereignis — aktualisiert der Instance-Agent Ihre benutzerdefinierten Kochbücher und führt die dem Ereignis zugewiesenen Rezepte aus, unabhängig davon, ob das Versionsupdate abgeschlossen ist oder nicht. Es gibt keine direkte Methode, um zu bestimmen, ob die Versionsaktualisierung abgeschlossen wurde. In den Bereitstellungsprotokollen ist jedoch die Chef-Version enthalten.
# Ruby-Versionen
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Auf allen Instanzen in einem Linux-Stack ist Ruby installiert. OpsWorks Stacks installiert auf jeder Instanz ein Ruby-Paket, mit dem Chef-Rezepte und der Instanzagent ausgeführt werden. OpsWorks Stacks bestimmt die Ruby-Version anhand der Chef-Version, auf der der Stack ausgeführt wird. Ändern Sie diese Version nicht, da hierdurch der Instance-Agent deaktiviert werden könnte.
OpsWorks Stacks installiert keine Ruby-Anwendung, die auf Windows-Stacks ausführbar ist. Der Chef 12.2-Client wird mit Ruby 2.0.0 p451 geliefert, aber die ausführbare Ruby-Datei wird nicht zur PATH-Umgebungsvariablen der Instanz hinzugefügt. Sie können mit dieser ausführbaren Datei auch den Ruby-Code ausführen, er befindet sich im Verzeichnis `\opscode\chef\embedded\bin\ruby.exe` auf Ihrem Windows-Laufwerk.
Die folgende Tabelle fasst die Ruby-Versionen von Stacks zusammen. OpsWorks Die verfügbaren Ruby-Anwendungsversionen hängen auch vom Betriebssystem der Instance ab. Weitere Informationen dazu und zu den verfügbaren Patch-Versionen finden Sie unter [OpsWorks Stacks-Betriebssysteme](workinginstances-os.md).
| Chef-Version | Chef-Ruby-Version | Verfügbare Ruby-Anwendungsversionen |
| --- | --- | --- |
| 0.9 (c) | 1.8.7 | 1.8.7(a), 1.9.3(e), 2.0.0 |
| 11.4 (c) | 1.8.7 | 1.8.7(a), 1.9.3(e), 2.0.0, 2.1, 2.2.0, 2.3 |
| 11.10 | 2.0.0-p481 | 1.9.3(c, e), 2.0.0, 2.1, 2.2.0, 2.3, 2.6.1 |
| 12 (b) | 2.1.6, 2.2.3 | Keine |
| 12.22 (d) | 2.3.6 | Keine |
**(a)** Nicht verfügbar für Amazon Linux 2014.09 und höher, Red Hat Enterprise Linux (RHEL) oder Ubuntu 14.04 LTS.
**(b)** Nur auf Linux-Stacks verfügbar.
**(c)** Nicht für RHEL verfügbar.
**(d)** Nur auf Windows-Stacks verfügbar. Hauptversion ist 12.2. Die aktuelle Unterversion ist 12.22.
**(e)** Deprecation abgeschlossen; Unterstützung ist abgelaufen.
Die Installationsverzeichnisse hängen von der Chef-Version ab:
+ Anwendungen verwenden die ausführbare Datei `/usr/local/bin/ruby` für alle Chef-Versionen.
+ Bei Chef 0.9 und 11.4 verwenden der Instance-Agent und die Chef-Rezepte die ausführbare Datei `/usr/bin/ruby`.
+ Bei Chef 11.10 verwenden der Instance-Agent und die Chef-Rezepte die ausführbare Datei `/opt/aws/opsworks/local/bin/ruby`.
# Installieren von benutzerdefinierten Rezeptbüchern
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Um auf einem Stack ein benutzerdefiniertes Rezeptbuch zu installieren und zu verwenden, müssen Sie auf dem Stack zunächst benutzerdefinierte Rezepte aktivieren, falls Sie dies noch nicht getan haben. Dann müssen Sie die Repository-URL sowie alle erforderlichen Informationen wie etwa ein Passwort bereitstellen.
**Wichtig**
Nachdem Sie den Stack so konfiguriert haben, dass er benutzerdefinierte Kochbücher unterstützt, installiert OpsWorks Stacks Ihre Kochbücher beim Start automatisch auf allen neuen Instanzen. Sie müssen OpsWorks Stacks jedoch ausdrücklich anweisen, neue oder aktualisierte Kochbücher auf allen vorhandenen Instanzen zu installieren, indem Sie den Stack-Befehl [**Update**](workingstacks-commands.md) Custom Cookbooks ausführen. Weitere Informationen finden Sie unter [Aktualisieren von benutzerdefinierten Rezeptbüchern](workingcookbook-installingcustom-enable-update.md). Überprüfen Sie vor dem Aktivieren der Option **Use custom Chef cookbooks (Verwenden von benutzerdefinierten Chef-Rezeptbüchern)** auf einem Stack, ob die verwendeten benutzerdefinierten und Community-Rezeptbücher die auf dem Stack verwendete Chef-Version unterstützen.
**So konfigurieren Sie einen Stack für benutzerdefinierte Rezeptbücher:**
1. Klicken Sie auf der Seite des Stacks auf **Stack Settings**, um die Seite **Settings** anzuzeigen. Klicken Sie auf **Edit**, um die Einstellungen zu bearbeiten.
1. Schalten Sie **Use custom Chef Cookbooks** zu **Yes** um.
![\[Bearbeiten der Stack-Einstellungen\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/stack_settings_edit.png)
1. Konfigurieren Sie Ihre benutzerdefinierten Rezeptbücher.
Wenn Sie fertig sind, klicken Sie auf **Save**, um den aktualisierten Stack zu speichern.
## Festlegen eines benutzerdefinierten Rezeptbuch-Repositorys
Auf Linux-Stacks können benutzerdefinierte Rezeptbücher aus den folgenden Repository-Typen installiert werden:
+ HTTP- oder Amazon S3 S3-Archive.
Sie können entweder öffentlich oder privat sein, aber Amazon S3 ist in der Regel die bevorzugte Option für ein privates Archiv.
+ Mit Git- und Subversion-Repositorys können Sie die Quelle steuern und mehrere Versionen bereitstellen.
Windows Stacks können benutzerdefinierte Kochbücher aus Amazon S3 S3-Archiven und Git-Repositorys installieren.
Alle Repository-Typen haben die folgenden Pflichtfelder.
+ **Repository-Typ — Der Repository-Typ**
+ **Repository-URL** — Die Repository-
OpsWorks Stacks unterstützt öffentlich gehostete Git-Repository-Sites wie [GitHub](https://github.com/)[Bitbucket](https://bitbucket.org) sowie privat gehostete Git-Server. Für Git-Repositorys müssen Sie abhängig davon, ob es sich um ein öffentliches oder privates Repository handelt, eines der folgenden URL-Formate verwenden. Dieselben URL-Richtlinien gelten auch für Git-Submodule.
Verwenden Sie für öffentliche Git-Repositorys HTTPS oder Git-Protokolle für schreibgeschützten Zugriff:
+ Git schreibgeschützt —. `git://github.com/amazonwebservices/opsworks-example-cookbooks.git`
+ HTTPS —. `https://github.com/amazonwebservices/opsworks-example-cookbooks.git`
Für ein privates Git-Repository müssen Sie das read/write SSH-Format verwenden, wie in den folgenden Beispielen gezeigt:
+ Github-Repositorys —. `git@github.com:project/repository`
+ Repositorys auf einem Git-Server — `user@server:project/repository`
Die übrigen Einstellungen sind abhängig vom Repository-Typ und werden in den folgenden Abschnitten beschrieben.
### HTTP-Archiv
Wenn Sie **Http Archive** für **Repository type** auswählen, werden zwei zusätzliche Einstellungen angezeigt, die Sie für passwortgeschützte Archive konfigurieren müssen.
+ **Benutzername** — Ihr Benutzername
+ **Passwort — Ihr Passwort**
### Amazon S3 S3-Archiv
Wenn Sie **S3 Archive (S3-Archiv)** für **Repository type (Repository-Typ)** auswählen, werden die folgenden zusätzlichen, optionalen Einstellungen angezeigt. OpsWorks Stacks kann mithilfe von EC2 Amazon-Rollen (Host Operating System Manager-Authentifizierung) auf Ihr Repository zugreifen, unabhängig davon, ob Sie die OpsWorks Stacks-API oder die Stacks-Konsole verwenden.
+ **Zugriffsschlüssel-ID** — Eine AWS-Zugriffsschlüssel-ID, z. B. AKIAIOSFODNN7EXAMPLE
+ **Geheimer Zugriffsschlüssel** — Der entsprechende geheime AWS-Zugriffsschlüssel, z. wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY B.
### Git-Repository
Wenn Sie **Git** unter **Source Control (Quellkontrolle)** auswählen, werden die beiden folgenden zusätzlichen optionalen Einstellungen angezeigt:
**Repository SSH key (Repository-SSH-Schlüssel)**
Sie müssen einen SSH-Bereitstellungsschlüssel für den Zugriff auf private Git-Repositorys angeben. Bei Git-Submodulen muss der angegebene Schlüssel Zugriff auf diese Submodule haben. Weitere Informationen finden Sie unter [Verwenden von Git-Repository-SSH-Schlüsseln](workingapps-deploykeys.md).
Für den SSH-Bereitstellungsschlüssel ist kein Passwort erforderlich. OpsWorks Stacks hat keine Möglichkeit, es weiterzugeben.
**Branch/Revision**
Wenn das Repository mehrere Branches hat, lädt OpsWorks Stacks standardmäßig den Master-Branch herunter. Um einen bestimmten Branch zu spezifizieren, geben Sie den Branch-Namen, den SHA1 Hash oder den Tag-Namen ein. Um einen bestimmten Commit festzulegen, geben Sie die vollständige Commit-ID mit 40 Hexadezimalziffern an.
### Subversion-Repository
Wenn Sie **Subversion** unter **Source Control (Quellkontrolle)** auswählen, werden die folgenden zusätzlichen Einstellungen angezeigt:
+ **Benutzername** — Ihr Benutzername für private Repositorys.
+ **Passwort** — Ihr Passwort für private Repositorys.
+ **Revision** — [Optional] Der Revisionsname, falls Sie mehrere Revisionen haben.
Um eine Verzweigung oder ein Tag anzugeben, müssen Sie die Repository-URL wie im folgenden Beispiel anpassen: **http://repository\$1domain/repos/myapp/branches/my-apps-branch** oder **http://repository\$1domain\$1name/repos/calc/myapp/my-apps-tag**.
# Aktualisieren von benutzerdefinierten Rezeptbüchern
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Wenn du OpsWorks Stacks benutzerdefinierte Kochbücher zur Verfügung stellst, erstellen die integrierten Setup-Rezepte auf jeder neu gestarteten Instanz einen lokalen Cache und laden die Kochbücher in den Cache herunter. OpsWorks Stacks führt dann Rezepte aus dem Cache aus, nicht aus dem Repository. Wenn Sie die benutzerdefinierten Kochbücher im Repository ändern, müssen Sie sicherstellen, dass die aktualisierten Kochbücher in den lokalen Caches Ihrer Instanzen installiert sind. OpsWorks Stacks stellt automatisch die neuesten Kochbücher auf neuen Instanzen bereit, wenn diese gestartet werden. Für vorhandene Instances ist die Situation jedoch eine andere:
+ Sie müssen aktualisierte benutzerdefinierte Rezeptbücher manuell auf Online-Instances bereitstellen.
+ Sie müssen aktualisierte benutzerdefinierte Rezeptbücher nicht für Instance-Speicher-gestützte Offline-Instances bereitstellen, einschließlich last- und zeitbasierter Instances.
OpsWorks Stacks stellt automatisch die aktuellen Kochbücher bereit, wenn die Instanzen neu gestartet werden.
+ Sie müssen EBS-gesicherte 24/7-Instances offline starten, die nicht last- oder zeitbasiert sind.
+ Sie können Offline-EBS-gestützte last- und zeitbasierte Instances nicht starten, so dass es am einfachsten ist, Offline-Instances zu löschen und neue Instances hinzuzufügen, um diese zu ersetzen.
Da es sich jetzt um neue Instanzen handelt, stellt OpsWorks Stacks beim Start der Instanzen automatisch die aktuellen benutzerdefinierten Kochbücher bereit.
**So aktualisieren Sie benutzerdefinierte Rezeptbücher:**
1. Aktualisieren Sie Ihr Repository mit den geänderten Kochbüchern. OpsWorks Stacks verwendet die Cache-URL, die Sie bei der ursprünglichen Installation der Kochbücher angegeben haben. Daher sollten sich der Name der Kochbuch-Stammdatei, der Speicherort des Repositorys und die Zugriffsrechte nicht ändern.
+ Ersetzen Sie bei Amazon S3- oder HTTP-Repositorys die ursprüngliche .zip-Datei durch eine neue .zip-Datei mit demselben Namen.
+ Für Git- oder Subversion-Repositorys, [bearbeiten Sie Ihre Stack-Einstellungen](workingstacks-edit.md), um das Feld **Branch/Revision** zur neuen Version zu ändern.
1. Klicken Sie auf der Seite des Stacks auf **Run Command** und wählen Sie den Befehl **Update Custom Cookbooks** aus.
![\[Ausführen der Befehlsseite\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/update_cookbooks.png)
1. Fügen Sie bei Bedarf einen Kommentar hinzu.
1. Geben Sie optional ein benutzerdefiniertes JSON-Objekt für den Befehl an, um der Stack-Konfiguration und den Bereitstellungsattributen, die OpsWorks Stacks auf den Instances installiert, benutzerdefinierte Attribute hinzuzufügen. Weitere Informationen erhalten Sie unter [Nutzen eines benutzerdefinierten JSON-Objekts](workingstacks-json.md) und [Überschreiben der Attribute](workingcookbook-attributes.md).
1. Standardmäßig aktualisiert OpsWorks Stacks die Kochbücher auf jeder Instanz. Um anzugeben, welche Instances zu aktualisieren ist, wählen Sie die entsprechenden Instances aus der Liste am Ende der Seite aus. Um alle Instances in einem Layer auszuwählen, wählen Sie das entsprechenden Layer-Kontrollkästchen in der linken Spalte aus.
1. Klicken Sie auf **Benutzerdefinierte Kochbücher aktualisieren, um die aktualisierten Kochbücher** zu installieren. OpsWorks Stacks löscht die zwischengespeicherten benutzerdefinierten Kochbücher auf den angegebenen Instanzen und installiert die neuen Kochbücher aus dem Repository.
**Anmerkung**
Dieser Vorgang ist nur für vorhandene Instances erforderlich, die alte Versionen der Rezeptbücher in ihren Caches haben. Wenn Sie anschließend Instanzen zu einer Ebene hinzufügen, stellt OpsWorks Stacks die Kochbücher bereit, die sich derzeit im Repository befinden, sodass sie automatisch die neueste Version erhalten.
# Ausführen von Rezepten
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Sie können Rezepte auf zwei Arten ausführen:
+ Automatisch, indem Sie sie einem passenden Lebenszyklusereignis eines Layers zuweisen
+ Manuell, indem Sie den [Stack-Befehl "Execute Recipes"](workingstacks-commands.md) ausführen oder die Agent CLI verwenden
**Topics**
+ [OpsWorks Stapelt Lifecycle-Ereignisse](workingcookbook-events.md)
+ [Automatisches Ausführen von Rezepten](workingcookbook-assigningcustom.md)
+ [Manuelles Ausführen von Rezepten](workingcookbook-manual.md)
# OpsWorks Stapelt Lifecycle-Ereignisse
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Jeder Layer verfügt über fünf Lebenszyklusereignisse, denen jeweils Rezepte zugeordnet sind, die sich von Layer zu Layer unterscheiden. Wenn ein Ereignis auf einer Instance eines Layers auftritt, führt OpsWorks Stacks die entsprechenden Rezepte automatisch aus. Implementieren Sie benutzerdefinierte Rezepte und [weisen Sie sie den entsprechenden Ereignissen für jede Ebene zu, um auf diese Ereignisse](workingcookbook-assigningcustom.md) individuell reagieren zu können. OpsWorks Stacks führt diese Rezepte nach den integrierten Rezepten des Events aus.
**Setup**
Dieses Ereignis tritt nach dem Hochfahren einer Instance auf. Sie können das Setup Ereignis auch manuell auslösen, indem Sie den [Befehl Setup stack](workingstacks-commands.md) verwenden. OpsWorks Stacks führt Rezepte aus, die die Instanz entsprechend ihrer Ebene einrichten. Wenn die Instanz beispielsweise Mitglied der Rails App Server-Schicht ist, installieren die Setup Rezepte Apache, Ruby Enterprise Edition, Passenger und Ruby on Rails.
Während eines **Setup**-Ereignisses muss eine Instance offline gehen. Da die Instance während des **Setup**-Lebenszyklusereignisses nicht den Status **Online** hat, werden Instances, auf denen Sie **Setup**-Ereignisse ausführen, vom Load Balancer getrennt.
**Configure**
Dieses Ereignis tritt auf allen Instances des Stacks auf, wenn eines der folgenden passiert:
+ Eine Instance geht online oder offline.
+ Sie [ordnen einer Instance eine Elastic IP-Adresse zu](resources-attach.md#resources-attach-eip) oder Sie [heben die Zuordnung einer Elastic IP-Adresse zu einer Instance auf](resources-detach.md#resources-detach-eip).
+ Sie [fügen einem Layer einen Elastic Load Balancing Load Balancer](layers-elb.md) hinzu oder trennen ihn von einem Layer.
Nehmen wir zum Beispiel an, Ihr Stack hat die Instanzen A, B und C und Sie starten eine neue Instance D. Nachdem D die Ausführung seiner Einrichtungsrezepte abgeschlossen hat, löst OpsWorks Stacks das Configure Ereignis für A, B, C und D aus. Wenn Sie A anschließend beenden, löst OpsWorks Stacks das Configure Ereignis für B, C und D aus. OpsWorks Stacks reagiert auf das Configure Ereignis, indem es die Configure Rezepte jeder Ebene ausführt, die die Konfiguration der Instanzen aktualisieren, sodass sie den aktuellen Satz von Online-Instanzen widerspiegelt. Das Configure-Ereignis ist daher ein guter Zeitpunkt, um Konfigurationsdateien wiederherzustellen. Die HAProxy Configure Rezepte konfigurieren beispielsweise den Load Balancer neu, um Änderungen in der Gruppe der Online-Anwendungsserver-Instanzen zu berücksichtigen.
Sie können das Konfigurationsereignis auch manuell mithilfe des [Stack-Befehls "Configure"](workingstacks-commands.md) auslösen.
**Deploy**
Dieses Ereignis tritt auf, wenn Sie den Befehl **Deploy** ausführen, um eine Anwendung für Anwendungsserver-Instances bereitzustellen. Auf den Instances werden Rezepte zur Bereitstellung der Anwendung und zugehöriger Dateien aus einem Repository für die Instances des Layers ausgeführt. Bei Rails-Anwendungsserver-Instances beispielsweise laden die Deploy-Rezepte eine bestimmte Ruby-Anwendung herunter und weisen [Phusion Passenger](https://www.phusionpassenger.com/) an, diese neu zu laden. Sie können Deploy auch auf anderen Instances ausführen, um beispielsweise die Konfiguration der Instances zu aktualisieren und auf die neu bereitgestellte App abzustimmen.
Der Befehl "Setup" beinhaltet den Befehl "Deploy", nach den Einrichtungsrezepten werden also auch die Bereitstellungsrezepte ausgeführt.
**Undeploy**
Dieses Ereignis tritt auf, wenn Sie eine App löschen oder den Befehl Undeploy ausführen, um eine Anwendung von Anwendungsserver-Instances zu löschen. Auf den angegebenen Instances werden Rezepte ausgeführt, um alle Anwendungsversionen zu löschen und die Instances zu bereinigen.
**Shutdown**
Dieses Ereignis tritt ein, nachdem Sie OpsWorks Stacks angewiesen haben, eine Instance herunterzufahren, aber bevor die zugehörige EC2 Amazon-Instance tatsächlich beendet wird. OpsWorks Stacks führt Rezepte aus, um Bereinigungsaufgaben wie das Herunterfahren von Diensten auszuführen.
Wenn Sie dem Layer einen Elastic Load Balancing Load Balancer hinzugefügt und die [Unterstützung für den Verbindungsabbau aktiviert haben, wartet OpsWorks Stacks](layers-elb.md), bis der Verbindungsabbau abgeschlossen ist, bevor das Ereignis ausgelöst wird. Shutdown
Nach dem Auslösen eines Shutdown Ereignisses OpsWorks gewährt Stacks den Shutdown Rezepten eine bestimmte Zeit, um ihre Aufgaben auszuführen, und stoppt oder beendet dann die Amazon-Instance. EC2 Der Standardwert für den Shutdown-Timeout ist 120 Sekunden. Wenn Sie mehr Zeit benötigen, um Shutdown-Rezepte auszuführen, können Sie den Timeout-Wert in der [Layer-Konfiguration anpassen](workinglayers-basics-edit.md#workinglayers-basics-edit-general). Weitere Informationen über Instance-Shutdown finden Sie unter [Anhalten einer Instance](workinginstances-starting.md#workinginstances-starting-stop).
**Anmerkung**
[Ein Neustart einer Instance](workinginstances-starting.md#workinginstances-starting-reboot) löst keine Lebenszyklusereignisse aus.
Weitere Erläuterungen zu den App-Befehlen Deploy und Undeploy finden Sie unter [Bereitstellen von Anwendungen](workingapps-deploying.md).
Nachdem eine Instance vollständig hochgefahren wurde, sieht die weitere Startup-Sequenz wie folgt aus:
1. OpsWorks Stacks führt die integrierten Setup Rezepte der Instance aus, gefolgt von allen benutzerdefinierten Rezepten. Setup
1. OpsWorks Stacks führt die integrierten Deploy Rezepte der Instanz aus, gefolgt von allen benutzerdefinierten Deploy Rezepten.
Die Instance ist jetzt online.
1. OpsWorks Stacks löst ein Configure Ereignis auf allen Instanzen im Stack aus, einschließlich der neu gestarteten Instanz.
OpsWorks Stacks führt die integrierten Configure Rezepte der Instances aus, gefolgt von allen benutzerdefinierten Rezepten. Configure
**Anmerkung**
Um sich die Lebenszyklusereignisse anzusehen, die auf einer bestimmten Instance aufgetreten sind, rufen Sie die Seite **Instances** auf und klicken Sie auf den Namen der Instance, um die Detailseite zu öffnen. Die Liste der Ereignisse finden Sie im Bereich **Logs** unten auf der Seite. Klicken Sie auf **show** in der Spalte **Log**, um das Chef-Protokoll für ein Ereignis anzusehen. Es enthält detaillierte Informationen zur Verarbeitung des Ereignisses einschließlich der ausgeführten Rezepte. Weitere Informationen zur Deutung der Chef-Protokolle finden Sie unter [Chef-Protokolle](troubleshoot-debug-log.md).
![\[Log entries showing commands, timestamps, and durations for system operations.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/instance_logs.png)
Für jedes Lebenszyklusereignis installiert OpsWorks Stacks auf jeder Instance eine Reihe von [Stackkonfigurations- und Bereitstellungsattributen](workingcookbook-json.md), die den aktuellen Stack-Status und bei Deploy Ereignissen Informationen zur Bereitstellung enthalten. Die Attribute enthalten außerdem auch Informationen zu den verfügbaren Instances, deren IP-Adressen usw. Weitere Informationen finden Sie unter [Attribute für die Stack-Konfiguration und -Bereitstellung](workingcookbook-json.md).
**Anmerkung**
Durch das gleichzeitige Starten oder Anhalten einer großen Anzahl von Instances kann es kurzfristig zu einer großen Anzahl von Configure-Ereignissen kommen. Um unnötige Verarbeitung zu vermeiden, reagiert OpsWorks Stacks nur auf das letzte Ereignis. Die Stack-Konfigurations- und Bereitstellungsattribute des Ereignisses enthalten alle notwendigen Informationen zur Aktualisierung der Stack-Instances für alle anstehenden Änderungen. Dadurch entfällt die Notwendigkeit, auch die früheren Configure Ereignisse zu verarbeiten. OpsWorks **Stacks kennzeichnet die unverarbeiteten Configure Ereignisse als ersetzt.**
# Automatisches Ausführen von Rezepten
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Jeder Layer verfügt über eine Reihe von integrierten Rezepten, die den einzelnen Lebenszyklusereignissen zugeordnet sind. Nicht alle Layer verfügen jedoch über Rezepte für "Bereitstellung aufheben". Wenn ein Lebenszyklusereignis auf einer Instance eintritt, führt OpsWorks Stacks die entsprechenden Rezepte für die zugehörige Ebene aus.
Wenn Sie benutzerdefinierte Kochbücher installiert haben, können Sie OpsWorks Stacks einige oder alle Rezepte automatisch ausführen lassen, indem Sie jedes Rezept dem Lebenszyklusereignis einer Ebene zuweisen. Nach dem Eintreten eines Ereignisses führt OpsWorks Stacks die angegebenen benutzerdefinierten Rezepte nach den integrierten Rezepten der Ebene aus.
**So weisen Sie benutzerdefinierte Rezepte zu den Ereignissen eines Layers hinzu**
1. Klicken Sie auf der Seite **Layers** für den entsprechenden Layer auf **Recipes** und dann auf **Edit**. Wenn Sie noch keine benutzerdefinierten Rezeptbücher aktiviert haben, klicken Sie auf **configure cookbooks**, um die Seite **Settings** des Stacks zu öffnen. Wählen Sie für **Use custom Chef Cookbooks** **Yes** aus und geben Sie die Informationen zum Rezeptbuch-Repository ein. Klicken Sie nun auf **Save** und kehren Sie zur Bearbeitungsseite der Registerkarte **Recipes** zurück. Weitere Informationen finden Sie unter [Installieren von benutzerdefinierten Rezeptbüchern](workingcookbook-installingcustom-enable.md).
1. Geben Sie auf der Registerkarte **Recipes** die benutzerdefinierten Rezepte in die entsprechenden Ereignisfelder ein und klicken Sie auf **\$1**, um sie zur Liste hinzuzufügen. Geben Sie ein Rezept wie folgt an:*cookbook*: *somerecipe* (lassen Sie die `.rb` Erweiterung weg).
![\[Detailseite "Layer"\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/php_edit.png)
Wenn Sie eine neue Instanz starten, führt OpsWorks Stacks automatisch die benutzerdefinierten Rezepte für jedes Ereignis aus, nachdem die Standardrezepte ausgeführt wurden.
**Anmerkung**
Benutzerdefinierte Rezepte werden in der Reihenfolge ausgeführt, in der Sie auf der Konsole eingegeben wurden. Sie können auch ein Metarezept implementieren, um die Rezepte in einer bestimmten Reihenfolge auszuführen.
# Manuelles Ausführen von Rezepten
**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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Rezepte werden zwar üblicherweise automatisch während eines Lebenszyklusereignisses ausgeführt, Sie können sie jedoch auch jederzeit manuell auf bestimmten oder allen Instances eines Stacks ausführen. Dies kann beispielsweise nützlich sein, um Aufgaben auszuführen, die sich keinem Lebenszyklusereignisse zuordnen lassen, wie eine Sicherung der Instances. Wenn Sie ein benutzerdefiniertes Rezept manuell ausführen möchten, muss es in einem Ihrer benutzerdefinierten Rezeptbücher enthalten, aber nicht unbedingt einem Lebenszyklusereignis zugeordnet sein. Wenn Sie ein Rezept manuell ausführen, installiert OpsWorks Stacks dieselben `deploy` Attribute wie bei einem Deploy-Ereignis.
**So führen Sie ein Rezept manuell auf Stack-Instances aus**
1. Klicken Sie auf der Seite **Stack** auf **Run command**. Wählen Sie für **Command** die Option **Execute Recipes** aus.
![\[Der Befehl "Execute Recipes" auf der Seite "Run command"\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/execute_recipe.png)
1. Geben Sie die auszuführenden Rezepte in das Feld **Auszuführende Rezepte ein, indem Sie** das *recipename* Standardformat*cookbookname*:: verwenden. Sie können mehrere Rezepte durch Kommas trennen. Die Rezepte werden in der eingegebenen Reihenfolge ausgeführt.
1. Fügen Sie optional im Feld **Custom Chef JSON** ein benutzerdefiniertes JSON-Objekt ein, um benutzerdefinierte Attribute festzulegen, die in die Stack-Konfigurations- und Bereitstellungsattribute auf den Instances integriert werden. Weitere Informationen zur Verwendung von benutzerdefinierten JSON-Objekten finden Sie unter [Nutzen eines benutzerdefinierten JSON-Objekts](workingstacks-json.md) und [Überschreiben der Attribute](workingcookbook-attributes.md).
1. Wählen Sie unter **Instanzen** die Instanzen aus, auf denen OpsWorks Stacks die Rezepte ausführen soll.
Wenn ein Lebenszyklusereignis eintritt, erhält der OpsWorks Stacks-Agent einen Befehl zur Ausführung der zugehörigen Rezepte. Sie können diese Befehl auch manuell auf bestimmten Instances ausführen. Verwenden Sie dafür den entsprechenden [Stack-Befehl](workingstacks-commands.md) oder den Befehl [run\$1command](agent-run.md) der Agenten CLI. Weitere Informationen zur Verwendung der Agent CLI finden Sie unter [OpsWorks Stacks Agent CLI](agent.md).