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 oder über den AWS Premium-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".

• AWS OpsWorks Stacks installiert einen MySQL-Client nur dann auf den Instanzen eines Stacks, wenn der Stack eine MySQL-Schicht enthält.

• AWS 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

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.

Installation und Vorrang von Rezeptbüchern

Das Verfahren zur Installation von AWS 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 AWS OpsWorks Stacks in der folgenden Reihenfolge zu einem gemeinsamen Verzeichnis zusammengeführt:

1. Integrierte Rezeptbücher.

2. Berkshelf-Rezeptbücher, sofern vorhanden.

3. Benutzerdefinierte Rezeptbücher, sofern vorhanden.

Wenn AWS 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 Namensomeattributes.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 AWS 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 AWS OpsWorks.

Verwenden der Chef-Suchfunktion

Sie können die Chef-search-Methode in Ihren Rezepten verwenden, um Stack-Daten abzufragen. Sie verwenden dieselbe Syntax wie für den Chef-Server, aber AWS OpsWorks Stacks bezieht die Daten vom lokalen Knotenobjekt, anstatt einen Chef-Server abzufragen. Diese Daten umfassen Folgendes:

• Die Stack-Konfigurations- und Bereitstellungsattribute 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. AWS OpsWorks Stacks aktualisiert diese Attribute für jedes Lebenszyklusereignis, 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 AWS 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 AWS OpsWorks Stacks-Dienst zurückgemeldet, sodass Sie nicht von anderen Instanzen aus auf diese Daten zugreifen können, indem Sie die Suche verwenden.

• Benutzerdefinierte deploy-Attribute.

  Sie können das benutzerdefinierte JSON-Objekt bei der Bereitstellung einer App 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, 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 ruft eine Vielzahl von Daten auf einer Instance ab und fügt sie dem Knotenobjekt hinzu. Diese Daten werden lokal gespeichert und nicht dem AWS 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 AWS 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 AWS 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 AWS OpsWorks Stacks-Instanz ausgeführt werden kann. Wenn Sie Code speziell für AWS 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 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. AWS OpsWorks Stacks erhält die Daten allerdings aus den Stack-Konfigurations- und Bereitstellungsattributen der Instance. AWS 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, 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.

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 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.) Insbesondere können Sie mit Berkshelf AWS 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 AWS OpsWorks Stacks-Betriebssysteme.

Zum Verwenden von Berkshelf müssen Sie eine Aktivierung vornehmen, wie in Installieren von benutzerdefinierten Rezeptbüchern 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 die Rezeptbücher in den Quell-URLs, es sei denn, Sie geben ein Repository explizit an. 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_name — (Erforderlich) Gibt den Namen des Kochbuches an.

  Wenn Sie keine weiteren Felder angeben, installiert Berkshelf das Rezeptbuch mit den angegebenen Quell-URLs.

• cookbook_version — (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_options — (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 AWS 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.

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.

• 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 AWS 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. AWS OpsWorks Stacks läuft berks install bei jedem Koch-Lauf, sodass Ihre Berkshelf-Kochbücher für jedes Lebenszyklusereignis 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.

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.