Einrichtungsrezepte - AWS OpsWorks
tomcat::setuptomcat::installtomcat::servicetomcat::container_configtomcat::apache_tomcat_bind

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.

Einrichtungsrezepte

Wichtig

Der AWS OpsWorks Stacks 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 das AWS Support Team auf AWS re:POST oder über den AWS Premium-Support.

Einrichtungsrezepte werden dem Setup-Lebenszyklusereignis des Layers zugeordnet und nach dem Start einer Instance ausgeführt. Sie führen Aufgaben wie das Installieren von Paketen, das Erstellen von Konfigurationsdateien und das Starten von Services durch. Nachdem die Ausführung der Setup-Rezepte abgeschlossen ist, führt AWS OpsWorks Stacks die Deploy-Rezepte aus, um alle Apps auf der neuen Instanz bereitzustellen.

tomcat::setup

Das tomcat::setup-Rezept ist dafür konzipiert, dem Setup-Lebenszyklusereignis eines Layer zugewiesen zu werden.


include_recipe 'tomcat::install'
include_recipe 'tomcat::service'

service 'tomcat' do
  action :enable
end

# for EBS-backed instances we rely on autofs
bash '(re-)start autofs earlier' do
  user 'root'
  code <<-EOC
    service autofs restart
  EOC
  notifies :restart, resources(:service => 'tomcat')
end

include_recipe 'tomcat::container_config'
include_recipe 'apache2'
include_recipe 'tomcat::apache_tomcat_bind'

Das tomcat::setup-Rezept ist weitestgehend ein Metarezept. Es enthält eine Reihe von abhängigen Rezepten, die die meisten Details der Installation und Konfiguration von Tomcat und zugehörigen Paketen verarbeiten. Der erste Teil von tomcat::setup führt die folgenden Rezepte aus, die zu einem späteren Zeitpunkt besprochen werden:

Der mittlere Teil von tomcat::setup ermöglicht und startet den Tomcat-Service:

  • Die service-Ressource von Chef aktiviert den Tomcat-Service beim Start.

  • Die Chef-Bash-Ressource führt ein Bash-Skript aus, um den autofs-Daemon zu starten, der für Amazon EBS-gestützte Instances erforderlich ist. Die Ressource weist dann die service-Ressource an, den Tomcat-Service neu zu starten.

    Weitere Informationen finden Sie unter: autofs (für Amazon Linux) oder Autofs (für Ubuntu).

Der letzte Teil von tomcat::setup erstellt Konfigurationsdateien und installiert und konfiguriert den Apache-Frontend-Server:

  • Das tomcat::container_config-Rezept erstellt Konfigurationsdateien.

  • Das apache2 Rezept (das eine Abkürzung fürapache2::default) ist ein in AWS OpsWorks Stacks integriertes Rezept, das einen Apache-Server installiert und konfiguriert.

  • Das tomcat::apache_tomcat_bind-Rezept konfiguriert den Apache-Server so, dass er als Frontend für den Tomcat-Server dient.

Anmerkung

Sie können oft Zeit und Mühen sparen, indem Sie integrierte Rezepte für die Durchführung einiger der erforderlichen Aufgaben nutzen. Dieses Rezept verwendet das integrierte apache2::default-Rezept zum Installieren von Apache anstelle einer Implementierung von Anfang an. Ein weiteres Beispiel für die Verwendung integrierter Rezepte finden Sie unter Bereitstellungsrezepte.

Die folgenden Abschnitte beschreiben die Einrichtungsrezepte des Tomcat-Rezeptbuch im Detail. Weitere Informationen zu den apache2-Rezepten finden Sie unter opsworks-cookbooks/apache2.

tomcat::install

Das tomcat::install -Rezept installiert den Tomcat-Server, OpenJDK und eine Java-Konnektorbibliothek, die die Verbindung zum MySQL-Server verarbeitet.


tomcat_pkgs = value_for_platform(
  ['debian', 'ubuntu'] => {
    'default' => ["tomcat#{node['tomcat']['base_version']}", 'libtcnative-1', 'libmysql-java']
  },
  ['centos', 'redhat', 'fedora', 'amazon'] => {
    'default' => ["tomcat#{node['tomcat']['base_version']}", 'tomcat-native', 'mysql-connector-java']
  },
  'default' => ["tomcat#{node['tomcat']['base_version']}"]
)

tomcat_pkgs.each do |pkg|
  package pkg do
    action :install
  end
end

link ::File.join(node['tomcat']['lib_dir'], node['tomcat']['mysql_connector_jar']) do
  to ::File.join(node['tomcat']['java_dir'], node['tomcat']['mysql_connector_jar'])
  action :create
