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.

# Erstellen eines benutzerdefinierten Tomcat-Server-Layers
<a name="create-custom"></a>

**Wichtig**  
Der AWS OpsWorks Stacks Service 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).

**Anmerkung**  
In diesem Thema wird beschrieben, wie ein benutzerdefinierter Layer für einen Linux-Stack implementiert wird. Die grundlegenden Prinzipien und ein Teil des Codes kann jedoch auch zur Implementierung benutzerdefinierter Layer für Windows-Stacks angepasst werden, vor allem diejenigen im Abschnitt über Anwendungsbereitstellung.

Die einfachste Möglichkeit, nicht standardmäßige Pakete auf OpsWorks Stacks-Instanzen zu verwenden, besteht darin, eine bestehende Ebene zu [erweitern](workingcookbook-extend-package.md). Bei diesem Ansatz werden jedoch sowohl standardmäßige als auch nicht standardmäßige Pakete auf Instances des Layers installiert und ausgeführt, was nicht immer wünschenswert ist. Ein etwas komplexerer, aber leistungsstärkerer Ansatz besteht darin, einen benutzerdefinierten Layer zu implementieren. Dies gibt Ihnen die nahezu vollständige Kontrolle über die Instances des Layers, einschließlich der folgenden Aspekte: 
+ Welche Pakete installiert werden
+ Wie jedes Paket konfiguriert ist
+ Wie Anwendungen von einem Repository der Instance bereitgestellt werden

Unabhängig davon, ob Sie die Konsole oder die API verwenden, erstellen und verwalten Sie einen benutzerdefinierten Layer ähnlich wie jeden anderen Layer, wie unter [Benutzerspezifische Layers](workinglayers-custom.md) beschrieben. Die integrierten Rezepte eines benutzerdefinierten Layers führen jedoch nur einige sehr grundlegende Aufgaben aus, wie z. B. das Installieren eines Ganglia-Clients zum Melden von Metriken an einen Ganglia-Master. Um die Instances eines benutzerdefinierten Layers mehr als minimal funktionsfähig zu machen, müssen Sie mindestens ein benutzerdefiniertes Rezeptbuch mit Chef-Rezepten und zugehörige Dateien implementieren, um die Aufgaben der Installation und Konfiguration von Paketen, der Bereitstellung von Anwendungen usw. auszuführen. Aber Sie müssen nicht notwendigerweise alles von Grund auf implementieren. Wenn Sie beispielsweise Anwendungen in einem der Standard-Repositorys speichern, können Sie die integrierten Bereitstellungsrezepte verwenden, um einen Großteil der Arbeit der Installation der Anwendungen auf den Instances des Layers zu verarbeiten.

**Anmerkung**  
Wenn Sie noch nie mit Chef gearbeitet haben, lesen Sie zuerst das Tutorial [Rezeptbücher 101](cookbooks-101.md). Es enthält eine Einführung in die Grundlagen der Implementierung von Rezeptbüchern, mit denen Sie die unterschiedlichsten Aufgaben ausführen können. 

