Konfigurationsrezepte - 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.

Konfigurationsrezepte

Wichtig

Das Tool AWS OpsWorks Stacks Der Dienst hat am 26. Mai 2024 das Ende seiner Nutzungsdauer erreicht und wurde sowohl für neue als auch für bestehende Kunden deaktiviert. Wir empfehlen Kunden dringend, ihre Workloads so bald wie möglich auf andere Lösungen zu migrieren. Wenn Sie Fragen zur Migration haben, wenden Sie sich an AWS Support Team ein AWS Re:post oder durch AWS Premium-Support.

Konfigurationsrezepte werden dem Configure-Lebenszyklusereignis des Layers zugewiesen, das auf allen Instances des Stacks stattfindet, wenn eine Instance in den Online-Status wechselt oder diesen verlässt. Sie verwenden Konfigurationsrezepte, um die Konfiguration einer Instance so anzupassen, dass in entsprechender Weise auf die Änderung reagiert wird. Wenn Sie ein Konfigurationsrezept implementieren, sollten Sie bedenken, dass sich eine Stack-Konfigurationsänderung möglicherweise auf Instances auswirkt, die nichts mit diesem Layer zu tun haben. Das Rezept muss entsprechend reagieren können, was in einigen Fällen auch bedeuten kann, dass nichts durchgeführt wird.

tomcat::configure

Das tomcat::configure-Rezept ist für das Configure-Lebenszyklusereignis eines Layers bestimmt.

include_recipe 'tomcat::context' # Optional: Trigger a Tomcat restart in case of a configure event, if relevant # settings in custom JSON have changed (e.g. java_opts/JAVA_OPTS): #include_recipe 'tomcat::container_config'

Das tomcat::configure-Rezept ist grundsätzlich ein Metarezept, das zwei abhängige Rezepte ausführt.

  1. Das tomcat::context-Rezept erstellt eine Webanwendungs-Kontextkonfigurationsdatei.

    In dieser Datei werden die JDBC Ressourcen konfiguriert, die Anwendungen für die Kommunikation mit der SQL My-Instanz verwenden, wie im nächsten Abschnitt beschrieben. Wenn Sie dieses Rezept als Reaktion auf ein Konfigurationsereignis ausführen, kann der Layer die Webanwendungs-Kontextkonfigurationsdatei aktualisieren, wenn sich der Datenbank-Layer geändert hat.

  2. Das tomcat::container_config-Einrichtungsrezept wird nochmals ausgeführt, um Änderungen in der Container-Konfiguration zu erfassen.

Das include für tomcat::container_config wird für dieses Beispiel auskommentiert. Wenn Sie die Tomcat-Einstellungen mithilfe von Benutzerdefiniert ändern JSON möchten, können Sie den Kommentar entfernen. Ein Configure-Lebenszyklusereignis führt sogar tomcat::container_config aus, wodurch die zu Tomcat gehörenden Konfigurationsdateien aktualisiert werden, wie in tomcat::container_config beschrieben, und startet den Tomcat-Service neu.

tomcat::context

Das Tomcat-Kochbuch ermöglicht Anwendungen den Zugriff auf einen SQL My-Datenbankserver, der auf einer separaten Instanz ausgeführt werden kann, mithilfe eines J2EE-Objekts. DataSource Mit Tomcat können Sie die Verbindung aktivieren, indem Sie eine Webanwendungs-Kontextkonfigurationsdatei für jede Anwendung erstellen und installieren. Diese Datei definiert die Beziehung zwischen der Anwendung und der JDBC Ressource, die die Anwendung für die Kommunikation mit der Datenbank verwendet. Weitere Informationen finden Sie unter The Context Container.

Der Hauptzweck des tomcat::context-Rezepts ist die Erstellung dieser Konfigurationsdatei.

include_recipe 'tomcat::service' node[:deploy].each do |application, deploy| context_name = deploy[:document_root].blank? ? application : deploy[:document_root] template "context file for #{application} (context name: #{context_name})" do path ::File.join(node['tomcat']['catalina_base_dir'], 'Catalina', 'localhost', "#{context_name}.xml") source 'webapp_context.xml.erb' owner node['tomcat']['user'] group node['tomcat']['group'] mode 0640 backup false only_if { node['datasources'][context_name] } variables(:resource_name => node['datasources'][context_name], :webapp_name => application) notifies :restart, resources(:service => 'tomcat') end end

Zusätzlich zu den Tomcat-Kochbuchattributen verwendet dieses Rezept die Stack-Konfiguration und die Deployment-Attribute AWS OpsWorks Stacks wird mit dem Configure-Ereignis installiert. Das Tool AWS OpsWorks Der Stacks-Dienst fügt dem Knotenobjekt jeder Instanz Attribute hinzu, die die Informationen enthalten, die Rezepte normalerweise mithilfe von Datenbeuteln oder Suchen abrufen würden, und installiert die Attribute auf jeder Instanz. Die Attribute enthalten detaillierte Informationen über die Stack-Konfiguration, bereitgestellte Apps und benutzerdefinierte Daten, die ein Benutzer einbeziehen möchte. Rezepte können Daten von Attributen der Stack-Konfiguration und -Bereitstellung mithilfe von standardmäßiger Chef-Knotensyntax abrufen. Weitere Informationen finden Sie unter Attribute für die Stack-Konfiguration und -Bereitstellung. Mit Chef 11.10-Stacks können Sie auch die Chef-Suche verwenden, um Daten der Stack-Konfiguration und -Bereitstellung abzurufen. Weitere Informationen finden Sie unter Verwenden der Chef-Suchfunktion.