end

# remove the ROOT webapp, if it got installed by default
include_recipe 'tomcat::remove_root_webapp'

Das Rezept führt die folgenden Aufgaben aus:

  1. Es erstellt eine Liste der Pakete, die installiert werden, abhängig vom Betriebssystem der Instance.

  2. Es installiert jedes Paket auf der Liste.

    Die Chef-Paketressource verwendet den entsprechenden Anbieter — yum für Amazon Linux und apt-get für Ubuntu —, um die Installation durchzuführen. Die Paketanbieter installieren OpenJDK als Tomcat-Abhängigkeit, die MySQL-Konnektorbibliothek muss jedoch explizit installiert werden.

  3. Es verwendet eine link-Ressource von Chef zum Erstellen eines symbolischen Links (symlink) im Verzeichnis "lib" des Tomcat-Servers zur MySQL-Konnektorbibliothek im JDK.

    Unter Verwendung der standardmäßigen Attributwerte lautet das Tomcat-lib-Verzeichnis /usr/share/tomcat6/lib und die MySQL-Konnektorbibliothek (mysql-connector-java.jar) befindet sich unter /usr/share/java/.

Das Rezept tomcat::remove_root_webapp entfernt die ROOT-Webanwendung (standardmäßig /var/lib/tomcat6/webapps/ROOT), um einige Sicherheitsprobleme zu vermeiden.

ruby_block 'remove the ROOT webapp' do
  block do
    ::FileUtils.rm_rf(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT'), :secure => true)
  end
  only_if { ::File.exists?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) && !::File.symlink?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) }
end

Die only_if-Anweisung stellt sicher, dass das Rezept die Datei nur dann entfernt, wenn sie vorhanden ist.

Anmerkung

Die Tomcat-Version wird von dem ['tomcat']['base_version']-Attribut spezifiziert, das in der Attributdatei auf 6 festgelegt ist. Zur Installation von Tomcat 7 können Sie benutzerdefinierte JSON-Attribute verwenden, um das Attribut zu überschreiben. Bearbeiten Sie Ihre Stack-Einstellungen und geben Sie im Feld Custom Chef JSON folgende JSON-Objekte ein oder fügen Sie ein bestehendes benutzerdefiniertes JSON-Objekt hinzu:


{
  'tomcat' : {
    'base_version' : 7
  }
}

Das benutzerdefinierte JSON-Attribut überschreibt das Standardattribut und legt die Tomcat-Version auf 7 fest. Weitere Informationen über das Überschreiben von Attributen finden Sie unter Überschreiben der Attribute.

tomcat::service

Das tomcat::service-Rezept erstellt die Tomcat-Servicedefinition.


service 'tomcat' do
  service_name "tomcat#{node['tomcat']['base_version']}"

  case node[:platform]
  when 'centos', 'redhat', 'fedora', 'amazon'
    supports :restart => true, :reload => true, :status => true
  when 'debian', 'ubuntu'
    supports :restart => true, :reload => false, :status => true
  end

  action :nothing
end

Das Rezept verwendet die service-Ressource von Chef, um den Tomcat-Servicenamen (standardmäßig "tomcat6") anzugeben, und das supports-Attribut, um zu definieren, wie Chef die Neustart-, Neulade- und Statusbefehle auf den verschiedenen Betriebssystemen verwaltet.

  • true gibt an, dass Chef das Init-Skript oder einen anderen Serviceanbieter zum Ausführen des Befehls verwenden kann.

  • false gibt an, dass Chef versuchen muss, den Befehl anderweitig auszuführen.

Beachten Sie, dass action auf :nothing festgelegt ist. Für jedes Lebenszyklusereignis initiiert AWS OpsWorks Stacks einen Chef-Lauf, um die entsprechenden Rezepte auszuführen. Das Tomcat-Rezeptbuch folgt einem allgemeinen Muster, das festlegt, dass ein Rezept die Servicedefinition erstellt, den aber Service nicht neu startet. Andere Rezepte in der Chef-Ausführung verarbeiten den Neustart, normalerweise mit einem notifies-Befehl in den template-Ressourcen, die zum Erstellen von Konfigurationsdateien verwendet werden. Benachrichtigungen sind eine komfortable Möglichkeit, einen Service neu zu starten, denn sie tun das nur, wenn die Konfiguration geändert wurde. Wenn eine Chef-Ausführung mehrere Neustartbenachrichtigungen für einen Service aufweist, startet Chef den Service zudem höchstens einmal neu. So werden Probleme vermieden, die auftreten können, wenn versucht wird, einen Service neu zu starten, der nicht voll betriebsbereit. Dies ist eine häufige Quelle von Fehlern bei Tomcat.