In der folgenden schrittweisen Anleitung wird beschrieben, wie Sie einen benutzerdefinierten Layer implementieren, der einen Tomcat-Anwendungsserver unterstützt. Der Layer basiert auf einem benutzerdefinierten Rezeptbuch mit dem Namen Tomcat. Es enthält Rezepte zum Verarbeiten von Paketinstallation, Bereitstellung usw. Die schrittweise Anleitung umfasst Auszüge aus dem Tomcat-Rezeptbuch. [Sie können das komplette Kochbuch aus dem Repository herunterladen. GitHub ](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat) Wenn Sie mit [Opscode Chef](http://www.opscode.com/chef/) nicht vertraut sind, sollten Sie zunächst [Cookbooks und Rezepte](workingcookbook.md) lesen.

**Anmerkung**  
OpsWorks Stacks enthält eine [Java App Server-Schicht](layers-java.md) mit vollem Funktionsumfang für den Produktionseinsatz. Der Zweck des Tomcat-Rezeptbuchs besteht darin zu zeigen, wie benutzerdefinierte Layer implementiert werden. Es unterstützt daher nur eine eingeschränkte Version von Tomcat, die keine Funktionen wie SSL umfasst. Ein Beispiel für eine Implementierung mit vollem Funktionsumfang finden Sie in dem integrierten Rezeptbuch [opsworks\$1java](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/opsworks_java).

Das Tomcat-Rezeptbuch unterstützt einen benutzerspezifischen Layer, dessen Instances die folgenden Eigenschaften aufweisen:
+ Sie unterstützen einen Tomcat-Anwendungsserver mit einem Apache-Frontend.
+ Tomcat ist so konfiguriert, dass Anwendungen ein `DataSource` JDBC-Objekt verwenden können, um eine Verbindung zu einer separaten MySQL-Instanz herzustellen, die als Backend-Datenspeicher dient.

Das Rezeptbuch für dieses Projekt umfasst mehrere wichtige Komponenten:
+ [Die Attributdatei](create-custom-attributes.md) enthält Konfigurationseinstellungen, die von den verschiedenen Rezepten verwendet werden.
+ [Einrichtungsrezepte](create-custom-setup.md) werden dem Setup-[Lebenszyklusereignis](workingcookbook-events.md) des Layers zugewiesen. Sie werden ausgeführt, nachdem eine Instanz gestartet wurde, und führen Aufgaben wie das Installieren von Paketen und das Erstellen von Konfigurationsdateien aus.
+ [Konfigurationsrezepte](create-custom-configure.md) werden dem Configure-Lebenszyklusereignis des Layers zugewiesen. Sie werden ausgeführt, nachdem sich die Konfiguration des Stacks geändert hat — in erster Linie, wenn Instances online gehen oder offline gehen — und übernehmen alle erforderlichen Konfigurationsänderungen.
+ [Bereitstellungsrezepte](create-custom-deploy.md) werden dem Deploy-Lebenszyklusereignis des Layers zugewiesen. Sie werden nach den Einrichtungsrezepten ausgeführt und wenn Sie eine Anwendung manuell bereitstellen, um den Code zu installieren und zugehörige Dateien auf den Instances eines Layers zu installieren, und verarbeiten die dazugehörigen Aufgaben, wie z. B. das Neustarten von Services.

Im letzten Abschnitt wird beschrieben[Erstellen eines Stacks und Ausführen einer Anwendung](create-custom-stack.md), wie Sie einen Stack erstellen, der eine benutzerdefinierte Ebene enthält, die auf dem Tomcat-Kochbuch basiert, und wie Sie eine einfache JSP-Anwendung bereitstellen und ausführen, die Daten aus einer MySQL-Datenbank anzeigt, die auf einer Instanz läuft, die zu einer separaten MySQL-Schicht gehört.

**Anmerkung**  
Die Rezepte für das Tomcat-Kochbuch hängen von einigen in Stacks integrierten Rezepten ab. OpsWorks Um den Ursprung der einzelnen Rezepte deutlich zu machen, werden in diesem Thema Rezepte mithilfe der Chef-Konvention *Rezeptbuchname*::*Rezeptname* bezeichnet.

**Topics**
+ [Attributdatei](create-custom-attributes.md)
+ [Einrichtungsrezepte](create-custom-setup.md)
+ [Konfigurationsrezepte](create-custom-configure.md)
+ [Bereitstellungsrezepte](create-custom-deploy.md)
+ [Erstellen eines Stacks und Ausführen einer Anwendung](create-custom-stack.md)

# Attributdatei
<a name="create-custom-attributes"></a>

**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).

Bevor wir Rezepte betrachten, ist es sinnvoll, zuerst die Attributdatei des Tomcat-Rezeptbuchs anzusehen, die verschiedene Konfigurationseinstellungen enthält, die die Rezepte verwenden. Attribute sind nicht erforderlich. Sie können diese Werte einfach in Ihren Rezepten oder Vorlagen fest programmieren. Wenn Sie jedoch Konfigurationseinstellungen mithilfe von Attributen definieren, können Sie die OpsWorks Stacks-Konsole oder die API verwenden, um die Werte zu ändern, indem Sie benutzerdefinierte JSON-Attribute definieren. Dies ist einfacher und flexibler, als den Rezept- oder Vorlagencode jedes Mal neu zu schreiben, wenn Sie eine Einstellung ändern möchten. Dieser Ansatz ermöglicht es Ihnen beispielsweise, dasselbe Rezeptbuch für mehrere Stacks zu verwenden, aber den Tomcat-Server für jeden Stack unterschiedlich zu konfigurieren. Weitere Informationen zu Attributen und wie diese überschrieben werden können, finden Sie unter [Überschreiben der Attribute](workingcookbook-attributes.md).

Das folgende Beispiel zeigt die komplette Attributdatei, `default.rb`, die sich im Verzeichnis `attributes` des Tomcat-Rezeptbuchs befindet.