deployattributes bezieht sich auf den [:deploy] Namespace, der bereitstellungsbezogene Attribute enthält, die über die Konsole definiert oder generiert API werden AWS OpsWorks Stacks-Dienst. Das deploy-Attribut enthält ein Attribut für jede bereitgestellte Anwendung, wobei die Kurzbezeichnung der Anwendung verwendet wird. Jedes Anwendungsattribut enthält eine Reihe von Attributen, die die Anwendung charakterisieren, wie z. B. das Dokumenten-Stammverzeichnis ([:deploy][:appname][:document_root]).

Das context-Rezept stellt zuerst sicher, dass der Service für diese Chef-Ausführung definiert ist, indem tomcat::service aufgerufen wird. Anschließend definiert es eine context_name-Variable, die den Namen der Konfigurationsdatei darstellt, ohne die .xml-Erweiterung. Wenn Sie das standardmäßige Dokumenten-Stammverzeichnis verwenden, wird context_name auf den Kurznamen der Anwendung festgelegt. Andernfalls wird es auf das angegebene Dokumenten-Stammverzeichnis festgelegt. In dem unter besprochenen Beispiel wird das Stammverzeichnis des Dokuments auf Erstellen eines Stacks und Ausführen einer Anwendung festgelegt"ROOT", sodass der Kontext ROOT und die Konfigurationsdatei benannt ROOT.xml ist.

Der Großteil des Rezepts geht die Liste der bereitgestellten Anwendungen durch und verwendet für jede Anwendung die Vorlage webapp_context.xml.erb zur Erstellung einer Kontextkonfigurationsdatei. Das Beispiel stellt nur eine Anwendung bereit, die Definition des deploy-Attributs erfordert aber dennoch, dass Sie es als eine Liste von Anwendungen behandeln.

Die Vorlage webapp_context.xml.erb ist nicht betriebssystemspezifisch. Sie befindet sich also im Unterverzeichnis templates des Verzeichnisses default.

Das Rezept erstellt die Konfigurationsdatei wie folgt:

  • Unter Verwendung von Standardattributwerten wird der Name der Konfigurationsdatei auf context_name.xml festgelegt und im Verzeichnis /etc/tomcat6/Catalina/localhost/ installiert.

    Der ['datasources'] Knoten aus den Stack-Konfigurationsattributen enthält ein oder mehrere Attribute, von denen jedes der JDBC Datenressource, die die zugehörige Anwendung für die Kommunikation mit der Datenbank verwendet, einen Kontextnamen zuordnet. Der Knoten und sein Inhalt werden JSON bei der Erstellung des Stacks mit custom definiert, wie weiter unten unter beschriebenErstellen eines Stacks und Ausführen einer Anwendung. Das Beispiel hat ein einzelnes Attribut, das den ROOT Kontextnamen einer JDBC Ressource namens jdbc/mydb zuordnet.

  • Mithilfe von Standardattributwerten werden sowohl der Benutzer als auch die Gruppe der Datei auf die vom Tomcat-Paket definierten Werte festgelegt: tomcat (Amazon Linux) oder tomcat6 (Ubuntu).

  • Die template-Ressource erstellt die Konfigurationsdatei nur dann, wenn der ['datasources']-Knoten vorhanden ist und ein context_name-Attribut enthält.

  • Die Ressource template definiert die beiden Variablen resource_name und webapp_name.

    resource_name wird auf den Ressourcennamen festgelegt, der context_name zugeordnet ist, und webapp_name auf den Kurznamen der Anwendung festgelegt.

  • Die template-Ressource startet den Tomcat-Service neu, um die Änderungen zu laden und zu aktivieren.

Die Vorlage webapp_context.xml.erb besteht aus einem Context-Element, das ein Resource-Element mit einem eigenen Satz an Attributen enthält.

Die Resource Attribute kennzeichnen die Kontextkonfiguration:

  • name — Der JDBC Ressourcenname, der auf den in tomcat::context definierten resource_name Wert gesetzt ist.

    Für das Beispiel wird der Ressourcenname auf "jdbc/mydb" festgelegt.

  • auth und type — Dies sind Standardeinstellungen für JDBC DataSource Verbindungen.

  • maxActivemaxIdle, und maxWait— Die maximale Anzahl von aktiven und inaktiven Verbindungen sowie die maximale Wartezeit, bis eine Verbindung zurückgegeben wird.

  • username und password — Der Benutzername und das Root-Passwort der Datenbank, die aus den deploy Attributen abgerufen werden.

  • driverClassName— Der Klassenname des JDBC Fahrers, der auf Mein SQL Treiber eingestellt ist.

  • url — Die VerbindungURL.

    Das Präfix hängt von der Datenbank ab. Sie sollte jdbc:mysql für MySQL, für Postgres und jdbc:postgresql jdbc:sqlserver für SQL Server auf eingestellt sein. Das Beispiel setzt den Wert aufURL, wobei jdbc:mysql://host_IP_Address:3306:simplejsp simplejsp ist der Kurzname der App.

  • factory — Die DataSource Factory, die für Meine SQL Datenbanken erforderlich ist.

Weitere Informationen zu dieser Konfigurationsdatei finden Sie im DataSources Thema Using des Tomcat-Wikis.