Der Tomcat-Service muss für jede Chef-Ausführung, die Neustartbenachrichtigungen verwendet, definiert werden. tomcat::service ist daher in mehreren Rezepten enthalten, um sicherzustellen, dass der Service für jede Chef-Ausführung definiert ist. Es entstehen keine Nachteile, wenn eine Chef-Ausführung mehrere Instances von tomcat::service umfasst, da Chef sicherstellt, dass ein Rezept nur einmal pro Ausführung ausgeführt wird, unabhängig davon, wie oft es enthalten ist.

tomcat::container_config

Das tomcat::container_config-Rezept erstellt Konfigurationsdateien von Rezeptbuch-Vorlagendateien.


include_recipe 'tomcat::service'

template 'tomcat environment configuration' do
  path ::File.join(node['tomcat']['system_env_dir'], "tomcat#{node['tomcat']['base_version']}")
  source 'tomcat_env_config.erb'
  owner 'root'
  group 'root'
  mode 0644
  backup false
  notifies :restart, resources(:service => 'tomcat')
end

template 'tomcat server configuration' do
  path ::File.join(node['tomcat']['catalina_base_dir'], 'server.xml')
  source 'server.xml.erb'
  owner 'root'
  group 'root'
  mode 0644
  backup false
  notifies :restart, resources(:service => 'tomcat')
end

Das Rezept ruft zuerst tomcat::service auf, das den Service bei Bedarf definiert. Der Großteil des Rezepts besteht aus zwei template-Ressourcen, von denen jede eine Konfigurationsdatei von einer der Vorlagendateien des Rezeptbuchs erstellt, die Dateieigenschaften festlegt und Chef anweist, den Service neu zu starten.

Tomcat-Umgebungskonfigurationsdatei

Die erste template-Ressource verwendet die Vorlagendatei tomcat_env_config.erb zum Erstellen einer Tomcat-Umgebungskonfigurationsdatei, die zum Festlegen von Umgebungsvariablen wie JAVA_HOME verwendet wird. Der Standardname ist das Argument der template-Ressource. tomcat::container_config verwendet ein path-Attribut, um den Standardwert zu überschreiben und der Konfigurationsdatei den Namen /etc/sysconfig/tomcat6 (Amazon Linux) oder /etc/default/tomcat6 (Ubuntu) zu geben. Die template-Ressource gibt zudem den Eigentümer, die Gruppe und die Moduseinstellungen der Datei an und weist Chef an, keine Sicherungsdateien zu erstellen.

Wenn Sie sich den Quellcode ansehen, gibt es tatsächlich drei Versionen von tomcat_env_config.erb, in jeweils unterschiedlichen Unterverzeichnissen des templates-Verzeichnisses. Die Verzeichnisse ubuntu und amazon enthalten die Vorlagen für die jeweiligen Betriebssysteme. Der Ordner default enthält eine Dummy-Vorlage mit einer einzigen Kommentarzeile, die nur verwendet wird, wenn Sie versuchen, dieses Rezept für eine Instance mit einem nicht unterstützten Betriebssystem auszuführen. Das Rezept tomcat::container_config muss nicht angeben, welche Datei tomcat_env_config.erb zu verwenden ist. Chef wählt automatisch das entsprechende Verzeichnis für das Betriebssystem der Instance aus, basierend auf den unter File Specificity beschriebenen Regeln.

Die tomcat_env_config.erb-Dateien für dieses Beispiel bestehen größtenteils aus Kommentaren. Um zusätzliche Umgebungsvariablen festzulegen, heben Sie die Auskommentierung der entsprechenden Zeilen auf und stellen Sie Ihre bevorzugten Werte bereit.

Anmerkung

Jede Konfigurationseinstellung, die sich ändern könnte, sollte als Attribut definiert und nicht in der Vorlage fest programmiert werden. Auf diese Weise müssen Sie nicht die Vorlage überschreiben, um eine Einstellung zu ändern. Sie können einfach das Attribut überschreiben.

Die Amazon Linux-Vorlage legt nur eine Umgebungsvariable fest, wie im folgenden Auszug gezeigt.


...
# Use JAVA_OPTS to set java.library.path for libtcnative.so
#JAVA_OPTS="-Djava.library.path=/usr/lib"

JAVA_OPTS="${JAVA_OPTS} <%= node['tomcat']['java_opts'] %>"