```
default['tomcat']['base_version'] = 6
default['tomcat']['port'] = 8080
default['tomcat']['secure_port'] = 8443
default['tomcat']['ajp_port'] = 8009
default['tomcat']['shutdown_port'] = 8005
default['tomcat']['uri_encoding'] = 'UTF-8'
default['tomcat']['unpack_wars'] = true
default['tomcat']['auto_deploy'] = true
case node[:platform]
when 'centos', 'redhat', 'fedora', 'amazon'
  default['tomcat']['java_opts'] = ''
when 'debian', 'ubuntu'
  default['tomcat']['java_opts'] = '-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC'
end
default['tomcat']['catalina_base_dir'] = "/etc/tomcat#{node['tomcat']['base_version']}"
default['tomcat']['webapps_base_dir'] = "/var/lib/tomcat#{node['tomcat']['base_version']}/webapps"
default['tomcat']['lib_dir'] = "/usr/share/tomcat#{node['tomcat']['base_version']}/lib"
default['tomcat']['java_dir'] = '/usr/share/java'
default['tomcat']['mysql_connector_jar'] = 'mysql-connector-java.jar'
default['tomcat']['apache_tomcat_bind_mod'] = 'proxy_http' # or: 'proxy_ajp'
default['tomcat']['apache_tomcat_bind_config'] = 'tomcat_bind.conf'
default['tomcat']['apache_tomcat_bind_path'] = '/tc/'
default['tomcat']['webapps_dir_entries_to_delete'] = %w(config log public tmp)
case node[:platform]
when 'centos', 'redhat', 'fedora', 'amazon'
  default['tomcat']['user'] = 'tomcat'
  default['tomcat']['group'] = 'tomcat'
  default['tomcat']['system_env_dir'] = '/etc/sysconfig'
when 'debian', 'ubuntu'
  default['tomcat']['user'] = "tomcat#{node['tomcat']['base_version']}"
  default['tomcat']['group'] = "tomcat#{node['tomcat']['base_version']}"
  default['tomcat']['system_env_dir'] = '/etc/default'
end
```

Die Einstellungen selbst werden später im entsprechenden Abschnitt besprochen. Die folgenden Hinweise gelten allgemein:
+ Alle Knotendefinitionen weisen den `default`-Typ auf. Sie können also mit [benutzerdefinierten JSON-Attributen](workingcookbook-json-override.md) überschrieben werden.
+ Die Datei verwendet eine `case`-Anweisung, um einige Attributwerte basierend auf dem Betriebssystem der Instance bedingt festzulegen.

  Der `platform`-Knoten wird vom Ohai Tool von Chef generiert und stellt das Betriebssystem der Instance dar. 

# Einrichtungsrezepte
<a name="create-custom-setup"></a>

**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
<a name="create-custom-setup-setup"></a>

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
<a name="create-custom-setup-install"></a>

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
<a name="create-custom-setup-service"></a>

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
<a name="create-custom-setup-config"></a>

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
<a name="create-custom-setup-config-env"></a>

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"
<a name="create-custom-setup-config-server"></a>

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 -%>
  <!-- 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. Beispiel:

```
<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](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat).

## tomcat::apache\$1tomcat\$1bind
<a name="create-custom-setup-bind"></a>

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.

# Konfigurationsrezepte
<a name="create-custom-configure"></a>

**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).

Konfigurationsrezepte werden dem Configure-[Lebenszyklusereignis](workingcookbook-events.md) 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
<a name="create-custom-configure-configure"></a>

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.

1. 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\$1config](create-custom-setup.md#create-custom-setup-config) beschrieben, und startet den Tomcat-Service neu.

## tomcat::context
<a name="create-custom-configure-context"></a>

Das Tomcat-Kochbuch ermöglicht es Anwendungen, mithilfe eines [ DataSourceJ2EE-Objekts](http://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html) 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](http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).

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](workingcookbook-json.md) mit dem Configure-Ereignis OpsWorks installiert. Der 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](workingcookbook-json.md). 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](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search).

`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. 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](create-custom-setup.md#create-custom-setup-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](create-custom-stack.md) 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](create-custom-stack.md) 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.](http://wiki.apache.org/tomcat/UsingDataSources)

# Bereitstellungsrezepte
<a name="create-custom-deploy"></a>

**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).

Bereitstellungsrezepte werden dem Deploy-[Lebenszyklusereignis](workingcookbook-events.md) des Layers zugewiesen. Es tritt normalerweise auf allen Instanzen des Stacks auf, wann immer Sie eine App bereitstellen. Sie können das Ereignis jedoch optional auf nur bestimmte Instanzen beschränken. OpsWorks Stacks führt die Deploy-Rezepte auch auf neuen Instanzen aus, nachdem die Setup-Rezepte abgeschlossen sind. Der Hauptzweck von Bereitstellungsrezepten besteht in der Bereitstellung von Code und zugehörigen Dateien aus einem Repository in den Instances des Anwendungsserver-Layers. Bereitstellungsrezepte werden jedoch auch oft auf anderen Layern ausgeführt. Auf diese Weise können Instances dieser Layer z. B. ihre Konfiguration aktualisieren, um die neu bereitgestellte Anwendung einzubinden. Wenn Sie ein Bereitstellungsrezept implementieren, beachten Sie, dass ein Deploy-Ereignis nicht notwendigerweise bedeutet, dass der Instance Anwendungen bereitgestellt werden. Es könnte auch einfach nur eine Benachrichtigung sein, dass Anwendungen in anderen Instances im Stack bereitgestellt werden, um zu ermöglichen, dass die Instance notwendige Updates durchführt. Das Rezept muss entsprechend reagieren können, was auch bedeuten kann, dass nichts durchgeführt wird.

