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. # Rezeptstruktur **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). Ein Rezeptbuch ist in erster Linie eine Sammlung von *Rezepten*, mit denen zahlreiche Aufgaben auf einer Instance ausgeführt werden können. Um die Implementierung von Rezepten zu verdeutlichen, ist ein einfaches Beispiel hilfreich. Nachfolgend finden Sie das Einrichtungsrezept für den integrierten [HAProxy Layer](layers-haproxy.md). Konzentrieren Sie sich zum jetzigen Zeitpunkt nur auf die allgemeine Struktur. Machen Sie sich keine Gedanken über die Details, sie werden in den nachfolgenden Beispielen veranschaulicht. ``` package 'haproxy' do action :install end if platform?('debian','ubuntu') template '/etc/default/haproxy' do source 'haproxy-default.erb' owner 'root' group 'root' mode 0644 end end include_recipe 'haproxy::service' service 'haproxy' do action [:enable, :start] end template '/etc/haproxy/haproxy.cfg' do source 'haproxy.cfg.erb' owner 'root' group 'root' mode 0644 notifies :restart, "service[haproxy]" end ``` **Anmerkung** Dieses und weitere Beispiele für funktionierende Rezepte und die zugehöriger Dateien finden Sie unter [OpsWorks  Stacks built-in recipes](https://github.com/aws/opsworks-cookbooks). In diesem Beispiel werden die wichtigsten Rezeptelemente vorgestellt, die in den folgenden Abschnitten beschrieben werden. **Topics** + [Ressourcen](#cookbooks-101-basics-structure-resources) + [Flusssteuerung](#cookbooks-101-basics-structure-ruby) + [Eingebundene Rezepte](#cookbooks-101-basics-structure-include) ## Ressourcen Rezepte bestehen zum Großteil aus Chef-*Ressourcen*. Jede gibt einen bestimmten Aspekt des letzten Instance-Status an, z. B. ein zu installierendes Paket oder ein zu startender Service. Im Beispiel werden vier Ressourcen verwendet: + Eine `package` Ressource, die ein installiertes Paket darstellt, in diesem Beispiel einen [HAProxy Server](http://haproxy.1wt.eu/). + Eine `service` Ressource, die einen Dienst darstellt, den HAProxy Dienst für dieses Beispiel. + Zwei `template` Ressourcen, die Dateien darstellen, die aus einer bestimmten Vorlage erstellt werden sollen, zwei HAProxy Konfigurationsdateien für dieses Beispiel. Ressourcen sind eine deklarative Möglichkeit, um den Instance-Status anzugeben. Im Hintergrund ist jeder Ressource ein *Anbieter* zugeordnet, von dem die erforderlichen Aufgaben ausgeführt werden, z. B. Pakete installieren, Verzeichnisse erstellen und konfigurieren und Services starten. Falls die Details der Aufgabe vom jeweiligen Betriebssystem abhängen, verfügt die Ressource über mehrere Anbieter, von denen jeweils der geeignete für das System ausgewählt wird. Bei einem Red Hat Linux-System wird vom `package`-Anbieter `yum` zum Installieren der Pakete verwendet. Auf einem Ubuntu Linux-System verwendet der `package`-Anbieter hingegen `apt-get`. Eine Ressource wird als Ruby-Codeblock im folgenden allgemeinen Format implementiert. ``` resource_type "resource_name" do attribute1 'value1' attribute2 'value2' ... action :action_name notifies : action 'resource' end ``` Die Elemente lauten folgendermaßen: **Ressourcentyp** (Erforderlich) Das Beispiel enthält drei Ressourcentypen, nämlich `package`, `service` und `template`. **Ressourcenname** (Erforderlich) Der Name identifiziert eine bestimmte Ressource und wird gelegentlich als Standardwert für eines der Attribute verwendet. In diesem Beispiel steht `package` für eine "package"-Ressource mit dem Namen `haproxy` und die erste `template`-Ressource steht für eine Konfigurationsdatei mit dem Namen `/etc/default/haproxy`. **Attribute** (Optional) Attribute geben die Ressourcenkonfiguration an. Sie hängen vom Ressourcentyp und davon, wie Sie die Ressource konfigurieren möchten, ab. + Im Beispiel definieren die `template`-Ressourcen explizit mehrere Attribute, die jeweils die Quelle, den Besitzer, die Gruppe und den Modus der erstellten Datei spezifizieren. + Von den im Beispiel verwendeten Ressourcen `package` und `service` werden keine Attribute explizit definiert. Der Ressourcenname ist in der Regel der Standardwert für ein erforderliches Attribut – und häufig ist auch nicht mehr nötig. Beispielsweise ist der Ressourcenname der Standardwert für das `package`-Attribut der `package_name`-Ressource und gleichzeitig auch das einzig erforderliche Attribut. Die so genannten "Wächterattribute" sind besondere Attribute und geben an, wann eine Aktion seitens des Ressourcenanbieters erforderlich ist. Beispielsweise fordert das `only_if`-Attribut den Ressourcenanbieter nur zu einer Aktion auf, sofern eine festgelegte Bedingung erfüllt wird. Das HAProxy Rezept verwendet keine Guard-Attribute, aber sie werden in mehreren der folgenden Beispiele verwendet. **Aktionen und Benachrichtigungen** (Optional) Aktionen und Benachrichtigungen geben an, welche Aufgaben vom Anbieter ausgeführt werden sollen. + Mit `action` wird der Anbieter zu einer bestimmten Aktion aufgefordert, z. B. etwas zu installieren oder zu erstellen. Für jede Ressource sind mehrere ressourcenabhängige Aktionen möglich, eine davon ist immer die Standardaktion. In diesem Beispiel lautet die Aktion für die `package`-Ressource `install` und weist den Anbieter an, das Paket zu installieren. Die erste `template`-Ressource hat kein `action`-Element, daher führt der Anbieter die `create`-Standardaktion aus. + Mit `notifies` wird der Anbieter einer anderen Ressource zur Ausführung einer Aktion aufgefordert. Dies gilt nur, wenn sich der Ressourcenstatus geändert hat. `notifies` wird in der Regel mit Ressourcen wie `template` und `file` für die Aufgabenausführung verwendet, z. B. um den Service nach einer Änderung der Konfigurationsdatei neu zu starten. Ressourcen verfügen nicht über Standardbenachrichtigungen. Wenn eine Benachrichtigung gesendet werden soll, muss für die Ressource explizit ein `notifies`-Element deklariert werden. Im HAProxy Rezept benachrichtigt die zweite `template` Ressource die `service` Haproxy-Ressource, den HAProxy Dienst neu zu starten, falls sich die zugehörige Konfigurationsdatei geändert hat. Manchmal hängen Ressourcen vom Betriebssystem ab. + Einige Ressourcen können nur auf Linux- oder Windows-Systemen verwendet werden. Beispielsweise werden mit [package](https://docs.chef.io/chef/resources.html#package) Pakete auf Linux-Systemen und mit [windows\$1package](https://docs.chef.io/chef/resources.html#windows-package) Pakete auf Windows-Systemen installiert. + Einige Ressourcen können mit einem beliebigen Betriebssystem genutzt werden, haben aber Attribute für ein bestimmtes System. Beispielsweise kann die [file](https://docs.chef.io/chef/resources.html#file)-Ressource sowohl auf Linux- als auch auf Windows-Systemen eingesetzt werden, verfügt aber über unterschiedliche Attributsätze für die Berechtigungskonfiguration. Beschreibungen der Standardressourcen einschließlich der verfügbaren Attribute, Aktionen und Benachrichtigungen für die einzelnen Ressourcen finden Sie unter [About Resources and Providers](https://docs.chef.io/resource.html). ## Flusssteuerung Da es sich bei Rezepten um Ruby-Anwendungen handelt, können Sie Ruby-Steuerungsstrukturen für die Einbindung der Flusssteuerung in ein Rezept verwenden. Beispielsweise können Sie mit der Ruby-Bedingungslogik unterschiedliches Rezeptverhalten auf verschiedenen Systemen erzeugen. Das HAProxy Rezept beinhaltet einen `if` Block, der eine `template` Ressource verwendet, um eine Konfigurationsdatei zu erstellen, aber nur, wenn das Rezept auf einem Debian- oder Ubuntu-System läuft. Ein anderes gängiges Szenario besteht darin, in einer Schleife eine Ressource mehrere Male mit unterschiedlichen Attributeinstellungen auszuführen. Beispielsweise können Sie Verzeichnisse anlegen, indem Sie eine `directory`-Ressource mehrfach mit unterschiedlichen Verzeichnisnamen in einer Schleife ausführen. **Anmerkung** Falls Sie mit Ruby nicht vertraut sind, finden Sie die für die meisten Rezepte erforderlichen Informationen unter [Just Enough Ruby for Chef](https://docs.chef.io/just_enough_ruby_for_chef.html). ## Eingebundene Rezepte Mit `include_recipe` können Sie weitere Rezepte in den Code einbinden, sodass Sie die Rezepte "modularisieren" und denselben Code in mehreren Rezepten verwenden können. Vor der Ausführung des Host-Rezepts ersetzt Chef jedes `include_recipe`-Element durch den angegebenen Rezeptcode. Sie erkennen ein eingebundenes Rezept an der Standardsyntax von Chef, `cookbook_name::recipe_name`, wobei für `recipe_name` die Erweiterung `.rb` fehlt. Das Beispiel beinhaltet ein Rezept`haproxy::service`, das den HAProxy Dienst repräsentiert. **Anmerkung** Falls Sie Rezepte aus einem anderen Rezeptbuch mit `include_recipe` in Rezepte einbinden, die mit Chef 11.10 und neuer ausgeführt werden, müssen Sie in einer `depends`-Anweisung die Abhängigkeit in der Datei `metadata.rb` des Rezeptbuchs deklarieren. Weitere Informationen finden Sie unter [Implementieren von Rezepten: Chef 11.10](workingcookbook-chef11-10.md).