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
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
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.
-
Das
tomcat::context
-Rezept erstellt eine Webanwendungs-Kontextkonfigurationsdatei.Diese Datei konfiguriert die JDBC-Ressourcen, die Anwendungen verwenden, um mit der MySQL-Instance zu kommunizieren, 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.
-
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 ein benutzerdefiniertes JSON-Objekt zum Ändern von Tomcat-Einstellungen verwenden 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 es Anwendungen, mithilfe eines DataSourceJ2EE-Objekts
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 Bereitstellungsattribute, die Stacks mit dem Configure-Ereignis AWS OpsWorks installiert. Der AWS OpsWorks 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.
deploy
attributes bezieht sich auf den [:deploy]
Namespace, der bereitstellungsbezogene Attribute enthält, die über die Konsole oder API definiert oder vom Stacks-Dienst generiert werden. AWS OpsWorks 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 in Erstellen eines Stacks und Ausführen einer Anwendung erläuterten Beispiel wird das Dokumenten-Stammverzeichnis auf "ROOT"
festgelegt, sodass der Kontext "ROOT" ist und die Konfigurationsdatei ROOT.xml
benannt wird.
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
festgelegt und im Verzeichniscontext_name
.xml/etc/tomcat6/Catalina/localhost/
installiert.Der
['datasources']
-Knoten aus den Stack-Konfigurationsattributen enthält ein oder mehrere Attribute, die jeweils einen Kontextnamen der JDBC-Datenressource zuordnen, die die zugeordnete Anwendung für die Kommunikation mit der Datenbank verwendet. Der Knoten und sein Inhalt werden beim Erstellen des Stacks mit benutzerdefinierter JSON definiert, wie später in Erstellen eines Stacks und Ausführen einer Anwendung erläutert. Das Beispiel hat ein einzelnes Attribut, das den Kontextnamen "ROOT" einer JDBC-Ressource mit dem Namen "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) odertomcat6
(Ubuntu). -
Die
template
-Ressource erstellt die Konfigurationsdatei nur dann, wenn der['datasources']
-Knoten vorhanden ist und eincontext_name
-Attribut enthält. -
Die Ressource
template
definiert die beiden Variablenresource_name
undwebapp_name
.resource_name
wird auf den Ressourcennamen festgelegt, dercontext_name
zugeordnet ist, undwebapp_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 Name der JDBC-Ressource, der auf den in definierten
resource_name
Wert gesetzt ist.tomcat::context
Für das Beispiel wird der Ressourcenname auf "jdbc/mydb" festgelegt.
-
auth und type — Dies sind Standardeinstellungen für JDBC-Verbindungen.
DataSource
-
MaxActive, MaxIdle 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 Attributen abgerufen werden.
deploy
-
driverClassName— Der Klassenname des JDBC-Treibers, der auf den MySQL-Treiber gesetzt ist.
-
url — Die Verbindungs-URL.
Das Präfix hängt von der Datenbank ab. Es sollte folgendermaßen festgelegt werden:
jdbc:mysql
für MySQL,jdbc:postgresql
für Postgres undjdbc:sqlserver
für SQL Server. Im Beispiel wird die URL aufjdbc:mysql://
festgelegt, wobeihost_IP_Address
:3306:simplejspsimplejsp
der Kurzname der App ist. -
factory — Die
DataSource
Factory, die für MySQL-Datenbanken erforderlich ist.