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 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](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support). Einrichtungsrezepte werden dem Setup-[Lebenszyklusereignis](workingcookbook-events.md) 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 OpsWorks Stacks die [Deploy-Rezepte](create-custom-deploy.md) aus, um alle Apps auf der neuen Instanz bereitzustellen. **Topics** + [tomcat::setup](#create-custom-setup-setup) + [tomcat::install](#create-custom-setup-install) + [tomcat::service](#create-custom-setup-service) + [tomcat::container\$1config](#create-custom-setup-config) + [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind) ## 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: + Das [tomcat::install](#create-custom-setup-install)-Rezept installiert das Tomcat-Serverpaket. + Das [tomcat::service](#create-custom-setup-service)-Rezept richtet den Tomcat-Service ein. Der mittlere Teil von `tomcat::setup` ermöglicht und startet den Tomcat-Service: + Die [service-Ressource](https://docs.chef.io/chef/resources.html#service) von Chef aktiviert den Tomcat-Service beim Start. + Die [Chef-Bash-Ressource](https://docs.chef.io/chef/resources.html#bash) 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](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html) (für Amazon Linux) oder [Autofs](https://help.ubuntu.com/community/Autofs) (für Ubuntu). Der letzte Teil von `tomcat::setup` erstellt Konfigurationsdateien und installiert und konfiguriert den Apache-Frontend-Server: + Das [tomcat::container\$1config](#create-custom-setup-config)-Rezept erstellt Konfigurationsdateien. + Das `apache2` Rezept (das eine Abkürzung für`apache2::default`) ist ein in OpsWorks Stacks integriertes Rezept, das einen Apache-Server installiert und konfiguriert. + Das [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-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](create-custom-deploy.md). Die folgenden Abschnitte beschreiben die Einrichtungsrezepte des Tomcat-Rezeptbuch im Detail. Weitere Informationen zu den `apache2`-Rezepten finden Sie unter [opsworks-cookbooks/apache2](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/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. 1. Es installiert jedes Paket auf der Liste. Die [Chef-Paketressource](https://docs.chef.io/chef/resources.html#id146) 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. 1. Es verwendet eine [link-Ressource](https://docs.chef.io/chef/resources.html#link) 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](workingstacks-edit.md) 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](workingcookbook-attributes.md). ## 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](https://docs.chef.io/chef/resources.html#service) 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 OpsWorks Stacks einen [Chef-Lauf](https://docs.chef.io/chef_client_overview.html#the-chef-client-run), 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\$1config 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](https://docs.chef.io/chef/resources.html#template), 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](http://docs.chef.io/templates.html#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\$1OPTS 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](create-custom-stack.md#create-custom-stack-stack). 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\$1version'] 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](http://docs.oracle.com/javase/6/docs/technotes/guides/vm/cms-6.html). + 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](workingcookbook-attributes.md). Vollständige Vorlagendateien finden Sie im [Quellcode](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat). ### Konfigurationsdatei "Server.xml" Die zweite `template` Ressource wird verwendet`server.xml.erb`, um die [`system.xml`Konfigurationsdatei zu erstellen, mit](http://tomcat.apache.org/tomcat-7.0-doc/config/) der der Container konfiguriert wird. servlet/JSP `server.xml.erb`enthält keine betriebssystemspezifischen Einstellungen und befindet sich daher im `template` Unterverzeichnis des Verzeichnisses. `default` 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 -%> <% end -%> <% if node['tomcat']['base_version'].to_i < 7 -%> <% end -%> <% if node['tomcat']['base_version'].to_i > 6 -%> <% end -%> ``` Die Vorlage verwendet Attribute anstelle von fest programmierten Einstellungen, damit Sie die Einstellungen einfach ändern können, indem Sie benutzerdefinierte JSON-Attribute definieren. Beispiel: ``` ``` Weitere Informationen finden Sie im [Quellcode](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat). ## tomcat::apache\$1tomcat\$1bind 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\$1proxy](https://httpd.apache.org/docs/2.2/mod/mod_proxy.html) 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: + HTTP: `proxy_http` + [ JServ Apache-Protokoll (AJP](http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html)): `proxy_ajp` AJP ist ein internes Tomcat-Protokoll. Beide [execute-Ressourcen](https://docs.chef.io/chef/resources.html#execute) 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 OpsWorks Stacks integriertes Rezept, das den Apache-Dienst definiert. Weitere Informationen finden Sie im [Rezept](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/apache2/recipes/service.rb) im 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 [ProxyPassReverse](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse)Direktiven [ProxyPass](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypass)und, 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.