# What user should run tomcat
#TOMCAT_USER="tomcat"
...

JAVA_OPTS kann verwendet werden, um Java-Optionen anzugeben, wie z. B. den Bibliothekspfad. Mithilfe der standardmäßigen Attributwerte legt die Vorlage keine Java-Optionen für Amazon Linux fest. Sie können Ihre eigenen Java-Optionen festlegen, indem Sie z. B. das ['tomcat']['java_opts']-Attribut mithilfe benutzerdefinierter JSON-Attribute überschreiben. Ein Beispiel finden Sie unter Erstellen eines Stacks.

Die Ubuntu-Vorlage legt verschiedene Umgebungsvariablen fest, wie im folgenden Auszug aus der Vorlage gezeigt.


# Run Tomcat as this user ID. Not setting this or leaving it blank will use the
# default of tomcat<%= node['tomcat']['base_version'] %>.
TOMCAT<%= node['tomcat']['base_version'] %>_USER=tomcat<%= node['tomcat']['base_version'] %>
...
# Run Tomcat as this group ID. Not setting this or leaving it blank will use
# the default of tomcat<%= node['tomcat']['base_version'] %>.
TOMCAT<%= node['tomcat']['base_version'] %>_GROUP=tomcat<%= node['tomcat']['base_version'] %>
...
JAVA_OPTS="<%= node['tomcat']['java_opts'] %>"

<% if node['tomcat']['base_version'].to_i < 7 -%>
# Unset LC_ALL to prevent user environment executing the init script from
# influencing servlet behavior.  See Debian bug #645221
unset LC_ALL
<% end -%>

Mithilfe von standardmäßigen Attributwerten legt die Vorlage die Ubuntu-Umgebungsvariablen wie folgt fest:

  • TOMCAT6_USER und TOMCAT6_GROUP, die den Tomcat-Benutzer und die Tomcat-Gruppe darstellen, sind beide auf tomcat6 festgelegt.

    Wenn Sie ['tomcat']['base_version'] auf tomcat7 festlegen, werden die Variablennamen zu TOMCAT7_USER und TOMCAT7_GROUP aufgelöst und beide sind auf tomcat7 festgelegt.

  • JAVA_OPTS ist festgelegt auf -Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC.

    • Wenn Sie -Djava.awt.headless auf true festlegen, wird der Grafik-Engine mitgeteilt, dass die Instance keinen Monitor und keine Konsole hat, wodurch fehlerhaftes Verhalten bestimmter grafischer Anwendungen behoben wird.

    • -Xmx128m stellt sicher, dass die JVM über ausreichend Arbeitsspeicherressourcen verfügt, 128 MB für dieses Beispiel.

    • -XX:+UseConcMarkSweepGC legt eine gleichzeitige Mark-Sweep-Speicherbereinigung fest, was dazu beiträgt, durch Speicherbereinigung verursachte Pausen einzuschränken.

      Weitere Informationen finden Sie unter Concurrent Mark Sweep Collector Enhancements.

  • Wenn die Tomcat-Version niedriger ist als 7, löscht die Vorlage die Festlegung von LC_ALL, wodurch ein Ubuntu-Problem gelöst wird.

Anmerkung

Mit den Standardattributen werden einige dieser Umgebungsvariablen einfach auf ihre Standardwerte gesetzt. Das explizite Festlegen von Umgebungsvariablen auf Attribute bedeutet jedoch, dass Sie benutzerdefinierte JSON-Attribute definieren können, um die Standardattribute zu überschreiben und benutzerdefinierte Werte bereitzustellen. Weitere Informationen über das Überschreiben von Attributen finden Sie unter Überschreiben der Attribute.

Vollständige Vorlagendateien finden Sie im Quellcode.

Konfigurationsdatei "Server.xml"

Die zweite template-Ressource verwendet server.xml.erb zum Erstellen der system.xml Konfigurationsdatei, die den servlet/JSP-Container konfiguriert. server.xml.erb enthält keine betriebssystemspezifischen Einstellungen, weshalb sie sich im template-Verzeichnis, im default-Unterverzeichnis befindet.

Die Vorlage verwendet Standardeinstellungen, kann jedoch eine Datei system.xml für Tomcat 6 oder für Tomcat 7 erstellen. Der folgende Code aus dem Serverabschnitt der Vorlage konfiguriert beispielsweise die entsprechenden Listener für die angegebene Version.


<% if node['tomcat']['base_version'].to_i > 6 -%>
  <!-- Security listener. Documentation at /docs/config/listeners.html
  <Listener className="org.apache.catalina.security.SecurityListener" />
  -->