OpsWorks Stacks stellt Apps der Standard-App-Typen automatisch auf den entsprechenden integrierten Anwendungsserverschichten bereit. Zur Bereitstellung von Anwendungen in einem benutzerdefinierten Layer müssen Sie benutzerdefinierte Bereitstellungsrezepte implementieren, die die Dateien der Anwendung von einem Repository in den entsprechenden Speicherort in der Instance herunterladen. Sie können jedoch häufig die Menge des Codes begrenzen, den Sie schreiben müssen, indem Sie das integrierte [Bereitstellungsrezeptbuch](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/deploy) verwenden, um verschiedene Aspekte der Bereitstellung zu verarbeiten. Wenn Sie beispielsweise Ihre Dateien in einem der unterstützten Repositorys speichern, kann das integrierte Rezeptbuch die Details des Herunterladens von Dateien aus dem Repository in die Instances des Layers verarbeiten. 

Das `tomcat::deploy`-Rezept ist dafür konzipiert, dem Deploy-Lebenszyklusereignis zugewiesen zu werden.

```
include_recipe 'deploy'

node[:deploy].each do |application, deploy|
  opsworks_deploy_dir do
    user deploy[:user]
    group deploy[:group]
    path deploy[:deploy_to]
  end

  opsworks_deploy do
    deploy_data deploy
    app application
  end
...
```

Das `tomcat::deploy`-Rezept verwendet das integrierte Bereitstellungsrezeptbuch für Aspekte der Bereitstellung, die nicht anwendungsspezifisch sind. Das `deploy`-Rezept (die Kurzbezeichnung für das integrierte `deploy::default`-Rezept) ist ein integriertes Rezept, das die Details der Einrichtung der Benutzer, Gruppen usw. verarbeitet, basierend auf Daten aus den `deploy`-Attributen.

Das Rezept verwendet zwei integrierte Chef-Definitionen, `opsworks_deploy_dir` und `opworks_deploy`, zum Installieren der Anwendung. 

