Rezeptstruktur - AWS OpsWorks

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 oder über den AWS Premium-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. Im Folgenden finden Sie das Einrichtungsrezept für die integrierte HAProxy-Ebene. 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 AWS OpsWorks  Stacks built-in recipes.

In diesem Beispiel werden die wichtigsten Rezeptelemente vorgestellt, die in den folgenden Abschnitten beschrieben werden.

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 für ein installiertes Paket steht – in diesem Beispiel ein HAProxy-Server.

  • Eine service-Ressource, die für einen Service steht – in diesem Beispiel der HAProxy-Service.

  • Zwei template-Ressourcen, die für aus einer bestimmten Vorlage zu erstellende Dateien stehen – in diesem Beispiel zwei HAProxy-Konfigurationsdateien.

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. Im HAProxy-Rezept werden keine Wächterattribute genutzt, aber sie werden in einigen 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 haproxy service-Ressource über den Neustart des HAProxy-Service nach einer Änderung der zugehörigen Konfigurationsdatei.

Manchmal hängen Ressourcen vom Betriebssystem ab.

  • Einige Ressourcen können nur auf Linux- oder Windows-Systemen verwendet werden.

    Beispielsweise werden mit package Pakete auf Linux-Systemen und mit 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-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.

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 enthält einen if-Block, der mithilfe einer template-Ressource eine Konfigurationsdatei erstellt, vorausgesetzt, das Rezept wird auf einem Debian- oder Ubuntu-System ausgeführt.

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.

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. Im Beispiel ist das Rezept haproxy::service für den HAProxy-Service enthalten.

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.