<% end -%>
  <!--APR library loader. Documentation at /docs/apr.html -->
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
  <Listener className="org.apache.catalina.core.JasperListener" />
  <!-- Prevent memory leaks due to use of particular java/javax APIs-->
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<% if node['tomcat']['base_version'].to_i < 7 -%>
  <!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html -->
  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
<% end -%>
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<% if node['tomcat']['base_version'].to_i > 6 -%>
  <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<% end -%>

Die Vorlage verwendet Attribute anstelle von fest programmierten Einstellungen, damit Sie die Einstellungen einfach ändern können, indem Sie benutzerdefinierte JSON-Attribute definieren. Beispielsweise:


<Connector port="<%= node['tomcat']['port'] %>" protocol="HTTP/1.1"
           connectionTimeout="20000"
           URIEncoding="<%= node['tomcat']['uri_encoding'] %>"
           redirectPort="<%= node['tomcat']['secure_port'] %>" />

Weitere Informationen finden Sie im Quellcode.

tomcat::apache_tomcat_bind

Das tomcat::apache_tomcat_bind-Rezept ermöglicht dem Apache-Server, als Tomcat-Frontend zu agieren, eingehende Anforderungen zu erhalten und sie an Tomcat weiterzuleiten sowie die Antworten an den Client zurückzugeben. Dieses Beispiel verwendet mod_proxy als Apache-Proxy/Gateway.


execute 'enable mod_proxy for apache-tomcat binding' do
  command '/usr/sbin/a2enmod proxy'
  not_if do
    ::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', 'proxy.load')) || node['tomcat']['apache_tomcat_bind_mod'] !~ /\Aproxy/
  end
end

execute 'enable module for apache-tomcat binding' do
  command "/usr/sbin/a2enmod #{node['tomcat']['apache_tomcat_bind_mod']}"
  not_if {::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', "#{node['tomcat']['apache_tomcat_bind_mod']}.load"))}
end

include_recipe 'apache2::service'

template 'tomcat thru apache binding' do
  path ::File.join(node['apache']['dir'], 'conf.d', node['tomcat']['apache_tomcat_bind_config'])
  source 'apache_tomcat_bind.conf.erb'
  owner 'root'
  group 'root'
  mode 0644
  backup false
  notifies :restart, resources(:service => 'apache2')
end

Um mod_proxy zu aktivieren, müssen Sie das proxy-Modul und ein protokollbasiertes Modul aktivieren. Es gibt zwei Möglichkeiten für das Protokollmodul:

Beide execute-Ressourcen des Rezepts führen den a2enmod-Befehl aus, der das angegebene Modul aktiviert, indem die erforderlichen symbolischen Links (symlinks) erstellt werden:

  • Die erste execute-Ressource aktiviert das proxy-Modul.

  • Die zweite execute-Ressource aktiviert das Protokollmodul, das standardmäßig auf proxy_http festgelegt ist.

    Wenn Sie lieber AJP verwenden, können Sie ein benutzerdefiniertes JSON-Objekt definieren, um das apache_tomcat_bind_mod-Attribut zu überschreiben und es auf proxy_ajp festzulegen.

Das apache2::service Rezept ist ein in AWS OpsWorks Stacks integriertes Rezept, das den Apache-Dienst definiert. Weitere Informationen finden Sie im Rezept im AWS OpsWorks Stacks-Repository GitHub .

Die template-Ressource verwendet apache_tomcat_bind.conf.erb zum Erstellen einer Konfigurationsdatei, die standardmäßig tomcat_bind.conf benannt wird. Die Datei wird im Verzeichnis ['apache']['dir']/.conf.d abgelegt. Das ['apache']['dir']-Attribut ist in der integrierten apache2-Attributdatei definiert und standardmäßig auf /etc/httpd (Amazon Linux) bzw. /etc/apache2 (Ubuntu) festgelegt. Wenn die template-Ressource die Konfigurationsdatei erstellt oder ändert, plant der notifies-Befehl einen Neustart des Apache-Services.


<% if node['tomcat']['apache_tomcat_bind_mod'] == 'proxy_ajp' -%>
ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/
ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/
<% else %>
ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/
ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/
<% end -%>

Die Vorlage verwendet die ProxyPassReverseDirektiven ProxyPassund, um den Port zu konfigurieren, der für die Weiterleitung des Datenverkehrs zwischen Apache und Tomcat verwendet wird. Da sich beide Server auf derselben Instance befinden, können sie eine "localhost"-URL verwenden und sind beide standardmäßig auf http://localhost:8080 festgelegt.