Die `opsworks_deploy_dir`-Definition richtet die Verzeichnisstruktur basierend auf Daten der JSON-Bereitstellung der Anwendung ein. Definitionen sind grundsätzlich eine bequeme Möglichkeit, Ressourcendefinitionen zu verpacken, und befinden sich im Verzeichnis `definitions` eines Rezeptbuchs. Rezepte können Definitionen ähnlich wie Ressourcen verwenden, aber der Definition selbst ist kein Anbieter zugeordnet, sondern nur die Ressourcen, die in der Definition enthalten sind. Sie können Variablen im Rezept definieren, die an die zugrunde liegenden Ressourcendefinitionen weitergegeben werden. Das `tomcat::deploy`-Rezept legt die Variablen `user`, `group` und `path` basierend auf Daten aus der JSON-Bereitstellung fest. Sie werden an die [directory-Ressource](https://docs.chef.io/chef/resources.html#directory) der Definition weitergegeben, die die Verzeichnisse verwaltet. 

**Anmerkung**  
Die Benutzer und die Gruppe Ihrer bereitgestellten Anwendung werden von den Attributen`[:opsworks][:deploy_user][:user]` und `[:opsworks][:deploy_user][:group]` bestimmt, die in der Attributdatei des [integrierten Bereitstellungsrezeptbuchs `deploy.rb` definiert werden](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/deploy/attributes/deploy.rb). Der Standardwert von `[:opsworks][:deploy_user][:user]` ist `deploy`. Der Standardwert von `[:opsworks][:deploy_user][:group]` hängt vom Betriebssystem der Instance ab:  
Für Ubuntu-Instances ist die Standardgruppe `www-data`.
Für Amazon Linux-Instances, die Mitglieder einer Rails-App Server-Ebene sind, die Nginx und Unicorn verwendet, ist die Standardgruppe. `nginx`
Für alle anderen Amazon Linux-Instances ist die Standardgruppe `apache`.
Sie können diese Einstellungen ändern, indem Sie mithilfe einer benutzerdefinierten JSON-Datei oder einer benutzerdefinierten Attributdatei das entsprechende Attribut überschreiben. Weitere Informationen finden Sie unter [Überschreiben der Attribute](workingcookbook-attributes.md).

Die andere Definition, `opsworks_deploy`, verarbeitet die Details der Überprüfung des Codes der App und der zugehörigen Dateien aus dem Repository und der Bereitstellung in der Instance, basierend auf Daten aus den `deploy`-Attributen. Sie können diese Definition für jeden Anwendungstyp verwenden. Bereitstellungsdetails wie die Verzeichnisnamen werden in der Konsole oder über die API festgelegt und in den `deploy`-Attributen gespeichert. Allerdings funktioniert`opsworks_deploy` nur für die vier [unterstützten Repository-Typen](workingcookbook-installingcustom-repo.md): Git, Subversion, S3 und HTTP. Sie müssen diesen Code selbst implementieren, wenn Sie einen anderen Repository-Typ verwenden möchten.

Sie installieren die Dateien einer App im Tomcat-Verzeichnis `webapps`. Eine typische Methode ist es, Dateien direkt nach `webapps` zu kopieren. Die OpsWorks Stacks-Bereitstellung ist jedoch so konzipiert, dass bis zu fünf Versionen einer App auf einer Instance beibehalten werden, sodass Sie bei Bedarf zu einer früheren Version zurückkehren können. OpsWorks Stacks macht daher Folgendes:

1. Es stellt Apps in einem getrennten Verzeichnis bereit, dessen Name einen Zeitstempel enthält, wie z. B. `/srv/www/my_1st_jsp/releases/20130731141527`.

1. Es erstellt einen symlink mit dem Namen `current`, wie etwa `/srv/www/my_1st_jsp/current`, zu diesem eindeutigen Verzeichnis.

1. Wenn nicht bereits vorhanden, erstellt es einen symlink von dem Verzeichnis `webapps` zum in Schritt 2 erstellten symlink `current`.

Wenn Sie eine frühere Version wiederherstellen müssen, modifizieren Sie den symlink `current` so, dass er auf ein bestimmtes Verzeichnis mit dem entsprechenden Zeitstempel zeigt, etwa indem Sie das Linkziel `/srv/www/my_1st_jsp/current` abändern.

Im mittleren Bereich von `tomcat::deploy` wird der symlink eingerichtet. 

```
  ...
  current_dir = ::File.join(deploy[:deploy_to], 'current')
  webapp_dir = ::File.join(node['tomcat']['webapps_base_dir'], deploy[:document_root].blank? ? application : deploy[:document_root])

  # opsworks_deploy creates some stub dirs, which are not needed for typical webapps
  ruby_block "remove unnecessary directory entries in #{current_dir}" do
    block do
      node['tomcat']['webapps_dir_entries_to_delete'].each do |dir_entry|
        ::FileUtils.rm_rf(::File.join(current_dir, dir_entry), :secure => true)
      end
    end
  end

  link webapp_dir do
    to current_dir
    action :create
  end
  ...
```

Das Rezept erstellt zunächst zwei Variablen, `current_dir` und `webapp_dir`, um jeweils die Verzeichnisse `current` und `webapp` darzustellen. Dann wird eine `link`-Ressource verwendet, um `webapp_dir` mit `current_dir` zu verknüpfen. Das OpsWorks `deploy::default` Stacks-Rezept erstellt einige Stub-Verzeichnisse, die für dieses Beispiel nicht erforderlich sind, sodass sie im mittleren Teil des Auszugs entfernt werden.

Der letzte Teil von `tomcat::deploy` startet den Tomcat-Service bei Bedarf neu.

```
  ...
  include_recipe 'tomcat::service'

  execute 'trigger tomcat service restart' do
    command '/bin/true'
    not_if { node['tomcat']['auto_deploy'].to_s == 'true' }
    notifies :restart, resources(:service => 'tomcat')
  end
end

include_recipe 'tomcat::context'
```

Das erste Rezept führt zuerst `tomcat::service` aus, um sicherzustellen, dass der Service für diese Chef-Ausführung definiert ist. Dann wird eine [execute-Ressource](https://docs.chef.io/chef/resources.html#execute) verwendet, um den Service anzuweisen, neu zu starten, aber nur, wenn `['tomcat']['auto_deploy']` festgelegt ist auf `'true'`. Andernfalls überwacht Tomcat Änderungen in seinem Verzeichnis `webapps`, was einen expliziten Neustart des Tomcat-Services überflüssig macht. 

**Anmerkung**  
Die `execute`-Ressource führt nichts wirklich Substantielles aus. `/bin/true` ist ein Dummy-Shell-Skript, das einfach einen Erfolgscode zurückgibt. Es wird hier als eine bequeme Möglichkeit verwendet, eine Neustartbenachrichtigung zu generieren. Wie bereits erwähnt wird durch die Verwendung von Benachrichtigungen sichergestellt, dass Services nicht zu häufig neu gestartet werden.

Schließlich wird `tomcat::deploy` von `tomcat::context` ausgeführt, wodurch die Webanwendungs-Kontextkonfigurationsdatei aktualisiert wird, wenn Sie die Backend-Datenbank geändert haben. 

# Erstellen eines Stacks und Ausführen einer Anwendung
<a name="create-custom-stack"></a>

**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).

In diesem Abschnitt wird erläutert, wie Sie das Tomcat-Rezeptbuch zum Implementieren einer grundlegenden Stack-Einrichtung verwenden, die eine einfache JSP-Anwendung (Java Server Pages-Anwendung) mit dem Namen "SimpleJSP" ausführt. Der Stack besteht aus einer Tomcat-basierten benutzerdefinierten Ebene mit dem Namen TomCustom und einer MySQL-Schicht. SimpleJSP wird in der MySQL-Datenbank bereitgestellt TomCustom und zeigt einige Informationen aus der MySQL-Datenbank an. Wenn Sie noch nicht mit den Grundlagen der Verwendung von OpsWorks Stacks vertraut sind, sollten Sie zuerst lesen. [Erste Schritte mit Chef 11 Linux-Stacks](gettingstarted.md)

## Die Anwendung SimpleJSP
<a name="create-custom-stack-jsp"></a>

Die SimpleJSP-Anwendung zeigt die Grundlagen der Einrichtung einer Datenbankverbindung und des Abrufens von Daten aus der MySQL-Datenbank des Stacks.

```
<html>
  <head>
    <title>DB Access</title>
  </head>
  <body>
    <%@ page language="java" import="java.sql.*,javax.naming.*,javax.sql.*" %>
    <%
      StringBuffer output = new StringBuffer();
      DataSource ds = null;
      Connection con = null;
      Statement stmt = null;
      ResultSet rs = null;
      try {
        Context initCtx = new InitialContext();
        ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/mydb");
        con = ds.getConnection();
        output.append("Databases found:<br>");
        stmt = con.createStatement();
        rs = stmt.executeQuery("show databases");
        while (rs.next()) {
          output.append(rs.getString(1));
          output.append("<br>");
        }
      }
      catch (Exception e) {
        output.append("Exception: ");
        output.append(e.getMessage());
        output.append("<br>");
      }
      finally {
        try {
          if (rs != null) {
            rs.close();
          }
          if (stmt != null) {
            stmt.close();
          }
          if (con != null) {
            con.close();
          }
        }
        catch (Exception e) {
          output.append("Exception (during close of connection): ");
          output.append(e.getMessage());
          output.append("<br>");
        }
      }
    %>
    <%= output.toString() %>
  </body>
</html>
```

SimpleJSP verwendet ein `DataSource`-Objekt für die Kommunikation mit der MySQL-Datenbank. Tomcat verwendet die Daten in der [Webanwendungs-Kontextkonfigurationsdatei](create-custom-configure.md#create-custom-configure-context), um ein `DataSource`-Objekt zu erstellen und zu initialisieren und mit einem logischen Namen zu verknüpfen. Es registriert dann den logischen Namen mit einer Java Naming and Directory Interface (JNDI). Um eine Instance des entsprechenden `DataSource`-Objekts zu erhalten, erstellen Sie ein `InitialContext`-Objekt und geben Sie den logischen Namen der Ressource an die `lookup`-Methode des Objekts weiter, die das entsprechende Objekt abruft. Der logische Namen des SimpleJSP-Beispiels, `java:comp/env/jdbc/mydb`, weist folgende Bestandteile auf:
+ Den Stamm-Namespace, `java`, der vom restlichen Namen durch einen Doppelpunkt (:) getrennt ist 
+ Alle zusätzlichen Namespaces, getrennt durch Schrägstriche (/)

  Tomcat fügt dem `comp/env`-Namespace automatisch Ressourcen hinzu.
+ Den Ressourcennamen, der in der Webanwendungs-Kontextkonfigurationsdatei definiert ist und mit einem Schrägstrich (/) vom Namespace getrennt ist

  Der Ressourcenname für dieses Beispiel lautet `jdbc/mydb`. 

Zum Herstellen einer Verbindung mit der Datenbank führt SimpleJSP Folgendes aus:

1. Ruft die `DataSource`-Methode des `getConnection`-Objekts auf, die ein `Connection`-Objekt zurückgibt.

1. Ruft die `Connection`-Methode des `createStatement`-Objekts auf, um ein `Statement`-Objekt zu erstellen, das Sie zur Kommunikation mit der Datenbank verwenden.

1. Kommuniziert mit der Datenbank, indem die entsprechende `Statement`-Methode aufgerufen wird.

   SimpleJSP ruft `executeQuery` auf, um eine SHOW DATABASES-Abfrage auszuführen, die die Datenbanken des Servers auflistet.

Die `executeQuery`-Methode gibt ein `ResultSet`-Objekt zurück, das die Abfrageergebnisse enthält. SimpleJSP ruft den Datenbanknamen aus dem zurückgegebenen `ResultSet`-Objekts ab und verkettet sie, um eine Ausgabezeichenfolge zu erstellen. Zuletzt schließt das Beispiel die Objekte `ResultSet`, `Statement` und `Connection`. Weitere Informationen zu JSP und JDBC finden Sie unter [JavaServer Pages Technology](http://docs.oracle.com/javaee/5/tutorial/doc/bnagx.html) bzw. [JDBC](http://docs.oracle.com/javase/tutorial/jdbc/basics/) Basics.

Um SimpleJSP mit einem Stack zu verwenden, müssen Sie es in einem Repository ablegen. Sie können jedes der unterstützten Repositorys verwenden, aber um SimpleJSP mit dem Beispiel-Stack zu verwenden, der im folgenden Abschnitt besprochen wird, müssen Sie SimpleJSP in einem öffentlichen S3-Archiv speichern. Weitere Informationen zur Verwendung der anderen Standard-Repositorys finden Sie unter [Rezeptbuch-Repositorys](workingcookbook-installingcustom-repo.md).

**Speichern von SimpleJSP in einem S3-Archiv-Repository**

1. Kopieren Sie den Beispielcode in eine Datei mit dem Namen `simplejsp.jsp` und speichern Sie die Datei in einem Verzeichnis mit dem Namen `simplejsp`.

1. Erstellen Sie ein `.zip`-Archiv des Verzeichnisses `simplejsp`.

1. Erstellen Sie einen öffentlichen Amazon S3 S3-Bucket, laden `simplejsp.zip` Sie ihn in den Bucket hoch und machen Sie die Datei öffentlich.

   Eine Beschreibung der Durchführung dieser Aufgabe finden Sie unter [Erste Schritte mit Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html).

## Erstellen eines Stacks
<a name="create-custom-stack-stack"></a>

Zum Ausführen von SimpleJSP benötigen Sie einen Stack mit den folgenden Layern.
+ Einen MySQL-Layer, der den Backend-MySQL-Server unterstützt
+ Einen benutzerdefinierten Layer, der das Tomcat-Rezeptbuch verwendet, um Tomcat-Server-Instances zu unterstützen

**So erstellen Sie den Stack**

1. Klicken Sie im OpsWorks Stacks-Dashboard auf **Stack hinzufügen, um einen neuen Stack** zu erstellen, und klicken Sie auf **Erweitert >>**, um alle Optionen anzuzeigen. Konfigurieren Sie den Stack wie folgt.
   + **Name** — Ein benutzerdefinierter Stackname; in diesem Beispiel wird. TomStack
   + **Benutzerdefinierte Chef-Kochbücher verwenden** — Stellen Sie den Schalter auf **Ja**, wodurch einige zusätzliche Optionen angezeigt werden.
   + **Repository-Typ** —Git.
   + **Repository-URL** —`git://github.com/amazonwebservices/opsworks-example-cookbooks.git`.
   + **Custom Chef JSON** — Fügen Sie den folgenden JSON hinzu:

     ```
     {
       "tomcat": {
         "base_version": 7,
         "java_opts": "-Djava.awt.headless=true -Xmx256m"
       },
       "datasources": {
         "ROOT": "jdbc/mydb"
       }
     }
     ```

   Für die restlichen Optionen können Sie die Standardwerte übernehmen.

   Das benutzerdefinierte JSON-Objekt führt Folgendes durch:
   + Überschreibt das `['base_version']`-Attribut des Tomcat-Rezeptbuchs, um die Tomcat-Version auf 7 festzulegen. Der Standardwert ist 6.
   + Überschreibt das `['java_opts']`-Attribut des Tomcat-Rezeptbuchs, um festzulegen, dass die Instance keinen Monitor hat, und legt die maximale JVM-Heap-Größe auf 256 MB fest. Der Standardwert legt keine Optionen für Instances fest, die Amazon Linux ausführen.
   + Gibt den `['datasources]`-Attributwert an, der dem Webanwendungs-Kontextnamen ("ROOT") einen JDBC-Ressourcennamen ("jdbc/mydb") zuweist, wie unter [tomcat::context](create-custom-configure.md#create-custom-configure-context) erläutert.

     Dieses letzte Attribut hat keinen Standardwert. Sie müssen es mit benutzerdefinierter JSON festlegen.  
![\[Configuration Management interface showing Chef version options and custom JSON input field.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/tom_add_stack.png)

1. Klicken Sie auf **Add a layer (Einen Layer hinzufügen)**. Wählen Sie für **Layer type (Ebenentyp)** die Option **MySQL** aus. Klicken Sie dann auf **Add Layer (Ebene hinzufügen)**.

1. Klicken Sie im Navigationsbereich auf **Instances** und dann auf **Add an instance (Eine Instance hinzufügen)**. Klicken Sie auf **Add Instance (Instance hinzufügen)**, um die Standardeinstellungen zu übernehmen. Klicken Sie in der Zeile für die Instance auf **start (starten)**.

1. Kehren Sie zur Seite **Layers (Ebenen)** zurück und klicken Sie auf **\$1 Layer (\$1Ebene)**, um einen Layer hinzuzufügen. Klicken Sie für **Layer type (Ebenentyp)** auf **Custom (Benutzerdefiniert)**. Das Beispiel verwendet **TomCustom** bzw. **tomcustom** als Namen bzw. Kurznamen des Layers.  
![\[Add Layer form with Custom layer type, Name, and Short name fields for creating a customized layer.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/tom_add_custom_layer.png)

1. Klicken Sie auf der Seite **Layers (Ebenen)** für den entsprechenden benutzerdefinierten Layer auf **Recipes (Rezepte)** und dann auf **Edit (Bearbeiten)**. Weisen Sie unter **Custom Chef Recipes (Benutzerdefinierte Chef-Rezepte)** den Lebenszyklusereignissen des Layers Tomcat-Rezeptbuchrezepte wie folgt zu:
   + Für **Setup (Einrichtung)** geben Sie tomcat::setup**tomcat::setup** ein und klicken Sie auf **\$1**.
   + Für **Configure (Konfigurieren)** geben Sie **tomcat::configure** ein und klicken Sie auf **\$1**.
   + Für **Deploy (Bereitstellen)** geben Sie **tomcat::deploy** ein und klicken Sie auf **\$1**. Klicken Sie dann auf **Save (Speichern)**.

     .  
![\[Custom Chef Recipes interface showing setup, configure, and deploy steps with options.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/tom_events.png)

1. Klicken Sie im Navigationsbereich auf **Apps** und dann auf **Add an app (Eine App hinzufügen)**. Geben Sie die folgenden Optionen an und klicken Sie dann auf **Add App (App hinzufügen)**:
   + **Name** — Der Name der App; im Beispiel wird SimpleJSP verwendet und der von OpsWorks Stacks generierte Kurzname lautet simplejsp.
   + **App-Typ** **— Stellen Sie diese Option auf Andere ein.**

     OpsWorks Stacks stellt automatisch Standard-App-Typen auf den zugehörigen Serverinstanzen bereit. Wenn Sie **App type (Typ hinzufügen)** auf "Other (Andere)" festlegen, führt OpsWorks Stacks einfach die Bereitstellungsrezepte aus und lässt diese die Bereitstellung verarbeiten.
   + **Dokumentenstamm** — Stellen Sie diese Option auf ein. **ROOT**

     Der Wert **Document root (Dokumentenstamm)** gibt den Kontextnamen an.
   + **Repository-Typ** — Stellen Sie diese Option auf **S3** Archive ein.
   + **Repository-URL** — Stellen Sie hier die Amazon S3 S3-URL der App ein, die Sie zuvor erstellt haben.

   Verwenden Sie für die anderen Optionen die Standardeinstellungen.  
![\[Application settings form with fields for name, app type, document root, and source details.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/tom_app.png)

1. Verwenden Sie die Seite „**Instances**“, um dem TomCustom Layer eine Instance hinzuzufügen und sie zu starten. OpsWorks Stacks führt die Deploy-Rezepte automatisch auf einer neuen Instance aus, nachdem die Setup-Rezepte abgeschlossen sind, sodass beim Starten der Instance auch SimpleJSP bereitgestellt wird.

1. Wenn die TomCustom Instanz online ist, klicken Sie auf der Instanzenseite auf den Instanznamen, um die zugehörigen Details zu **sehen**. Kopieren Sie die öffentliche IP-Adresse. Erstellen Sie dann eine URL wie folgt: http://*publicIP**appname.jsp*/tc/. Für das Beispiel sieht diese URL etwa folgendermaßen aus: **http://50.218.191.172/tc/simplejsp.jsp**.
**Anmerkung**  
Die Apache-URL, die Anfragen an Tomcat weiterleitet, ist auf das `['tomcat']['apache_tomcat_bind_path']`-Standardattribut, `/tc/`, festgelegt. Das SimpleJSP-Dokumenten-Stammverzeichnis ist auf `ROOT` festgelegt, einen speziellen Wert, der aufgelöst wird in `/`. Die URL lautet daher "... /tc/simplejsp.jsp".

1. Fügen Sie die URL aus dem vorherigen Schritt in Ihren Browser ein. Sie sollten Folgendes sehen:

   ```
   Databases found:
   information_schema
   simplejsp
   test
   ```
**Anmerkung**  
Wenn Ihr Stack über eine MySQL-Instanz verfügt, erstellt OpsWorks Stacks automatisch eine Datenbank für jede App, die mit dem Kurznamen der App benannt ist.