Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

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.

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

    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.

  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 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 auf einen MySQL-Datenbankserver zuzugreifen, der auf einer separaten Instanz ausgeführt werden kann. 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 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.

deployattributes 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 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, 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) 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 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 und jdbc:sqlserver für SQL Server. Im Beispiel wird die URL auf jdbc:mysql://host_IP_Address:3306:simplejsp festgelegt, wobei simplejsp der Kurzname der App ist.

  • factory — Die DataSource Factory, die für MySQL-Datenbanken erforderlich ist.

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

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.