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.

# OpsWorks Stacks-Ebenenreferenz
<a name="layers"></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).

Jede Instanz, die OpsWorks Stacks bereitstellt, muss mindestens einer Ebene angehören, die die Rolle einer Instanz im Stack definiert und die Einzelheiten der Einrichtung und Konfiguration der Instanz, der Installation von Paketen, der Bereitstellung von Anwendungen usw. steuert. Weitere Informationen zur Verwendung der OpsWorks Stacks zum Erstellen und Verwalten von Ebenen finden Sie unter. [Layer](workinglayers.md)

Jede Layer-Beschreibung enthält eine Liste der integrierten Rezepte, die OpsWorks Stacks für jedes Lifecycle-Ereignis der Ebene ausführt. Diese Rezepte werden in [https://github.com/aws/Opsworks-Cookbooks](https://github.com/aws/opsworks-cookbooks) gespeichert. Beachten Sie, dass die Listen nur die Rezepte enthalten, die direkt von Stacks ausgeführt werden. OpsWorks Diese Rezepte führen manchmal abhängige Rezepte aus, die nicht aufgeführt sind. Wenn Sie für ein bestimmtes Ereignis die vollständige Liste der Rezepte sehen möchten, einschließlich der abhängigen und benutzerdefinierten Rezepte, prüfen Sie die Ausführungsliste im entsprechenden [Chef-Protokoll](troubleshoot-debug-log.md) des Lebenszyklusereignisses.

**Topics**
+ [HAProxy Layer-Referenz](layers-load.md)
+ [HAProxy OpsWorks Stacks-Ebene](layers-haproxy.md)
+ [MySQL-Ebenenreferenz](layers-mysql.md)
+ [OpsWorks MySQL-Schicht](workinglayers-db-mysql.md)
+ [Referenz für Anwendungsserver-Layer](layers-server.md)
+ [Anwendungsserverebene](workinglayers-servers.md)
+ [Referenz zur ECS-Clusterschicht](#w2ab1c14c71b9c21c23)
+ [Referenz für benutzerdefinierte Layer](layers-other-custom.md)
+ [Referenz für andere Layer](layers-other.md)
+ [Andere Layer](workinglayers-other.md)

# HAProxy Layer-Referenz
<a name="layers-load"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Eine HAProxy Schicht verwendet einen zuverlässigen [HAProxy](http://haproxy.1wt.eu/) TCP/HTTP Hochleistungs-Loadbalancer, um hochverfügbare Lastenausgleichs- und Proxydienste für TCP- und HTTP-basierte Anwendungen bereitzustellen. Das ist besonders nützlich für Websites, die unter sehr hohen Belastungen durchsucht werden müssen und gleichzeitig Persistenz- oder Layer 7-Verarbeitung erfordern.

HAProxy überwacht den Datenverkehr und zeigt die Statistiken und den Zustand der zugehörigen Instanzen auf einer Webseite an. Standardmäßig lautet der URI http://*DNSName*/haproxy? stats, wo *DNSName* ist der HAProxy DNS-Name der Instanz.

**Short name (Kurzname):** lb

**Kompatibilität:** Ein HAProxy Layer ist mit den folgenden Layern kompatibel: custom, db-master und memcached.

**Offene Ports:** HAProxy ermöglicht den öffentlichen Zugriff auf die Ports 22 (SSH), 80 (HTTP) und 443 (HTTPS).

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig aktiviert

**Default EBS volume (Standard-EBS-Volume):** Nein

**Standard-Sicherheitsgruppe:** AWS-OpsWorks-LB-Server

**Konfiguration:** Um einen HAProxy Layer zu konfigurieren, müssen Sie Folgendes angeben:
+ URI Health die Integritätsprüfung (Standard: http://*DNSName*/).
+ Statistik-URI (Standard: http://*DNSName*/haproxy? Statistiken).
+ Passwort für Statistik (optional).
+ Methode für Zustandsprüfung (optional). HAProxy Verwendet standardmäßig die HTTP OPTIONS-Methode. Sie können auch GET oder HEAD angeben.
+ Statistiken aktivieren (optional)
+ Ports. Standardmäßig ist OpsWorks Stacks so konfiguriert, HAProxy dass es sowohl HTTP- als auch HTTPS-Verkehr verarbeitet. [Sie können so konfigurieren HAProxy , dass nur das eine oder das andere verarbeitet wird, indem Sie die Chef-Konfigurationsvorlage überschreiben.](https://github.com/aws/opsworks-cookbooks/tree/master-chef-11.4/haproxy/templates/default) `haproxy.cfg.erb`

**Setup recipes (Einrichtungsrezepte):**
+  opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ haproxy

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ haproxy::configure

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default
+ haproxy::configure 

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default
+ haproxy::stop

**Installation (Installation):**
+ OpsWorks Stacks verwendet das Paketinstallationsprogramm der Instanz, um die Installation HAProxy an den Standardspeicherorten durchzuführen.
+ Sie müssen Syslog so einrichten, dass die Protokolldateien an einen bestimmten Speicherort geleitet werden. Weitere Informationen finden Sie unter [HAProxy](http://haproxy.1wt.eu/).

# HAProxy OpsWorks Stacks-Ebene
<a name="layers-haproxy"></a>

**Anmerkung**  
Dieser Layer steht nur für Chef 11 und niedrigere Linux-basierte Stacks zur Verfügung.

Die OpsWorks HAProxy Stacks-Ebene ist eine OpsWorks Stacks-Ebene, die einen Blueprint für Instances bereitstellt, die einen [HAProxy](http://haproxy.1wt.eu/)Server hosten — ein zuverlässiger Hochleistungs-Lastenausgleich. TCP/HTTP Eine kleine Instance ist normalerweise ausreichend für die Verarbeitung des gesamten Datenverkehrs des Anwendungsservers. 

**Anmerkung**  
Stacks sind auf eine einzelne Region begrenzt. Um Ihre Anwendung über mehrere Regionen zu verteilen, müssen Sie für jede Region einen separaten Stack erstellen.

**Um eine Ebene zu erstellen HAProxy**

1. Klicken Sie im Navigationsbereich auf **Layers (Layers)**.

1. Klicken Sie auf der Seite **Layers (Layers)** auf **Add a Layer (Einen Layer hinzufügen)** oder auf **\$1 Layer (\$1 Layer)**. Wählen Sie als **Ebenentyp** die Option aus **HAProxy**.

Der Layer verfügt über die folgenden Konfigurationseinstellungen, die alle optional sind.

**HAProxy Statistiken**  
Unabhängig davon, ob der Layer Statistiken sammelt oder anzeigt. Der Standardwert ist **Yes**.

**Statistics URL (URL für Statistiken)**  
Der URL-Pfad der Statistikseite. Die vollständige URL lautet http://*DNSName**StatisticsPath*, wobei *DNSName* der DNS-Name der zugehörigen Instanz steht. Der *StatisticsPath* Standardwert ist /haproxy? stats, was etwa entspricht: http://ec2-54-245-151-7.us-west-2.compute.amazonaws.com/haproxy?stats.

**Statistics user name (Benutzername für Statistiken)**  
Der Benutzername der Statistikseite, den Sie angeben müssen, um die Statistikseite aufrufen zu können. Der Standardwert ist „opsworks“.

**Statistics password (Passwort für Statistiken)**  
Ein Passwort für die Statistikseite, das Sie eingeben müssen, um die Statistikseite zu sehen. Der Standardwert ist eine zufällig erstellte Zeichenfolge.

**Health check URL (URL für Zustandsprüfung)**  
Das URL-Suffix für die Integritätsprüfung. HAProxy verwendet diese URL, um in regelmäßigen Abständen eine HTTP-Methode auf jeder Anwendungsserverinstanz aufzurufen, um festzustellen, ob die Instanz funktioniert. Wenn die Integritätsprüfung fehlschlägt, wird die Weiterleitung des Datenverkehrs zur Instance HAProxy gestoppt, bis sie neu gestartet wird, entweder manuell oder durch [auto Reparatur.](workinginstances-autohealing.md) Der Standardwert für das URL-Suffix ist „/“, was der Homepage der Serverinstanz entspricht: http:///. *DNSName* 

**Health check method (Methode für Zustandsprüfung)**  
Eine HTTP-Methode, die in der Regel überprüft, ob Instances funktionieren. Der Standardwert ist **OPTIONS** und Sie können auch **GET** oder **HEAD** angeben. Weitere Informationen finden Sie unter [httpchk](http://cbonte.github.io/haproxy-dconv/configuration-1.5.html). 

**Benutzerdefinierte Sicherheitsgruppen**  
Diese Einstellung wird angezeigt, wenn Sie Ihren Layern nicht automatisch eine integrierte OpsWorks Stacks-Sicherheitsgruppe zuordnen möchten. Sie müssen die mit der Ebene zu verknüpfende Sicherheitsgruppe angeben. Stellen Sie sicher, dass die Gruppe über die richtigen Einstellungen verfügt, um Datenverkehr zwischen den Layern zu erlauben. Weitere Informationen finden Sie unter [Erstellen eines neuen Stacks](workingstacks-creating.md).

![\[HAProxy layer configuration form with options for statistics and health check settings.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/add_layer_haproxy.png)


**Anmerkung**  
Notieren Sie sich das Passwort für die spätere Verwendung. In OpsWorks Stacks können Sie das Passwort nicht anzeigen, nachdem Sie die Ebene erstellt haben. Sie können das Passwort jedoch aktualisieren, indem Sie auf die Seite **Edit (Bearbeiten)** des Layers wechseln und auf **Update password (Passwort aktualisieren)** auf der Registerkarte **General Settings (Allgemeine Einstellungen)** klicken.  

![\[HAProxy layer settings interface with options for statistics, health checks, and auto healing.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/haproxy_update_password.png)


## So funktioniert die HAProxy Ebene
<a name="w2ab1c14c71b9c21c13c19"></a>

 HAProxy Führt standardmäßig Folgendes aus:
+ Empfängt Anfragen auf den HTTP- und HTTPS-Ports.

  Sie können so konfigurieren HAProxy , dass nur der HTTP- oder HTTPS-Port abgehört wird, indem Sie die Chef-Konfigurationsvorlage überschreiben. `haproxy.cfg.erb`
+ Leitet den eingehenden Datenverkehr an Instances, die zu einem Anwendungsserver-Layer gehören.

  Standardmäßig ist OpsWorks Stacks so konfiguriert, dass der Datenverkehr HAProxy an Instanzen verteilt wird, die Mitglieder einer beliebigen Anwendungsserverschicht sind. Sie könnten beispielsweise einen Stack mit den Ebenen Rails App Server und PHP App Server haben, und ein HAProxy Master verteilt den Traffic auf die Instanzen in beiden Schichten. Sie können die Standard-Routing-Einstellungen konfigurieren, indem Sie eine benutzerdefiniertes Rezept verwenden.
+ Verteilt den Datenverkehr auf mehrere Availability Zones.

  Wenn eine Availability Zone ausfällt, leitet der Load Balancer den eingehenden Datenverkehr an Instances in anderen Zonen, sodass Ihre Anwendung weiterhin ohne Unterbrechung ausgeführt wird. Aus diesem Grund ist es ein empfohlenes Verfahren, Ihre Anwendungsserver über mehrere Availability Zones hinweg zu verteilen.
+ Führt in regelmäßigen Abständen die angegebene Methode für Zustandsprüfungen auf jeder Anwendungsserver-Instance aus, um ihren Zustand zu bewerten.

  Wenn die Methode nicht innerhalb eines bestimmten Timeout-Zeitraums zurückkehrt, wird davon ausgegangen, dass die Instanz ausgefallen ist, und HAProxy beendet die Weiterleitung von Anfragen an die Instanz. OpsWorks Stacks bietet auch eine Möglichkeit, ausgefallene Instances automatisch zu ersetzen. Weitere Informationen finden Sie unter [Verwenden von Auto Healing](workinginstances-autohealing.md). Sie können die Methode der Zustandsprüfung beim Erstellen des Layers ändern. 
+ Sammelt Statistiken und zeigt sie optional auf einer Webseite.

**Wichtig**  
Damit die Zustandsprüfung einwandfrei mit der standardmäßig verwendeten OPTIONS-Methode funktioniert, muss Ihre Anwendung einen 2xx- oder 3xx-Statuscode zurückgeben.

Wenn Sie einer HAProxy Ebene eine Instance hinzufügen, weist OpsWorks Stacks ihr standardmäßig eine Elastic IP-Adresse zu, um die weltweit öffentliche Anwendung darzustellen. Da die HAProxy Elastic IP-Adresse die einzige öffentliche URL der Anwendung ist, müssen Sie keine öffentlichen Domänennamen für die unterstrichenen Anwendungsserver-Instances erstellen und verwalten. Sie erhalten die Adresse, indem Sie die Seite **Instances (Instances)** aufrufen und die öffentliche IP-Adresse überprüfen, wie in der folgenden Abbildung gezeigt. Eine Adresse, die von (EIP) gefolgt wird, ist eine Elastic IP-Adresse. Weitere Informationen zu Elastic IP-Adressen finden Sie unter [Elastic IP Addresses (EIP) (Elastic IP-Adressen (EIP))](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html). 

![\[HAProxy instance table showing hostname, status, size, type, AZ, and public IP address.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/load_balancer_elastic_ip.png)


Wenn Sie eine HAProxy Instance beenden, behält OpsWorks Stacks die Elastic IP-Adresse bei und weist sie der Instance neu zu, wenn Sie sie neu starten. Wenn Sie eine HAProxy Instance löschen, löscht OpsWorks Stacks standardmäßig die IP-Adresse der Instance. Um die Adresse zu bewahren, löschen Sie die Option zum **Delete instance's Elastic IP (Löschen der Elastic IP der Instance)**, wie in der folgenden Abbildung dargestellt.

![\[HAProxy instance deletion confirmation dialog with option to retain Elastic IP address.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/delete_lb.png)


Diese Option wirkt sich auf das aus, was passiert, wenn Sie zu dem Layer eine neue Instance hinzufügen, um eine gelöschte Instance zu ersetzen:
+ Wenn Sie die Elastic IP-Adresse der gelöschten Instance beibehalten haben, weist OpsWorks Stacks die Adresse der neuen Instance zu.
+ Andernfalls weist OpsWorks Stacks der Instance eine neue Elastic IP-Adresse zu und Sie müssen Ihre DNS-Registrar-Einstellungen aktualisieren, damit sie der neuen Adresse zugeordnet werden.

Wenn Anwendungsserver-Instances online gehen oder offline gehen — entweder manuell oder als Folge der [automatischen Skalierung](workinginstances-autoscaling.md) oder [auto Heilung](workinginstances-autohealing.md) — muss die Load Balancer-Konfiguration aktualisiert werden, um den Datenverkehr an die aktuellen Online-Instanzen weiterzuleiten. Diese Aufgabe wird automatisch von den integrierten Rezepten des Layers durchgeführt:
+ [Wenn neue Instances online gehen, löst OpsWorks Stacks ein Configure-Lifecycle-Ereignis aus.](workingcookbook-events.md) Die in der HAProxy Ebene integrierten Configure-Rezepte aktualisieren die Load Balancer-Konfiguration, sodass Anfragen auch an alle neuen Anwendungsserver-Instanzen verteilt werden.
+ Wenn Instanzen offline gehen oder eine Instance eine Integritätsprüfung nicht besteht, löst OpsWorks Stacks auch ein Configure-Lifecycle-Ereignis aus. Mit den HAProxy Configure-Rezepten wird die Load Balancer-Konfiguration aktualisiert, sodass der Datenverkehr nur an die verbleibenden Online-Instanzen weitergeleitet wird. 

Schließlich können Sie auch eine benutzerdefinierte Domäne mit dem HAProxy Layer verwenden. Weitere Informationen finden Sie unter [Verwenden von benutzerdefinierten Domänen](workingapps-domains.md). 

## Die Statistikseite
<a name="w2ab1c14c71b9c21c13c21"></a>

Wenn Sie die Statistikseite aktiviert haben, HAProxy wird eine Seite mit einer Vielzahl von Metriken unter der angegebenen URL angezeigt.

**Um HAProxy Statistiken anzuzeigen**

1. Rufen Sie den **öffentlichen DNS-Namen** der HAProxy Instance von der **Detailseite** der Instance ab und kopieren Sie ihn.

1. Klicken Sie auf der Seite **Layers** auf **HAProxy**, um die Detailseite des Layers zu öffnen.

1. Rufen Sie die Statistik-URL aus den Layer-Details ab und hängen Sie sie an den öffentlichen DNS-Namen an. Zum Beispiel: **http://ec2-54-245-102-172.us-west-2.compute.amazonaws.com/haproxy?stats**.

1. Fügen Sie die URL aus dem vorherigen Schritt in Ihren Browser ein und verwenden Sie den Benutzernamen und das Passwort, die Sie angegeben haben, als Sie den Layer erstellt haben, um die Statistikseite zu öffnen.   
![\[HAProxy statistics report showing process information and session data for frontend and backend servers.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/haproxy_stats.png)

# MySQL-Ebenenreferenz
<a name="layers-mysql"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Die MySQL-Schicht unterstützt MySQL, ein weit verbreitetes relationales Datenbankverwaltungssystem. OpsWorks Stacks installiert die neueste verfügbare Version, die vom Betriebssystem abhängt. Wenn Sie eine MySQL-Instance hinzufügen, werden den Anwendungsserver-Layern die benötigten Zugriffsinformationen bereitgestellt. Sie müssen benutzerdefinierte Chef-Rezepte schreiben, um Master-Master- oder Master-Slave-Konfigurationen einzurichten. 

**Short name (Kurzname):** db-master

**Kompatibilität:** Eine MySQL-Schicht ist mit den folgenden Ebenen kompatibel: custom, lb, memcached, monitoring-master, nodejs-app, php-App, rails-app und web.

**Offene Ports:** Eine MySQL-Schicht ermöglicht den öffentlichen Zugriff auf Port 22 (SSH) und alle Ports von den Webservern, benutzerdefinierten Servern und den Anwendungsservern Rails, PHP und Node.js des Stacks.

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS volume (Standard-EBS-Volume):** Ja, bei `/vol/mysql`

**Standard-Sicherheitsgruppe: -Server** AWS-OpsWorks-DB-Master 

**Konfiguration:** Um eine MySQL-Schicht zu konfigurieren, müssen Sie Folgendes angeben:
+ Stammbenutzerpasswort
+ MySQL-Engine

**Setup recipes (Einrichtungsrezepte):**
+  opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ mysql::server
+ vermeiden
+ deploy::mysql 

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ deploy::mysql 

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default
+ deploy::mysql 

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default
+ mysql::stop

**Installation (Installation):**
+ OpsWorks Stacks verwendet das Paketinstallationsprogramm der Instanz, um MySQL und seine Protokolldateien an ihren Standardspeicherorten zu installieren. Weitere Informationen finden Sie in der [MySQL-Dokumentation](http://dev.mysql.com/doc/index.html).

# OpsWorks MySQL-Schicht
<a name="workinglayers-db-mysql"></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).

**Anmerkung**  
Dieser Layer steht nur für Chef 11 und niedrigere Linux-basierte Stacks zur Verfügung.

Eine OpsWorks MySQL-Ebene bietet einen Blueprint für EC2 Amazon-Instances, die als [MySQL-Datenbankmaster](http://www.mysql.com/) fungieren. Mithilfe eines integrierten Rezepts erstellen Sie eine Datenbank für jede Anwendung, die für einen Anwendungsserver-Layer bereitgestellt wurde. Wenn Sie beispielsweise eine PHP-Anwendung "MeineApp" erstellen, erstellt die Vorlage eine "MeineApp"-Datenbank.

Die MySQL-Schicht hat die folgenden Konfigurationseinstellungen.

**MySQL root user password (Passwort für MySQL-Root-Benutzer)**  
Passwort des Root-Benutzers (erforderlich)

**Set root user password on every instance (Root-Benutzer-Passwort für jede Instance setzen)**  
Legt fest, ob das Passwort des Root-Benutzers in den Stack-Konfigurations- und Bereitstellungsattributen enthalten ist, die für jede Instance des Stacks installiert werden (optional). Die Standardeinstellung ist **Yes (Ja)**.  
Wenn Sie diesen Wert auf **Nein** setzen, gibt OpsWorks Stacks das Root-Passwort nur an Anwendungsserver-Instanzen weiter.

**Benutzerdefinierte Sicherheitsgruppen**  
Eine benutzerdefinierte Sicherheitsgruppe, die dem Layer zugeordnet wird (optional). Weitere Informationen finden Sie unter [Erstellen eines neuen Stacks](workingstacks-creating.md).

![\[Add layer interface for MySQL database setup with OpsWorks, ECS, and RDS options.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/add_layer_mysql.png)


Sie können dem Layer eine oder mehrere Instances hinzufügen. Dabei repräsentiert jeder Layer eine eigene MySQL-Master-Datenbank. Fügen Sie dann [einer App eine Instance hinzu](workingapps-creating.md), um die erforderlichen Verbindungsinformationen in den Anwendungsservern der App zu speichern. Die Anwendung kann nun die Verbindungsinformationen verwenden, um [eine Verbindung zum Datenbankserver der Instance herzustellen](workingapps-connectdb.md).

# Referenz für Anwendungsserver-Layer
<a name="layers-server"></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).

OpsWorks Stacks unterstützt mehrere verschiedene Anwendungs- und statische Webseitenserver.

**Topics**
+ [Referenz zur AWS-Flow-Schicht (Ruby)](layers-server-flow.md)
+ [Referenz zur Java-App-Serverschicht](layers-server-java.md)
+ [Referenz auf die App-Serverschicht von Node.js](layers-server-nodejs.md)
+ [Referenz zur PHP-App-Serverschicht](layers-server-php.md)
+ [Referenz zur Rails-App Serverschicht](layers-server-rails.md)
+ [Referenz auf statische Webserverebene](layers-server-static.md)

# Referenz zur AWS-Flow-Schicht (Ruby)
<a name="layers-server-flow"></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**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Eine AWS Flow (Ruby) -Ebene bietet einen Blueprint für Instances, die Amazon Simple Workflow Service-Aktivitäten und Workflow-Worker hosten.

**Kurzname:** aws-flow-ruby

**Kompatibilität:** Eine AWS Flow (Ruby) -Schicht ist mit PHP App Server, MySQL, Memcached, Ganglia und benutzerdefinierten Ebenen kompatibel.

**Open ports (Offene Ports):** Keine

**IAM-Rolle:** aws-opsworks-ec 2- role-with-swf ist die standardmäßige AWS Flow (Ruby) -Rolle, die OpsWorks Stacks auf Anfrage für Sie erstellt.

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS Volume (Standard EBS-Volume)** Nein

**Standard-Sicherheitsgruppe**: -Ruby-Server AWS-OpsWorks-AWS-Flow

**Setup recipes (Einrichtungsrezepte):**
+ opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ opsworks\$1aws\$1flow\$1ruby::setup

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ mysql::client
+ agent\$1version
+ opsworks\$1aws\$1flow\$1ruby::configure 

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default
+ bereitstellen:: aws-flow-ruby 

**Undeploy recipes (Bereitstellung von Rezepten aufheben):**
+ bereitstellen:: aws-flow-ruby-undeploy

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default

# Referenz zur Java-App-Serverschicht
<a name="layers-server-java"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Ein Java App Server-Layer unterstützt einen [Apache Tomcat 7.0-Anwendungsserver](http://tomcat.apache.org/).

**Short name (Kurzname):** java-app

**Kompatibilität:** Eine Java App Server-Schicht ist mit den folgenden Ebenen kompatibel: custom, db-master und memcached.

**Offene Ports:** Eine Java App Server-Schicht ermöglicht den öffentlichen Zugriff auf die Ports 22 (SSH), 80 (HTTP), 443 (HTTPS) und alle Ports von Load Balancers.

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS Volume (Standard EBS-Volume)** Nein

**Standard-Sicherheitsgruppe**: -Server AWS-OpsWorks-Java-App

**Setup recipes (Einrichtungsrezepte):**
+ opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ opsworks\$1java::setup

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ opsworks\$1java::configure 

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default
+ deploy::java 

**Undeploy recipes (Bereitstellung von Rezepten aufheben):**
+ deploy::java-undeploy

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default
+ deploy::java-stop

**Installation (Installation):**
+ Tomcat wird in `/usr/share/tomcat7` installiert.
+ Weitere Informationen dazu, wie Protokolldateien erstellt werden, finden Sie unter [Logging in Tomcat](http://tomcat.apache.org/tomcat-6.0-doc/logging.html).

# Referenz auf die App-Serverschicht von Node.js
<a name="layers-server-nodejs"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Ein App-Server-Layer von Node.js unterstützt einen Anwendungsserver vom [Typ Node.js](http://nodejs.org/). Dabei handelt es sich um eine Plattform für die Implementierung hoch skalierbarer Netzwerkanwendungsserver. Programme werden ereignisgesteuert JavaScript und asynchron geschrieben, um den Overhead I/O zu minimieren und die Skalierbarkeit zu maximieren.

**Short name (Kurzname):** nodejs-app

**Kompatibilität:** Eine Node.js App Server-Ebene ist mit den folgenden Ebenen kompatibel: Benutzerdefiniert, DB-Master, Memcached und Monitoring-Master.

**Offene Ports:** Eine Node.js App Server-Ebene ermöglicht den öffentlichen Zugriff auf die Ports 22 (SSH), 80 (HTTP), 443 (HTTPS) und alle Ports von Load Balancers.

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS volume (Standard-EBS-Volume):** Nein

**Standard-Sicherheitsgruppe**: -Server AWS-OpsWorks-nodejs-App

**Setup recipes (Einrichtungsrezepte):**
+  opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ opsworks\$1nodejs
+ opsworks\$1nodejs::npm 

**Configure recipes (Konfigurationsrezepte)**
+  opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ opsworks\$1nodejs::configure 

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default
+ opsworks\$1nodejs
+ opsworks\$1nodejs::npm
+ deploy::nodejs 

**Undeploy recipes (Bereitstellung von Rezepten aufheben):**
+ deploy::nodejs-undeploy

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default
+ deploy::nodejs-stop

**Installation (Installation):**
+ Node.js wird in `/usr/local/bin/node` installiert.
+ Weitere Informationen zur Erstellung von Protokolldateien finden Sie unter [How to log in node.js](https://docs.nodejitsu.com/articles/intermediate/how-to-log/) auf der Nodejitsu-Website.

**Node.js application configuration (Node.js-Anwendungskonfiguration):**
+ Die von Node.js ausgeführte Hauptdatei muss `server.js` benannt werden und sich im Stammverzeichnis der bereitgestellten Anwendung befinden.
+ Die Node.js-Anwendung muss so festgelegt sein, dass Port 80 (oder Port 443, falls zutreffend) verwendet wird.

**Anmerkung**  
Node.js-Apps, die Express ausführen, verwenden normalerweise den folgenden Code, um den Überwachungsport festzulegen, wobei `process.env.PORT` den Standardport darstellt und in 80 aufgelöst wird:  

```
app.set('port', process.env.PORT || 3000);
```
Bei OpsWorks Stacks müssen Sie Port 80 explizit wie folgt angeben:  

```
app.set('port', 80);
```

# Referenz zur PHP-App-Serverschicht
<a name="layers-server-php"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Die PHP App Server-Ebene unterstützt einen PHP-Anwendungsserver unter Verwendung von [Apache2](http://httpd.apache.org/) mit mod\$1php.

**Short name (Kurzname):** php-app

**Kompatibilität:** Ein PHP-App-Server-Layer ist mit den folgenden Ebenen kompatibel: custom, db-Master, memcached, Monitoring-Master und Rails-App.

**Offene Ports:** Eine PHP-App-Server-Schicht ermöglicht den öffentlichen Zugriff auf die Ports 22 (SSH), 80 (HTTP), 443 (HTTPS) und alle Ports von Load Balancers.

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS volume (Standard-EBS-Volume):** Nein

**Standard-Sicherheitsgruppe**: -Server AWS-OpsWorks-PHP-App

**Setup recipes (Einrichtungsrezepte):**
+  opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ mysql::client
+ vermeiden
+ mod\$1php5\$1apache2 

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ mod\$1php5\$1apache2::php
+ php::configure 

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default
+ deploy::php 

**Undeploy recipes (Bereitstellung von Rezepten aufheben):**
+ deploy::php-undeploy

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default
+ apache2::stop 

**Installation (Installation): **
+  OpsWorks Stacks verwendet das Paketinstallationsprogramm der Instanz, um Apache2, mod\$1php und die zugehörigen Protokolldateien an ihren Standardspeicherorten zu installieren. Weitere Informationen zur Installation finden Sie unter [Apache](http://httpd.apache.org/). Weitere Informationen zur Protokollierung finden Sie unter [Log Files](http://httpd.apache.org/docs/2.2/logs.html).

# Referenz zur Rails-App Serverschicht
<a name="layers-server-rails"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Die Rails App Server-Schicht unterstützt einen [Ruby on Rails-Anwendungsserver](http://rubyonrails.org/).

**Short name (Kurzname):** rails-app

**Kompatibilität:** Eine Rails App Server-Schicht ist mit den folgenden Schichten kompatibel: Benutzerdefiniert, DB-Master, Memcached, Monitoring-Master, PHP-App.

**Ports:** Eine Rails App Server-Schicht ermöglicht den öffentlichen Zugriff auf die Ports 22 (SSH), 80 (HTTP), 443 (HTTPS) und alle Ports von Load Balancers.

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS volume (Standard-EBS-Volume):** Nein

**Standard-Sicherheitsgruppe**: -Server AWS-OpsWorks-Rails-App

**Konfiguration:** Um einen Rails App Server-Layer zu konfigurieren, müssen Sie Folgendes angeben:
+ Ruby-Version
+ Rails-Stack
+ Rubygems-Version
+ Ob [Bundler](http://gembundler.com/) installiert und verwaltet werden soll
+ Die Bundler-Version

**Setup recipes (Einrichtungsrezepte):**
+ opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ apache2 apache2::mod\$1deflate
+ passenger\$1apache2
+ passenger\$1apache2::mod\$1rails
+ passenger\$1apache2::rails 

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ rails::configure 

**Deploy recipes (Bereitstellungsrezepte)**
+ deploy::default
+ deploy::rails

**Undeploy recipes (Bereitstellung von Rezepten aufheben):**
+ deploy::rails-undeploy 

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default
+ apache2::stop 

**Installation (Installation):**
+ OpsWorks Stacks verwendet das Paketinstallationsprogramm der Instanz, um Apache2 mit mod\$1passenger, mod\$1rails und den zugehörigen Protokolldateien an ihren Standardspeicherorten zu installieren. Weitere Informationen über die Installation finden Sie unter [Phusion Passenger](https://www.phusionpassenger.com/). Weitere Informationen zur Protokollierung finden Sie unter [Log Files](http://httpd.apache.org/docs/2.2/logs.html).

# Referenz auf statische Webserverebene
<a name="layers-server-static"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Die statische Webserver-Ebene dient statischen HTML-Seiten, die clientseitigen Code enthalten können, wie z. JavaScript Er basiert auf [Nginx](http://nginx.org/en/), einem Open-Source-HTTP-, Reverse-Proxy- und Mail-Proxy-Server.

**Short name (Kurzname):** web

**Kompatibilität:** Eine statische Webserver-Ebene ist mit den folgenden Ebenen kompatibel: Benutzerdefiniert, DB-Master, Memcached.

**Offene Ports:** Eine statische Webserver-Schicht ermöglicht den öffentlichen Zugriff auf die Ports 22 (SSH), 80 (HTTP), 443 (HTTPS) und alle Ports von Load Balancers.

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS volume (Standard-EBS-Volume):** Nein

**Standard-Sicherheitsgruppe:** AWS-OpsWorks-Web-Server

**Setup recipes (Einrichtungsrezepte):**
+ opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ nginx 

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version 

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default
+ deploy::web 

**Undeploy recipes (Bereitstellung von Rezepten aufheben):**
+ deploy::web-undeploy

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default
+ nginx::stop

**Installation (Installation):**
+ Nginx wird in `/usr/sbin/nginx` installiert.
+ Nginx-Protokolldateien sind in `/var/log/nginx`.

# Anwendungsserverebene
<a name="workinglayers-servers"></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**  
Diese Ebenen sind nur für Chef 11 und frühere Linux-basierte Stacks verfügbar.

OpsWorks Stacks unterstützt mehrere verschiedene Anwendungsserver, wobei der Begriff „Anwendung“ statische Webseiten umfasst. Jeder Servertyp verfügt über eine separate OpsWorks Stacks-Ebene mit integrierten Rezepten, die die Installation des Anwendungsservers und aller zugehörigen Pakete auf den einzelnen Instanzen der Ebene, die Bereitstellung von Apps usw. übernehmen. Die Java App Server-Schicht installiert beispielsweise mehrere Pakete — darunter Apache, Tomcat und OpenJDK — und stellt Java-Apps auf jeder Instanz der Ebene bereit.

Nachfolgend wird das grundsätzliche Verfahren zur Verwendung einer Anwendungsserverebene beschrieben:

1. [Erstellen](workinglayers-basics-create.md) Sie eine der verfügbaren **App Server**-Ebenentypen.

1. [Fügen Sie eine oder mehrere Instances](workinginstances-add.md) der Ebene hinzu.

1. Erstellen Sie Anwendungen und stellen Sie sie den Instances bereit. Weitere Informationen finden Sie unter [Apps](workingapps.md).

1. (Optional) Wenn die Ebene über mehrere Instances verfügt, können Sie einen Load Balancer hinzufügen, der den eingehenden Datenverkehr an die Instances verteilt. Weitere Informationen finden Sie unter [HAProxy OpsWorks Stacks-Ebene](layers-haproxy.md).

**Topics**
+ [AWS-Flow-Schicht (Ruby)](workinglayers-awsflow.md)
+ [OpsWorks Stacks-Schicht für Java App Server](layers-java.md)
+ [Node.js App Server OpsWorks Stacks Layer](workinglayers-node.md)
+ [PHP-App-Server: OpsWorks Stacks-Layer](workinglayers-php.md)
+ [Rails App Server Stacks Layer OpsWorks](workinglayers-rails.md)
+ [Statischer Webserver: OpsWorks Stacks Layer](workinglayers-static.md)

# AWS-Flow-Schicht (Ruby)
<a name="workinglayers-awsflow"></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**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Eine AWS Flow (Ruby) -Ebene ist eine OpsWorks Stacks-Ebene, die einen Blueprint für Instances bereitstellt, die [Amazon SWF SWF-Aktivitäten](https://docs.aws.amazon.com/amazonswf/latest/developerguide/swf-welcome.html) und Workflow-Worker hosten. Die Worker werden mithilfe des [AWS Flow Framework for Ruby](https://docs.aws.amazon.com/amazonswf/latest/awsrbflowguide/welcome.html) implementiert, einem Programmier-Framework, das den Prozess der Implementierung einer verteilten asynchronen Anwendung vereinfacht und gleichzeitig alle Vorteile von Amazon SWF bietet. Es ist ideal für die Implementierung von Anwendungen in verschiedensten Szenarien, einschließlich Geschäftsprozessen, Media-Kodierung, Aufgaben mit langen Ausführungszeiten und Hintergrundverarbeitung.

Die AWS Flow (Ruby) -Schicht umfasst die folgenden Konfigurationseinstellungen.

**RubyGems Version**  
Die Framework-Version des Gems. 

**Bundler-Version**  
Die [Bundler](http://bundler.io/)-Version.

**EC2 Instanzprofil**  
Ein benutzerdefiniertes EC2 Amazon-Instance-Profil, das von den Instances des Layers verwendet werden soll. Dieses Profil muss Anwendungen, die auf den Instances des Layers ausgeführt werden, Berechtigungen für den Zugriff auf Amazon SWF gewähren.

Wenn Ihr Konto kein geeignetes Profil hat, können Sie **Neues Profil mit SWF-Zugriff** auswählen, damit OpsWorks Stacks das Profil aktualisiert, oder Sie können es selbst mithilfe der [IAM-Konsole](https://console.aws.amazon.com/iam/) aktualisieren. Das aktualisierte Profil können Sie anschließend für alle nachfolgenden AWS Flow-Ebenen verwenden. Im Folgenden finden Sie eine kurze Beschreibung, wie Sie das Profil mithilfe der IAM-Konsole erstellen. Weitere Informationen finden Sie unter [Identity and Access Management in Amazon Simple Workflow Service](https://docs.aws.amazon.com/amazonswf/latest/developerguide/swf-dev-iam.html).

**Erstellen eines Profils für AWS Flow (Ruby) -Instances**

1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.

1. Wählen Sie im Navigationsbereich **Richtlinien** und dann **Richtlinie erstellen** aus, um eine neue vom Kunden verwaltete Richtlinie zu erstellen.

1. Wählen Sie für **Service** die Option **SWF** aus.

1. Wählen Sie für **Aktionen** die Option **Alle SWF-Aktionen (swf: \$1)**. 

1. Geben Sie für **Amazon Resource Name (ARN)** den ARN ein, der angibt, auf welche Amazon SWF-Domänen die Worker zugreifen können. Wählen Sie aus**All resources**, ob Sie Zugriff auf alle Domänen gewähren möchten.

1. Wählen Sie **Weiter** aus.

1. Geben Sie optional ein Tag ein, um die Richtlinie zu identifizieren.

1. Wählen Sie **Weiter** aus.

1. Wenn Sie fertig sind, wählen Sie **Richtlinie erstellen** aus.

1. Wählen Sie im Navigationsbereich **Rollen** und dann **Rolle erstellen** aus.

1. Geben Sie den Rollennamen an und wählen Sie **Next Step** aus. Sie können den Namen nicht ändern, nachdem die Rolle erstellt wurde.

1. Wählen Sie **AWS-Service** und dann ** EC2**.

1. Wählen Sie **Weiter** aus.

1. Wählen Sie aus der Liste der **Berechtigungsrichtlinien** die Richtlinie aus, die Sie zuvor erstellt haben.

1. Wählen Sie **Weiter** aus.

1. Geben Sie einen Rollennamen ein und klicken Sie auf **Create Role (Rolle erstellen)**. Sie können den Namen nicht ändern, nachdem die Rolle erstellt wurde.

1. Geben Sie dieses Profil an, wenn Sie eine AWS Flow (Ruby) -Layer in OpsWorks Stacks erstellen.

# OpsWorks Stacks-Schicht für Java App Server
<a name="layers-java"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Die Java App Server-Schicht ist eine OpsWorks Stacks-Schicht, die einen Entwurf für Instanzen bereitstellt, die als Java-Anwendungsserver fungieren. Diese Schicht basiert auf [Apache Tomcat 7.0](http://tomcat.apache.org/) und [Open JDK 7.](http://openjdk.java.net/) OpsWorks Stacks installiert auch die Java-Connector-Bibliothek, mit der Java-Apps mithilfe eines `DataSource` JDBC-Objekts eine Verbindung zu einem Back-End-Datenspeicher herstellen können.

**Installation**: Tomcat wird installiert in `/usr/share/tomcat7`.

Auf der Seite **Add Layer (Ebene hinzufügen)** stehen folgende Konfigurationsoptionen zur Verfügung:

**Java-VM-Optionen**  
Mit dieser Einstellung können Sie die benutzerdefinierten Java-VM-Optionen definieren. Es existieren keine Standard-Optionen. Ein oft verwendeter Optionssatz lautet `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC`. Wenn Sie **Java VM Options** verwenden, stellen Sie sicher, dass Sie einen gültigen Satz von Optionen übergeben. OpsWorks Stacks validiert die Zeichenfolge nicht. Wenn Sie versuchen, eine ungültige Option anzugeben, startet der Tomcat-Server in der Regel nicht, sodass die Einrichtung fehlschlägt. In diesem Fall können Sie dem Chef-Setup-Protokoll der Instance weitere Details entnehmen. Weitere Informationen zur Anzeige und Deutung der Chef-Protokolle finden Sie unter [Chef-Protokolle](troubleshoot-debug-log.md).

**Benutzerdefinierte Sicherheitsgruppen**  
Diese Einstellung wird angezeigt, wenn Sie Ihren Layern nicht automatisch eine integrierte OpsWorks Stacks-Sicherheitsgruppe zuordnen möchten. Sie müssen die mit der Ebene zu verknüpfende Sicherheitsgruppe angeben. Weitere Informationen finden Sie unter [Erstellen eines neuen Stacks](workingstacks-creating.md).

**Elastic Load Balancer**  
Sie können einen Elastic Load Balancing Load Balancer an die Instances des Layers anhängen. Weitere Informationen finden Sie unter [Elastic Load Balancing Lastenausgleichsebene](layers-elb.md).

Mit einem benutzerdefinierten JSON-Objekt oder einer benutzerdefinierten Attributdatei können Sie andere Konfigurationseinstellungen angeben. Weitere Informationen finden Sie unter [Benutzerdefinierte Konfiguration](layers-java-config.md).

**Wichtig**  
Wenn Ihre Java-Anwendung SSL verwendet, empfehlen wir, diese Option nach Möglichkeit zu deaktivieren SSLv3 , um die in [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566) beschriebenen Sicherheitslücken zu beheben. Weitere Informationen finden Sie unter [Deaktivierung für Apache Server SSLv3](#layers-java-sslv3).

**Topics**
+ [Deaktivierung für Apache Server SSLv3](#layers-java-sslv3)
+ [Benutzerdefinierte Konfiguration](layers-java-config.md)
+ [Bereitstellen von Java-Anwendungen](layers-java-deploy.md)

## Deaktivierung für Apache Server SSLv3
<a name="layers-java-sslv3"></a>

Zum Deaktivieren SSLv3 müssen Sie die Dateieinstellungen des Apache-Servers `ssl.conf` ändern. `SSLProtocol` Dazu müssen Sie die `ssl.conf.erb` Vorlagendatei des integrierten [Apache2-Kochbuchs](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/apache2) überschreiben, die in den Setup-Rezepten des Java App Server-Layers erstellt wird. `ssl.conf` Die Details hängen davon ab, welches Betriebssystem Sie für die Ebenen-Instances angeben. Im Folgenden werden die erforderlichen Änderungen für Amazon Linux- und Ubuntu-Systeme zusammengefasst. SSLv3 ist für Red Hat Enterprise Linux (RHEL) -Systeme automatisch deaktiviert. Weitere Informationen zum Überschreiben einer integrierten Vorlage finden Sie unter [Verwenden von benutzerdefinierten Vorlagen](workingcookbook-template-override.md).

**Amazon Linux**  
Die Datei `ssl.conf.erb` für diese Betriebssysteme befindet sich im Verzeichnis `apache2` cookbook's `apache2/templates/default/mods`. Das folgende Beispiel zeigt den relevanten Teil der integrierten Datei.  

```
...
#SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

# enable only secure protocols: SSLv3 and TLSv1.2, but not SSLv2
SSLProtocol all -SSLv2
</IfModule>
```
Überschreiben Sie `ssl.conf.erb` und ändern Sie die `SSLProtocol`-Einstellung folgendermaßen.  

```
...
#SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

# enable only secure protocols: SSLv3 and TLSv1.2, but not SSLv2
SSLProtocol all -SSLv3 -SSLv2
</IfModule>
```

**Ubuntu 14.04 LTS**  
Die Datei `ssl.conf.erb` für dieses Betriebssystem befindet sich im Verzeichnis `apache2` cookbook's `apache2/templates/ubuntu-14.04/mods`. Das folgende Beispiel zeigt den relevanten Teil der integrierten Datei.  

```
...
# The protocols to enable.
# Available values: all, SSLv3, TLSv1.2
# SSL v2 is no longer supported
SSLProtocol all
...
```
Ändern Sie diese Einstellung folgendermaßen.  

```
...
# The protocols to enable.
# Available values: all, SSLv3, TLSv1.2
# SSL v2 is no longer supported
SSLProtocol all -SSLv3 -SSLv2
...
```

# Benutzerdefinierte Konfiguration
<a name="layers-java-config"></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).

OpsWorks Stacks stellt zusätzliche Konfigurationseinstellungen als integrierte Attribute zur Verfügung, die sich alle im Namespace befinden. `opsworks_java` Sie können eine benutzerdefinierte JSON- oder Attributdatei angeben, um die integrierten Attribute zu überschreiben und benutzerdefinierte Werte anzugeben. Die JVM- und Tomcat-Versionen werden beispielsweise von den integrierten `jvm_version`- und `java_app_server_version`-Attributen repräsentiert, die auf den Wert 7 gesetzt sind. Sie können eine oder beide mithilfe einer benutzerdefinierte JSON- oder Attributdatei auf den Wert 6 setzen. In dem folgenden Beispiel werden beide Attribute mithilfe einer benutzerdefinierten JSON-Datei auf den Wert 6 gesetzt:

```
{
  "opsworks_java": {
    "jvm_version": 6,
    "java_app_server_version" : 6
  }
}
```

Weitere Informationen finden Sie unter [Nutzen eines benutzerdefinierten JSON-Objekts](workingstacks-json.md).

Ein weiteres Beispiel für eine benutzerdefinierte Konfiguration besteht in der Installation eines benutzerdefinierten JDK, um die Attribute `use_custom_pkg_location` und `custom_pkg_location_url_debian`, `custom_pkg_location_url_rhel` zu überschreiben. 

**Anmerkung**  
Wenn Sie die integrierten Rezeptbücher überschreiben, müssen Sie diese Komponenten selbst aktualisieren. 

Weitere Informationen zu Attributen und wie diese überschrieben werden können, finden Sie unter [Überschreiben der Attribute](workingcookbook-attributes.md). Eine Liste der integrierten Attribute finden Sie unter [opsworks\$1java-Attribute](attributes-recipes-java.md).

# Bereitstellen von Java-Anwendungen
<a name="layers-java-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).

In den folgenden Themen wird beschrieben, wie Apps auf den Instanzen eines Java App Server-Layers bereitgestellt werden. In den Beispielen werden JSP-Anwendungen verwendet, aber Sie können zum Installieren von anderen Java-Anwendungsarten grundsätzlich in gleicher Weise vorgehen.

Sie können JSP-Seiten aus einem der unterstützten Repositorys bereitstellen. Wenn Sie WAR-Dateien bereitstellen möchten, beachten Sie, dass OpsWorks Stacks automatisch WAR-Dateien extrahiert, die aus einem Amazon S3- oder HTTP-Archiv bereitgestellt werden, aber nicht aus einem Git- oder Subversion-Repository. Wenn Sie Git oder Subversion für WAR-Dateien verwenden möchten, können Sie einen der folgenden Schritte ausführen:
+ Speichern Sie das extrahierte Archiv im Repository.
+ Speichern Sie die WAR-Datei im Repository und verwenden Sie zum Extrahieren des Archivs einen Chef-Bereitstellungs-Hook, wie im nachstehenden Beispiel beschrieben.

Sie können Chef-Bereitstellungs-Hooks verwenden, um vom Benutzer angegebene Ruby-Anwendungen in einer Instance in irgendeiner der vier Bereitstellungsstufen auszuführen. Die Phase wird durch den Anwendungsnamen bestimmt. Im folgenden Beispiel wird eine Ruby-Anwendung mit dem Namen `before_migrate.rb` beschrieben, die eine von einem Git- oder Subversion-Repository bereitgestellte WAR-Datei extrahiert. Der Name verknüpft die Anwendung mit dem Checkout-Bereitstellungs-Hook, sodass dieser zu Beginn der Bereitstellung nach erfolgter Prüfung des Codes, aber vor der Migration ausgeführt wird. Weitere Informationen zur Verwendung dieses Beispiels finden Sie unter [Verwenden von Chef-Bereitstellungs-Hooks](workingcookbook-extend-hooks.md).

```
::Dir.glob(::File.join(release_path, '*.war')) do |archive_file|
  execute "unzip_#{archive_file}" do
    command "unzip #{archive_file}"
    cwd release_path
  end
end
```

**Anmerkung**  
Wenn Sie eine Aktualisierung für eine JSP-Anwendung bereitstellen, wird Tomcat die Aktualisierung möglicherweise nicht erkennen und stattdessen die vorhandene Anwendungsversion ausführen. Dies kann beispielsweise auftreten, wenn Sie die Anwendung als ZIP-Datei bereitstellen, die nur eine JSP-Seite enthält. Um sicherzustellen, dass Tomcat die zuletzt bereitgestellte Version ausführt, muss das Stammverzeichnis des Projekts das Verzeichnis "WEB-INF" mit einer Datei `web.xml` enthalten. Der Inhalt einer `web.xml`-Datei kann vielfältig sein. Nachstehendes ist jedoch ausreichend, um sicherzustellen, dass Tomcat die Aktualisierungen erkennt und die aktuell bereitgestellte Anwendungsversion ausführt. Sie müssen die Version nicht für jede Aktualisierung ändern. Tomcat erkennt die Aktualisierung auch dann, wenn sich die Version nicht geändert hat.  

```
<context-param>
  <param-name>appVersion</param-name>
  <param-value>0.1</param-value>
</context-param>
```

**Topics**
+ [Bereitstellen einer JSP-Anwendung](#layers-java-deploy-jsp)
+ [Bereitstellen einer JSP-Anwendung mit einer Backend-Datenbank](#layers-java-deploy-jsp-db)

## Bereitstellen einer JSP-Anwendung
<a name="layers-java-deploy-jsp"></a>

Geben Sie zur Bereitstellung einer JSP-Anwendung den Namen und die Repository-Daten an. Außerdem können Sie optional Domänen und SSL-Einstellungen angeben. Weitere Informationen zum Erstellen einer Anwendung finden Sie unter [Hinzufügen von Apps](workingapps-creating.md). Das folgende Verfahren zeigt, wie Sie eine einfache JSP-Seite aus einem öffentlichen Amazon S3 S3-Archiv erstellen und bereitstellen. Informationen zur Verwendung anderer Repository-Typen, einschließlich privater Amazon S3 S3-Archive, finden Sie unter[Anwendungsquelle](workingapps-creating.md#workingapps-creating-source).

Das folgende Beispiel zeigt die JSP-Seite, auf der lediglich einige Systeminformationen aufgeführt sind.

```
<%@ page import="java.net.InetAddress" %>
<html>
<body>
<%
    java.util.Date date = new java.util.Date();
    InetAddress inetAddress = InetAddress.getLocalHost();
%>
The time is 
<%
    out.println( date );
    out.println("<br>Your server's hostname is "+inetAddress.getHostName());
%>
<br>
</body>
</html>
```

**Anmerkung**  
Im folgenden Verfahren wird davon ausgegangen, dass Sie bereits mit den Grundlagen zum Erstellen von Stacks, Hinzufügen von Instances zu Ebenen usw. vertraut sind. Wenn Sie OpsWorks Stacks noch nicht kennen, sollten Sie zuerst nachlesen[Erste Schritte mit Chef 11 Linux-Stacks](gettingstarted.md).

**So stellen Sie eine JSP-Seite aus einem Amazon S3 S3-Archiv bereit**

1. [Erstellen Sie einen Stack](workingstacks-creating.md) mit einem Java App Server-Layer, [fügen Sie dem Layer eine 24/7-Instance](workinginstances-add.md) hinzu und [starten Sie ihn](workinginstances-starting.md). 

1. Kopieren Sie den Code in eine Datei mit dem Namen `simplejsp.jsp`, speichern Sie die Datei in einem Verzeichnis mit dem Namen `simplejsp` und erstellen Sie ein `.zip`-Archiv des Verzeichnisses. Die Namen sind willkürlich. Sie können beliebige Datei- oder Verzeichnisnamen verwenden. Sie können auch andere Archivtypen verwenden, einschließlich gzip, bzip2, Tarball oder Java WAR. Beachten Sie, dass OpsWorks Stacks keine unkomprimierten Tarballs unterstützt. Um mehrere JSP-Seiten bereitzustellen, fügen Sie diese zu demselben Archiv hinzu.

1. Laden Sie das Archiv in einen Amazon S3 S3-Bucket hoch und veröffentlichen Sie die Datei. Kopieren Sie die URL der Datei zur späteren Verwendung. Weitere Informationen zum Erstellen von Buckets und Hochladen von Dateien finden Sie unter [Erste Schritte mit Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)

1. Klicken Sie auf [Hinzufügen einer Anwendung](workingapps-creating.md#workingapps-creating-general) zum Stack und geben Sie folgende Einstellungen an:
   + **Name (Name** – `SimpleJSP`
   + **App type** – `Java`
   + **Repository-Typ** – `Http Archive`
   + **Repository-URL** — die Amazon S3 S3-URL Ihrer Archivdatei.

   Verwenden Sie die Standardwerte für die übrigen Einstellungen und klicken Sie anschließend auf **Add App (App hinzufügen)**, um die Anwendung zu erstellen.

1. [Stellen Sie die App](workingapps-deploying.md) auf der Java App Server-Instance bereit.

Sie können jetzt die URL der Anwendung aufrufen und die Anwendung anzeigen. Wenn Sie keine Domäne angegeben haben, können Sie eine URL erstellen, indem Sie entweder die öffentliche IP-Adresse und den öffentlichen DNS-Namen der Instance verwenden. Um die öffentliche IP-Adresse oder den öffentlichen DNS-Namen einer Instanz abzurufen, gehen Sie zur OpsWorks Stacks-Konsole und klicken Sie auf der Seite **Instances** auf den Namen der Instanz, um deren Detailseite zu öffnen. 

Der Rest der URL hängt vom Kurznamen der App ab. Dabei handelt es sich um einen Namen in Kleinbuchstaben, den OpsWorks Stacks aus dem Namen der App generiert, den Sie bei der Erstellung der App angegeben haben. Der Kurzname von SimpleJSP, beispielsweise, lautet simplejsp. Sie können den Kurznamen einer Anwendung aus ihrer Detailseite entnehmen. 
+ Wenn der Kurzname `root` lautet, können Sie entweder `http://public_DNS/appname.jsp` oder `http://public_IP/appname.jsp` verwenden.
+ Andernfalls können Sie entweder `http://public_DNS/app_shortname/appname.jsp` oder `http://public_IP/app_shortname/appname.jsp` verwenden. 

Wenn Sie eine Domäne für die Anwendung angegeben haben, lautet die URL `http://domain/appname.jsp`.

Die URL sollte in etwa wie folgt aussehen: `http://192.0.2.0/simplejsp/simplejsp.jsp`.

Wenn Sie mehrere Anwendungen für dieselbe Instance bereitstellen möchten, dürfen Sie `root` nicht als Kurznamen verwenden. Dies kann URL-Konflikte verursachen, die verhindern, dass die Anwendung ordnungsgemäß funktioniert. Weisen Sie stattdessen den Anwendungen jeweils unterschiedliche Domänennamen zu.

## Bereitstellen einer JSP-Anwendung mit einer Backend-Datenbank
<a name="layers-java-deploy-jsp-db"></a>

JSP-Seiten können ein JDBC-`DataSource`-Objekt verwenden, um eine Verbindung mit einer Backend-Datenbank zu erstellen. Sie können eine Anwendung erstellen und bereitstellen, indem Sie das im vorherigen Abschnitt beschriebene Verfahren anwenden. Dabei ist ein zusätzlicher Schritt auszuführen, um die Verbindung einzurichten.

Auf der folgenden JSP-Seite wird die Verbindungsherstellung zu einem `DataSource`-Objekt dargestellt.

```
<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>
```

OpsWorks Stacks erstellt und initialisiert das `DataSource` Objekt, bindet es an einen logischen Namen und registriert den Namen bei einem Java Naming and Directory Interface (JNDI) -Namensdienst. Der vollständige logische Name lautet `java:comp/env/user-assigned-name`. Sie müssen den vom Benutzer zugewiesenen Teil des Namens angeben, indem Sie benutzerdefinierte JSON-Attribute zur Stack-Konfiguration und zu den Bereitstellungsattributen hinzufügen, um das Attribut `['opsworks_java']['datasources']` zu definieren, wie nachfolgend beschrieben. 

**So stellen Sie eine JSP-Seite bereit, die eine Verbindung mit einer MySQL-Datenbank herstellt**

1. [Erstellen Sie einen Stack](workingstacks-creating.md) [mit einer Java App Server-Ebene, [fügen Sie jeder Ebene rund um die Uhr verfügbare Instanzen](workinginstances-add.md) hinzu und starten Sie sie.](workinginstances-starting.md) 

1. Fügen Sie eine Datenbankebene zum Stack hinzu. Die Details hängen davon ab, welche Datenbank Sie verwenden.

   Um eine MySQL-Instanz für das Beispiel zu verwenden, [fügen Sie dem Stack eine MySQL-Ebene](workinglayers-db-mysql.md) [hinzu, fügen Sie der Ebene eine 24/7-Instanz](workinginstances-add.md) hinzu und [starten Sie sie](workinginstances-starting.md#workinginstances-starting-start).

   Um eine Amazon RDS (MySQL) -Instance für das Beispiel zu verwenden:
   + Geben Sie eine MySQL-Datenbank-Engine für die Instance an.
   + Weisen Sie der **Instance die Sicherheitsgruppen AWS- OpsWorks -DB-Master-Server (*security\$1group\$1id*)** und **AWS- OpsWorks -Java-App-Server** () zu. *security\$1group\$1id* OpsWorks Stacks erstellt diese Sicherheitsgruppen für Sie, wenn Sie Ihren ersten Stack in der Region erstellen.
   + Erstellen Sie eine Datenbank mit dem Namen `simplejspdb`.
   + Stellen Sie sicher, dass der Master-Benutzername und das Passwort nicht `&` oder andere Zeichen enthalten, die einen Tomcat-Fehler verursachen können.

     Insbesondere während des Starts muss Tomcat die Kontextdatei der Webanwendung analysieren. Diese XML-Datei enthält den Master-Benutzernamen und das Paswort. Wenn eine der Zeichenfolgen ein `&`-Zeichen enthält, interpretiert der XML-Parser dies als manipuliertes XML-Objekt und löst eine Parsing-Ausnahme aus, sodass Tomcat nicht starten kann. Weitere Informationen über die Kontextdatei der Webanwendung finden Sie unter [tomcat::context](create-custom-configure.md#create-custom-configure-context).
   + [Fügen Sie der Java App Server-Schicht einen MySQL-Treiber](workingapps-connectdb.md) hinzu.
   + [Registrieren Sie die RDS-Instance](workinglayers-db-rds.md#workinglayers-db-rds-register) mit Ihrem Stack. 

   Weitere Informationen zur Verwendung von Amazon RDS-Instances mit OpsWorks Stacks finden Sie unter[Amazon RDS-Serviceschicht](workinglayers-db-rds.md).

1. Kopieren Sie den Beispiel-Code in eine Datei mit dem Namen `simplejspdb.jsp`, speichern Sie die Datei in einem Verzeichnis mit dem Namen `simplejspdb` und erstellen Sie ein `.zip`-Archiv des Verzeichnisses. Die Namen sind willkürlich. Sie können beliebige Datei- oder Verzeichnisnamen verwenden. Sie können auch andere Archivierungstypen einschließlich gzip, bzip2 oder Tarball verwenden. Um mehrere JSP-Seiten bereitzustellen, fügen Sie diese zu demselben Archiv hinzu. Weitere Informationen zur Bereitstellung von Anwendungen aus anderen Repository-Typen finden Sie unter [Anwendungsquelle](workingapps-creating.md#workingapps-creating-source).

1. Laden Sie das Archiv in einen Amazon S3 S3-Bucket hoch und veröffentlichen Sie die Datei. Kopieren Sie die URL der Datei zur späteren Verwendung. Weitere Informationen zum Erstellen von Buckets und Hochladen von Dateien finden Sie unter [Erste Schritte mit Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html)

1. Klicken Sie auf [Hinzufügen einer Anwendung](workingapps-creating.md#workingapps-creating-general) zum Stack und geben Sie folgende Einstellungen an:
   + **Name (Name** – `SimpleJSPDB`
   + **App type** – `Java`
   + **Datenquellentyp** — **OpsWorks**(für eine MySQL-Instance) oder **RDS** (für eine Amazon RDS-Instance).
   + **Datenbank-Instance** — Die zuvor erstellte MySQL-Instance, die normalerweise den Namen **db-master1 (mysql)** trägt, oder die Amazon RDS-Instance, die den Namen ***DB\$1instance\$1name*(**mysql) erhalten wird.
   + **Datenbankname** – `simplejspdb`.
   + **Repository-Typ** – `Http Archive`
   + **Repository-URL** — die Amazon S3 S3-URL Ihrer Archivdatei.

   Verwenden Sie die Standardwerte für die übrigen Einstellungen und klicken Sie anschließend auf **Add App (App hinzufügen)**, um die Anwendung zu erstellen.

1. Fügen Sie die folgenden benutzerdefinierten JSON-Attribute zu den Stack-Konfigurationsattributen hinzu, wobei simplejspdb der Kurzname der Anwendung ist.

   ```
   {
     "opsworks_java": {
       "datasources": {
         "simplejspdb": "jdbc/mydb" 
       }
     }
   }
   ```

   OpsWorks Stacks verwendet diese Zuordnung, um eine Kontextdatei mit den erforderlichen Datenbankinformationen zu generieren.

   Weitere Informationen zum Hinzufügen benutzerdefinierter JSON-Attribute zu den Stack-Konfigurationsattributen finden Sie unter [Nutzen eines benutzerdefinierten JSON-Objekts](workingstacks-json.md).

1. [Stellen Sie die App](workingapps-deploying.md) auf der Java App Server-Instanz bereit.

Nun können Sie die Anwendung mit ihrer URL anzeigen. Eine Beschreibung zur Erstellung der URL finden Sie unter [Bereitstellen einer JSP-Anwendung](#layers-java-deploy-jsp). 

Die URL sollte in etwa wie folgt aussehen: `http://192.0.2.0/simplejspdb/simplejspdb.jsp`.

**Anmerkung**  
Das `datasources`-Attribut kann mehrere Attribute enthalten. Jedes Attribut wird mit dem Namen des Kurznamens einer Anwendung bezeichnet und wird auf den entsprechenden, vom Benutzer zugewiesenen Teil eines logischen Namen gesetzt. Wenn Sie über mehrere Anwendungen verfügen, können Sie verschiedene logischen Namen verwenden. Dazu ist ein benutzerdefiniertes JSON-Objekt erforderlich, das in etwa wie folgt aussieht.  

```
{
  "opsworks_java": {
    "datasources": {
      "myjavaapp": "jdbc/myappdb",
      "simplejsp": "jdbc/myjspdb",
      ...
    }
  }
}
```

# Node.js App Server OpsWorks Stacks Layer
<a name="workinglayers-node"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

[Die App Server-Ebene von Node.js ist eine OpsWorks Stacks-Ebene, die einen Blueprint für Instanzen bereitstellt, die als Node.js -Anwendungsserver fungieren.](http://nodejs.org/) OpsWorks Stacks installiert auch [Express](http://expressjs.com/), sodass die Instanzen des Layers sowohl Standard- als auch Express-Anwendungen unterstützen.

**Installation**: Node.js wird installiert in `/usr/local/bin/node`.

Auf der Seite **Add Layer (Ebene hinzufügen)** stehen folgende Konfigurationsoptionen zur Verfügung:

**Node.js-Version**  
Eine Liste der gegenwärtig unterstützten Versionen finden Sie unter [OpsWorks Stacks-Betriebssysteme](workinginstances-os.md).

**Benutzerdefinierte Sicherheitsgruppen**  
Diese Einstellung wird angezeigt, wenn Sie Ihren Layern nicht automatisch eine integrierte OpsWorks Stacks-Sicherheitsgruppe zuordnen möchten. Sie müssen die mit der Ebene zu verknüpfende Sicherheitsgruppe angeben. Weitere Informationen finden Sie unter [Erstellen eines neuen Stacks](workingstacks-creating.md).

**Elastic Load Balancer**  
Sie können einen Elastic Load Balancing Load Balancer an die Instances des Layers anhängen.

**Wichtig**  
Wenn Ihre Anwendung Node.js SSL verwendet, empfehlen wir Ihnen, dies nach Möglichkeit zu deaktivieren SSLv3 , um die in [CVE-2015-8027](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8027) beschriebenen Sicherheitslücken zu beheben. Um dies zu tun, müssen Sie **Node.js version** auf `0.12.9` festlegen.

## Bereitstellen von Node.js-Anwendungen
<a name="w2ab1c14c71b9c21c21c19c17"></a>

Eine detaillierte Anleitung zur Implementierung einer einfachen Node.js-Anwendung für OpsWorks Stacks und Bereitstellung für einen Stack finden Sie unter [Erstellen Ihres ersten Node.js-Stacks](gettingstarted-node.md). Normalerweise müssen Node.js-Anwendungen für OpsWorks Stacks folgende Bedingungen erfüllen:
+ Die Hauptdatei muss den Namen `server.js` haben und im Stammverzeichnis der Anwendung abgelegt sein.
+ Im Stammverzeichnis von [Express-](http://expressjs.com/)-Anwendungen muss die Datei `package.json` vorhanden sein.
+ Standardmäßig muss die Anwendung über Port 80 (HTTP) oder Port 443 (HTTPS) kommunizieren.

  Es ist möglich, andere Ports abzuhören, aber die integrierte Sicherheitsgruppe der App Server-Schicht von Node.js, **AWS- OpsWorks -NodeJS-App-Server**, lässt eingehenden Benutzerverkehr nur zu den Ports 80, 443 und 22 (SSH) zu. [Um eingehenden Benutzerverkehr zu anderen Ports zuzulassen, [erstellen Sie eine Sicherheitsgruppe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) mit entsprechenden Regeln für eingehenden Datenverkehr und weisen Sie sie der App Server-Schicht Node.js zu.](workinglayers-basics-edit.md#workinglayers-basics-edit-security) Ändern Sie keine Regeln für eingehenden Datenverkehr durch Bearbeiten der integrierten Sicherheitsgruppe. Jedes Mal, wenn Sie einen Stack erstellen, überschreibt OpsWorks Stacks die integrierten Sicherheitsgruppen mit den Standardeinstellungen, sodass alle von Ihnen vorgenommenen Änderungen verloren gehen.

**Anmerkung**  
OpsWorks Stacks setzt die Umgebungsvariable PORT auf 80 (Standard) oder 443 (wenn Sie SSL aktivieren), sodass Sie den folgenden Code verwenden können, um auf Anfragen zu warten.  

```
app.listen(process.env.PORT);
```

Wenn Sie [eine App Node.js für die Unterstützung von SSL konfigurieren](workingapps-creating.md#workingapps-creating-domain-ssl), müssen Sie den Schlüssel und die Zertifikate angeben. OpsWorks Stacks platziert die Daten für jede Anwendungsserverinstanz wie folgt als separate Dateien im `/srv/www/app_shortname/shared/config` Verzeichnis.
+ `ssl.crt`— das SSL-Zertifikat.
+ `ssl.key`— der SSL-Schlüssel.
+ `ssl.ca`— das Kettenzertifikat, falls Sie eines angegeben haben.

Ihre Anwendung kann die SSL-Schlüssel und Zertifikate aus diesen Dateien beziehen.

# PHP-App-Server: OpsWorks Stacks-Layer
<a name="workinglayers-php"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Die PHP App Server-Ebene ist eine OpsWorks Stacks-Ebene, die einen Entwurf für Instanzen bereitstellt, die als PHP-Anwendungsserver fungieren. Die PHP App Server-Schicht basiert auf [Apache2](http://httpd.apache.org/) mit `mod_php` und hat keine Standardkonfigurationsoptionen. Die PHP- und Apache-Version hängt davon ab, welches [Betriebssystem](workinginstances-os.md) Sie für die Ebene der Instances angeben. 


| Betriebssystem | PHP-Version | Apache-Version | 
| --- | --- | --- | 
| Amazon Linux 2018.03 | 5.3 | 2.2 | 
| Amazon Linux 2017.09 | 5.3 | 2.2 | 
| Amazon Linux 2017.03 | 5.3 | 2.2 | 
| Amazon Linux 2016.09 | 5.3 | 2.2 | 
| Amazon Linux 2016.03 | 5.3 | 2.2 | 
| Amazon Linux 2015.09 | 5.3 | 2.2 | 
| Amazon Linux 2015.03 | 5.3 | 2.2 | 
| Amazon Linux 2014.09 | 5.3 | 2.2 | 
| Ubuntu 14.04 LTS | 5.5 | 2.4 | 

**Installation**: OpsWorks Stacks verwendet das Paketinstallationsprogramm der Instanz, um Apache2 und `mod_php` an ihren Standardspeicherorten zu installieren. Weitere Informationen zur Installation finden Sie unter [Apache](http://httpd.apache.org/).

Auf der Seite **Add Layer (Ebene hinzufügen)** stehen folgende Konfigurationsoptionen zur Verfügung:

**Benutzerdefinierte Sicherheitsgruppen**  
Diese Einstellung wird angezeigt, wenn Sie Ihren Layern nicht automatisch eine integrierte OpsWorks Stacks-Sicherheitsgruppe zuordnen möchten. Sie müssen die mit der Ebene zu verknüpfende Sicherheitsgruppe angeben. Weitere Informationen finden Sie unter [Erstellen eines neuen Stacks](workingstacks-creating.md).

**Elastic Load Balancer**  
Sie können einen Elastic Load Balancing Load Balancer an die Instances des Layers anhängen.

Mit einer benutzerdefinierten JSON- oder Attributdatei können einige Apache-Konfigurationseinstellungen geändert werden. Weitere Informationen finden Sie unter [Überschreiben der Attribute](workingcookbook-attributes.md). Eine Liste der überschreibbaren Apache-Attribute finden Sie unter [apache2-Attribute](attributes-recipes-apache.md).

Ein Beispiel für die Bereitstellung einer PHP-Anwendung einschließlich der Verbindung zu einer Backend-Datenbank finden Sie unter [Erste Schritte mit Chef 11 Linux-Stacks](gettingstarted.md).

**Wichtig**  
Wenn Ihre PHP-Anwendung SSL verwendet, empfehlen wir Ihnen, dies nach Möglichkeit zu deaktivieren SSLv3 , um die in [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566) beschriebenen Sicherheitslücken zu beheben. Dazu müssen Sie die Einstellung `SSLProtocol` in der Datei `ssl.conf` des Apache-Servers ändern. Weitere Informationen zum Ändern dieser Einstellung finden Sie unter [Deaktivierung für Apache Server SSLv3](layers-java.md#layers-java-sslv3).

# Rails App Server Stacks Layer OpsWorks
<a name="workinglayers-rails"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Die Rails App Server-Schicht ist eine OpsWorks Stacks-Schicht, die einen Entwurf für Instanzen bereitstellt, die als Rails-Anwendungsserver fungieren.

**Installation**: OpsWorks Stacks verwendet das Paketinstallationsprogramm der Instanz, um die Serverpakete an ihren Standardspeicherorten zu installieren. Weitere Informationen zur Apache/Passenger Installation finden Sie unter [Phusion Passenger](https://www.phusionpassenger.com/). Weitere Informationen zur Protokollierung finden Sie unter [Log Files](http://httpd.apache.org/docs/2.2/logs.html). Weitere Informationen zur Nginx/Unicorn Installation finden Sie unter [Unicorn](http://unicorn.bogomips.org/).

Auf der Seite **Add Layer (Ebene hinzufügen)** stehen folgende Konfigurationsoptionen zur Verfügung, die alle optional sind.

**Ruby-Version**  
Die von Ihren Anwendungen verwendete Ruby-Version. Der Standardwert ist 2.3.  
Sie können auch Ihre bevorzugte Ruby-Version durch [Überschreiben des `[:opsworks][:ruby_version]`](workingcookbook-attributes.md)-Attributs angeben.  
OpsWorks Stacks installiert ein separates Ruby-Paket, das von Rezepten und dem Instanzagenten verwendet wird. Weitere Informationen finden Sie unter [Ruby-Versionen](workingcookbook-ruby.md).

**Rails-Stack**  
Der standardmäßige Rails-Stack lautet [Apache2](http://httpd.apache.org/) mit [Phusion Passenger](https://www.phusionpassenger.com/). Sie können auch [Nginx](http://nginx.org/en/) mit [Unicorn](http://unicorn.bogomips.org/) verwenden.  
Wenn Sie Ngnix und Unicorn verwenden, müssen Sie das Nginx- und Unicorn-Gem zur Gem-Datei Ihrer Anwendung hinzufügen, wie im folgenden Beispiel dargestellt:  

```
source 'https://rubygems.org'
gem 'rails', '3.2.15'
...
# Use unicorn as the app server
gem 'unicorn'
...
```

**Passenger-Version**  
Wenn Sie Apache2/Passenger angegeben haben, müssen Sie die Passenger-Version definieren. Der Standardwert ist 5.0.28.

**RubyGems-Version**  
Die standardmäßige [Rubygems](http://rubygems.org/)-Version ist 2.5.1.

**Bundler installieren und verwalten**  
Hier können Sie wählen, ob der [Bundler](http://gembundler.com/) installiert werden soll. Der Standardwert ist **Yes**.

**Bundler-Version**  
Die standardmäßige Bundler-Version ist 1.12.5.

**Benutzerdefinierte Sicherheitsgruppen**  
Diese Einstellung wird angezeigt, wenn Sie Ihren Layern nicht automatisch eine integrierte OpsWorks Stacks-Sicherheitsgruppe zuordnen möchten. Sie müssen die mit der Ebene zu verknüpfende Sicherheitsgruppe angeben. Weitere Informationen finden Sie unter [Erstellen eines neuen Stacks](workingstacks-creating.md).

**Elastic Load Balancer**  
Sie können einen Elastic Load Balancing Load Balancer an die Instances des Layers anhängen.

Mit einer benutzerdefinierten JSON- oder Attributdatei können einige Konfigurationseinstellungen geändert werden. Weitere Informationen finden Sie unter [Überschreiben der Attribute](workingcookbook-attributes.md). Eine Liste der überschreibbaren Apache-, Nginx-, Phusion Passenger- und Unicorn-Attribute finden Sie unter [Integrierte Rezeptbuchattribute](attributes-recipes.md).

**Wichtig**  
Wenn Ihre Ruby on Rails-Anwendung SSL verwendet, empfehlen wir Ihnen, dies nach Möglichkeit zu deaktivieren SSLv3 , um die in [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566) beschriebenen Sicherheitslücken zu beheben. Weitere Informationen finden Sie unter [Deaktivierung für Rails-Server SSLv3](#workinglayers-rails-sslv3).

**Topics**
+ [Deaktivierung für Rails-Server SSLv3](#workinglayers-rails-sslv3)
+ [Verbinden mit einer Datenbank](#workinglayers-rails-db)
+ [Bereitstellen von Ruby on Rails-Anwendungen](#workinglayers-rails-deploy)

## Deaktivierung für Rails-Server SSLv3
<a name="workinglayers-rails-sslv3"></a>

Um sie SSLv3 für Rails-Server zu deaktivieren, aktualisieren Sie die **Ruby-Versionseinstellung** des Layers auf 2.1 oder höher, wodurch Ruby 2.1.4 oder höher als die Version installiert wird, die Anwendungen verwenden.
+ Aktualisieren Sie die **Ruby Version-**-Einstellung der Ebene auf 2.1 oder höher.
+ Aktualisieren Sie die Konfigurationsdatei für Ihren Rails-Stack folgendermaßen.

**Apache mit Phusion Passenger**  
Aktualisieren Sie die `SSLProtocol`-Einstellung in der `ssl.conf`-Datei des Apache-Servers, wie in [Deaktivierung für Apache Server SSLv3](layers-java.md#layers-java-sslv3) beschrieben.

**Nginx mit Unicorn**  
Fügen Sie eine explizite `ssl_protocols`-Richtlinie zur `nginx.conf`-Datei des Nginx-Servers hinzu. Um sie zu deaktivieren SSLv3, überschreiben Sie die `nginx.conf.erb` Vorlagendatei [des integrierten Nginx-Kochbuchs](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/nginx), die die Setup-Rezepte der Rails-App Server-Schicht zum Erstellen verwenden`nginx.conf`, und fügen Sie die folgende Direktive hinzu:  

```
ssl_protocols TLSv1.2;
```
Weitere Informationen zum Konfigurieren von `nginx.conf` finden Sie unter [Configuring HTTPS servers](http://nginx.org/en/docs/http/configuring_https_servers.html). Weitere Informationen zum Überschreiben einer integrierten Vorlage finden Sie unter [Verwenden von benutzerdefinierten Vorlagen](workingcookbook-template-override.md).

## Verbinden mit einer Datenbank
<a name="workinglayers-rails-db"></a>

[Wenn Sie eine App bereitstellen, erstellt OpsWorks Stacks eine neue `database.yml` Datei mit Informationen aus den Attributen der App. `deploy`](workingcookbook-json.md#workingcookbook-json-deploy) Wenn Sie [eine MySQL- oder Amazon RDS-Instance an die App anhängen](workingapps-creating.md#workingapps-creating-data), fügt OpsWorks Stacks die Verbindungsinformationen zu den `deploy` Attributen hinzu, sodass sie `database.yml` automatisch die richtigen Verbindungsdaten enthalten. 

Wenn eine App keine angehängte Datenbank hat, fügt OpsWorks Stacks den `deploy` Attributen standardmäßig keine Verbindungsinformationen hinzu und erstellt auch keine. `database.yml` Wenn Sie eine andere Datenbank verwenden möchten, können Sie mit einem benutzerdefinierten JSON-Objekt Verbindungsdaten enthaltende Datenbank-Attribute zu den `deploy`-Attributen der Anwendung hinzufügen. Die Attribute befinden sich alle unter`["deploy"]["appshortname"]["database"]`. Wo *appshortname* ist der Kurzname der App, den OpsWorks Stacks aus dem Namen der App generiert. Die in der benutzerdefinierten JSON-Datei angegebenen Werte überschreiben sämtliche Standardeinstellungen. Weitere Informationen finden Sie unter [Hinzufügen von Apps](workingapps-creating.md).

OpsWorks Stacks integriert die folgenden [`[:...][:database]`](attributes-json-deploy.md#attributes-json-deploy-app-db)Attributwerte in. `database.yml` Die erforderlichen Attribute hängen von der jeweiligen Datenbank ab, aber Sie müssen über ein `host` Attribut verfügen, da OpsWorks Stacks sonst nichts erstellt. `database.yml`
+ `[:adapter] (String)`— Der Datenbankadapter, z. B. `mysql`
+ `[:database]`(String) — Der Datenbankname.
+ `[:encoding]`(String) — Die Kodierung, auf die normalerweise eingestellt ist`utf8`.
+ `[:host]`(String) — Die Host-URL, z. `railsexample.cdlqlk5uwd0k.us-west-2.rds.amazonaws.com` B.
+ `[:reconnect]`(Boolean) — Gibt an, ob die Anwendung erneut eine Verbindung herstellen soll, wenn die Verbindung nicht mehr besteht.
+ `[:password]`(String) — Das Datenbankkennwort.
+ `[:port]` (Zahl). — Die Portnummer der Datenbank. Mit diesem Attribut können Sie die Standard-Portnummer überschreiben, der vom Adapter vorgegeben wird.
+ `[:username]`(String) — Der Datenbankbenutzername.

Das folgende Beispiel zeigt ein benutzerdefiniertes JSON-Objekt für eine Anwendung mit dem Kurznamen *myapp*.

```
{
  "deploy" : {
    "myapp" : {
      "database" : {
        "adapter" : "adapter",
        "database" : "databasename",
        "host" : "host",
        "password" : "password",
        "port" : portnumber
        "reconnect" : true/false,
        "username" : "username"
      }
    }
  }
}
```

Weitere Informationen zur Definition eines benutzerdefinierten JSON-Objekts finden Sie unter [Nutzen eines benutzerdefinierten JSON-Objekts](workingstacks-json.md). Um die Vorlage zur Erstellung von `database.yml` (`database.yml.erb`) zu sehen, gehen Sie zu dem [integrierten Rezeptbuch-Repository](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/rails/templates/default).

## Bereitstellen von Ruby on Rails-Anwendungen
<a name="workinglayers-rails-deploy"></a>

Sie können Ruby on Rails-Anwendungen aus einem unterstützten Repository bereitstellen. Im Folgenden wird gezeigt, wie Sie eine Ruby on Rails-Beispiel-App auf einem Server bereitstellen, auf dem ein Apache/Passenger Rails-Stack ausgeführt wird. Der Beispielcode wird in einem öffentlichen GitHub Repository gespeichert, aber das grundlegende Verfahren ist dasselbe für die anderen unterstützten Repositorys. Weitere Informationen zum Erstellen und Bereitstellen von Anwendungen finden Sie unter [Apps](workingapps.md). Den Code des Beispiels, der ausführliche Kommentare enthält, finden Sie unter [https://github.com/awslabs/opsworks-demo-rails-photo-share-app](https://github.com/awslabs/opsworks-demo-rails-photo-share-app). 

**Um eine Ruby on Rails-App aus einem Repository bereitzustellen GitHub**

1. [Erstellen Sie einen Stack](workingstacks-creating.md) mit einer Rails-App Server-Ebene Apache/Passenger als Rails-Stack, [fügen Sie der Ebene eine 24/7-Instanz](workinginstances-add.md) hinzu und [starten Sie sie](workinginstances-starting.md). 

1. Wenn die Instance online ist, [fügen Sie eine Anwendung](workingapps-creating.md#workingapps-creating-general) zum Stack hinzu und geben Sie folgenden Einstellungen an:
   + **Name** – Beliebiger Name, im Beispiel wird `PhotoPoll` verwendet.

     OpsWorks Stacks verwendet diesen Namen für Anzeigezwecke und generiert einen Kurznamen für den internen Gebrauch und zur Identifizierung der App in der [Stackkonfiguration und den Bereitstellungsattributen](workingcookbook-json.md). Der PhotoPoll Kurzname lautet beispielsweise photopoll.
   + **App type** – **Ruby on Rails**.
   + ** Rails environment** – Die verfügbaren Umgebungen werden von der Anwendung bestimmt.

     Die Beispiel-Anwendung hat drei Umgebungen: **development**, **test**, und **production**. In diesem Beispiel geben Sie für die Umgebung **development** an. Im Beispiel-Code sind weitere Beschreibungen für jede Umgebung enthalten.
   + **Repository-Typ** — Jeder der unterstützten Repository-Typen. Geben Sie `Git` für dieses Beispiel an.
   + **Repository URL** – Repository, aus dem der Code bereitzustellen ist.

     In diesem Beispiel geben Sie für die URL **git://github.com/awslabs/opsworks-demo-rails-photo-share-app** an.

   Verwenden Sie die Standardwerte für die übrigen Einstellungen und klicken Sie anschließend auf **Add App (App hinzufügen)**, um die Anwendung zu erstellen.

1. [Stellen Sie die App](workingapps-deploying.md) auf der Rails App Server-Instanz bereit.

1. Wenn die Bereitstellung abgeschlossen ist, gehen Sie zur Seite **Instanzen** und klicken Sie auf die öffentliche IP-Adresse der Rails App Server-Instanz. Sie sollten Folgendes sehen:

![\[Congratulatory message for deploying first app with AWS OpsWorks, with stylized logo.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/rails_example.png)


# Statischer Webserver: OpsWorks Stacks Layer
<a name="workinglayers-static"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Die statische Webserver-Ebene ist eine OpsWorks Stacks-Ebene, die eine Vorlage für Instanzen zur Bereitstellung statischer HTML-Seiten bereitstellt, zu denen auch clientseitiges Scripting gehören kann. Diese Ebene basiert auf [Nginx](http://nginx.org/en/).

**Installation**: Nginx wird installiert in `/usr/sbin/nginx`.

Auf der Seite **Add Layer (Ebene hinzufügen)** stehen folgende Konfigurationsoptionen zur Verfügung:

**Benutzerdefinierte Sicherheitsgruppen**  
Diese Einstellung wird angezeigt, wenn Sie Ihren Layern nicht automatisch eine integrierte OpsWorks Stacks-Sicherheitsgruppe zuordnen möchten. Sie müssen die mit der Ebene zu verknüpfende Sicherheitsgruppe angeben. Weitere Informationen finden Sie unter [Erstellen eines neuen Stacks](workingstacks-creating.md).

**Elastic Load Balancer**  
Sie können einen Elastic Load Balancing Load Balancer an die Instances des Layers anhängen.

Mit einer benutzerdefinierten JSON- oder Attributdatei können einige Nginx-Konfigurationseinstellungen geändert werden. Weitere Informationen finden Sie unter [Überschreiben der Attribute](workingcookbook-attributes.md). Eine Liste der überschreibbaren Apache-Attribute finden Sie unter [nginx-Attribute](attributes-recipes-nginx.md).

**Wichtig**  
Wenn Ihre Webanwendung SSL verwendet, empfehlen wir Ihnen, dies nach Möglichkeit zu deaktivieren SSLv3 , um die in [CVE-2014-3566](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566) beschriebenen Sicherheitslücken zu beheben.   
Zum Deaktivieren müssen Sie SSLv3 die Datei des Nginx-Servers ändern. `nginx.conf` Überschreiben Sie dazu die `nginx.conf.erb` Vorlagendatei des integrierten [Nginx-Kochbuchs](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/nginx), die die Setup-Rezepte der Rails App Server-Schicht zum Erstellen verwenden`nginx.conf`, und fügen Sie die folgende Direktive hinzu:  

```
ssl_protocols TLSv1.2;
```
Weitere Informationen zum Konfigurieren von `nginx.conf` finden Sie unter [Configuring HTTPS servers](http://nginx.org/en/docs/http/configuring_https_servers.html). Weitere Informationen zum Überschreiben einer integrierten Vorlage finden Sie unter [Verwenden von benutzerdefinierten Vorlagen](workingcookbook-template-override.md).

## Referenz zur ECS-Clusterschicht
<a name="w2ab1c14c71b9c21c23"></a>

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Eine ECS-Cluster-Schicht stellt einen [Amazon Elastic Container Service (Amazon ECS) -Cluster](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) dar und vereinfacht die Clusterverwaltung.

**Short name (Kurzname):** ecs-cluster

**Kompatibilität:** Eine [Amazon ECS-Serviceschicht](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) ist nur mit benutzerdefinierten Ebenen kompatibel

**Offene Ports:** Der ECS-Cluster ermöglicht den öffentlichen Zugriff auf Port 22 (SSH)

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS volume (Standard-EBS-Volume):** Nein

**Standard-Sicherheitsgruppe:** AWS-OpsWorks-ECS-Cluster

**Konfiguration:** Um eine ECS-Clusterschicht zu konfigurieren, müssen Sie Folgendes angeben:
+ Ob den Container-Instances öffentliche IP-Adressen oder Elastic IP-Adressen zugewiesen werden sollen
+ Das Instance-Profil für die Container-Instances 

**Setup recipes (Einrichtungsrezepte):**
+  opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ opsworks\$1ecs::setup

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ mysql::client
+ agent\$1version
+ opsworks\$1ecs::configure

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default
+ opsworks\$1ecs::deploy 

**Undeploy recipes (Bereitstellung von Rezepten aufheben):**
+ opsworks\$1ecs::undeploy 

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default
+ opsworks\$1ecs::shutdown

**Installation (Installation):**
+ OpsWorks Stacks verwendet das Paketinstallationsprogramm der Instanz, um Docker an seinen Standardspeicherorten zu installieren
+ Das Chef-Protokoll für das Setup-Ereignis vermerkt, ob der Amazon ECS-Agent erfolgreich installiert wurde. Andernfalls enthalten die von OpsWorks Stacks bereitgestellten Protokolle keine Amazon ECS-Fehlerprotokollinformationen. Weitere Informationen zur Behandlung von Amazon ECS-Fehlern finden Sie unter [Amazon ECS-Fehlerbehebung](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html).

# Referenz für benutzerdefinierte Layer
<a name="layers-other-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).

Wenn die Standard-Layer nicht Ihren Anforderungen entsprechen, können Sie einen benutzerdefinierten Layer erstellen. Ein Stack kann mehrere benutzerdefinierte Layer aufweisen. Standardmäßig führt der benutzerdefinierte Layer bestimmte standardmäßige Rezepte aus, die grundlegende Funktionen unterstützen. Sie implementieren dann die primäre Funktionalität des Layers durch Implementieren einer Reihe benutzerdefinierter Chef-Rezepte für jedes der entsprechenden Lebenszyklusereignisse, zum Einrichten und Konfigurieren der Software des Layers usw. Benutzerdefinierte Rezepte folgen den OpsWorks Standard-Stacks-Rezepten für jedes Event. 

**Short name (Kurzname):** Benutzerdefiniert. Jeder benutzerdefinierte Layer in einem Stack muss einen unterschiedlichen Kurznamen haben.

**Open ports (Offene Ports):** Standardmäßig öffnet ein benutzerdefinierter Server-Layer den öffentlichen Zugriff auf die Ports 22 (SSH), 80 (HTTP), 443 (HTTPS) und alle Ports der Rails- und PHP-Anwendungsserver-Layer des Stacks.

**Autoassign Elastic IP Addresses (Elastic IP-Adresse automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS volume (Standard-EBS-Volume):** Nein

**Standard-Sicherheitsgruppe:** AWS-OpsWorks-Custom-Server

**Compatibility (Kompatibilität):** Benutzerdefinierte Layer sind mit folgenden Layern kompatibel: benutzerdefiniert, DB-Master, LB, Memcached, Monitoring-Master, Nodejs-App, PHP-App, Rails-App und Web.

**Configuration (Konfiguration):** Um einen benutzerdefinierten Layer zu konfigurieren, müssen Sie Folgendes angeben:
+ Den Namen des Layers
+ Den Kurznamen des Layers, der den Layer in Chef-Rezepte angibt und nur Buchstaben von A bis Z und Zahlen aufweist.

Bei Linux-Stacks verwendet der benutzerdefinierte Layer die folgenden Rezepte.

**Setup recipes (Einrichtungsrezepte):**
+  opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version 

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default

# Referenz für andere Layer
<a name="layers-other"></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).

OpsWorks Stacks unterstützt auch die folgenden Ebenen.

**Topics**
+ [Referenz zur Ganglien-Ebene](layers-other-ganglia.md)
+ [Memcached-Layer-Referenz](layers-other-memcached.md)

# Referenz zur Ganglien-Ebene
<a name="layers-other-ganglia"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

Eine Ganglia-Ebene unterstützt [Ganglia](http://ganglia.sourceforge.net/), ein verteiltes Überwachungssystem, das die Speicherung und Visualisierung von Instanzmetriken verwaltet. Es wurde zur Zusammenarbeit mit hierarchischen Instance-Topologien entwickelt, was es besonders nützlich für Instance-Gruppen macht. Ganglia hat zwei grundlegende Komponenten:
+ Einen Client mit geringem Overhead, der auf jeder Instance im Stack installiert wird und Metriken an den Master sendet.
+ Ein Master, der Metriken von den Clients sammelt und sie auf einem Amazon EBS-Volume speichert. Außerdem werden die Metriken auf einer Webseite angezeigt.

OpsWorks Stacks verfügt auf jeder verwalteten Instance über einen Ganglia-Monitoring-Agenten. Wenn Sie Ihrem Stack eine Ganglia-Ebene hinzufügen und diese starten, melden die Ganglia-Agenten auf jeder Instanz Metriken an die Ganglia-Instanz. Um Ganglia zu verwenden, fügen Sie dem Stack eine Ganglia-Ebene mit einer Instanz hinzu. Sie haben Zugriff auf die Daten, indem Sie sich beim Ganglia-Backend unter der IP-Adresse des Masters anmelden. Sie können zusätzliche Metrikdefinitionen bereitstellen, indem Sie Chef-Rezepte schreiben. 

**Short name (Kurzname):** monitoring-master

**Kompatibilität:** Eine Ganglia-Schicht ist mit den folgenden Ebenen kompatibel: custom, db-master, memcached, php-app, rails-app.

**Open ports (Offene Ports):** Load-Balancer ermöglicht den öffentlichen Zugriff auf die Ports 22 (SSH), 80 (HTTP) und 443 (HTTPS).

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS volume (Standard-EBS-Volume):** Ja, bei `/vol/ganglia`

** AWS-OpsWorks-Monitoring-MasterStandard-Sicherheitsgruppe**: -Server

**Konfiguration:** Um eine Ganglia-Schicht zu konfigurieren, müssen Sie Folgendes angeben:
+ Die URI, die den Zugriff auf die Überwachungsdiagramme bereitstellt. Der Standardwert ist http://*DNSName*/ganglia, wobei es sich um den DNS-Namen der Ganglia-Instanz *DNSName* handelt.
+ Den Benutzernamen und das Passwort zur Steuerung des Zugriffs auf die Überwachungsstatistiken.

**Setup recipes (Einrichtungsrezepte):**
+ opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ opsworks\$1ganglia::server 

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version
+ opsworks\$1ganglia::configure-server 

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default
+ opsworks\$1ganglia::configure-server
+ opsworks\$1ganglia::deploy 

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default
+ apache2::stop 

**Installation (Installation):**
+ Der Ganglia-Client wird installiert unter: `/etc/ganglia`.
+ Der Ganglia-Web-Frontend wird installiert unter: `/usr/share/ganglia-webfrontend`.
+ Der Ganglia-Logtailer wird installiert unter: `/usr/share/ganglia-logtailer`.

# Memcached-Layer-Referenz
<a name="layers-other-memcached"></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).

**Anmerkung**  
Diese Ebene steht nur für Linux-basierte Stacks zur Verfügung.

[Memcached](http://memcached.org/) ist ein verteiltes Speicher-Caching-System für beliebige Daten. Es beschleunigt Websites, indem Zeichenfolgen und Objekte als Schlüssel und Werte im RAM gespeichert werden, um die Anzahl der Male, die eine externe Datenquelle gelesen werden muss, zu reduzieren. 

Um Memcached in einem Stack zu verwenden, erstellen Sie eine Memcached-Ebene und fügen Sie eine oder mehrere Instanzen hinzu, die als Memcached-Server fungieren. Die Instanzen installieren Memcached automatisch, und die anderen Instanzen des Stacks können auf die Memcached-Server zugreifen und diese verwenden. Wenn Sie einen Rails-App-Server-Layer verwenden, platziert OpsWorks Stacks automatisch eine `memcached.yml` Konfigurationsdatei im Konfigurationsverzeichnis jeder Instanz in der Ebene. Sie können den Memcached-Server und die Portnummer aus dieser Datei abrufen.

**Short name (Kurzname):** memcached

**Kompatibilität:** Eine Memcached-Schicht ist mit den folgenden Ebenen kompatibel: custom, db-Master, lb, Monitoring-Master, Nodejs-App, PHP-App, Rails-App und Web.

**Offene Ports:** Eine Memcached-Schicht ermöglicht den öffentlichen Zugriff auf Port 22 (SSH) und alle Ports von den Webservern, benutzerdefinierten Servern und den Anwendungsservern Rails, PHP und Node.js des Stacks.

**Autoassign Elastic IP addresses (Elastic IP-Adressen automatisch zuweisen):** Standardmäßig deaktiviert

**Default EBS volume (Standard-EBS-Volume):** Nein

**Standard-Sicherheitsgruppe:** AWS-OpsWorks-Memcached-Server 

Um einen Memcached-Layer zu konfigurieren, müssen Sie die Cachegröße in MB angeben.

**Setup recipes (Einrichtungsrezepte):**
+ opsworks\$1initial\$1setup
+ ssh\$1host\$1keys
+ ssh\$1users
+ mysql::client
+ vermeiden
+ ebs
+ opsworks\$1ganglia::client
+ memcached 

**Configure recipes (Konfigurationsrezepte):**
+ opsworks\$1ganglia::configure-client
+ ssh\$1users
+ agent\$1version 

**Deploy recipes (Bereitstellungsrezepte):**
+ deploy::default

**Shutdown recipes (Shutdown-Rezepte):**
+ opsworks\$1shutdown::default
+ memcached::stop

**Installation (Installation):**
+ OpsWorks Stacks verwendet das Paketinstallationsprogramm der Instanz, um Memcached und seine Protokolldateien an ihren Standardspeicherorten zu installieren.

# Andere Layer
<a name="workinglayers-other"></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).

**Anmerkung**  
Diese Ebenen sind nur für Chef 11 und frühere Linux-basierte Stacks verfügbar.

OpsWorks Stacks unterstützt auch die Ebenen Ganglia und Memcached.

**Topics**
+ [Ganglien-Schicht](workinglayers-ganglia.md)
+ [Memcached](workinglayers-mem.md)

# Ganglien-Schicht
<a name="workinglayers-ganglia"></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).

**Anmerkung**  
Dieser Layer steht nur für Chef 11 und niedrigere Linux-basierte Stacks zur Verfügung.

OpsWorks Stacks sendet all Ihre Instance- und Volume-Metriken an [Amazon CloudWatch](https://aws.amazon.com/documentation/cloudwatch/), sodass Sie auf einfache Weise Grafiken anzeigen und Alarme einrichten können, um Ihnen bei der Fehlerbehebung zu helfen und automatisierte Maßnahmen auf der Grundlage des Status Ihrer Ressourcen zu ergreifen. Sie können die Ganglia OpsWorks Stacks-Ebene auch für zusätzliche Optionen zur Anwendungsüberwachung verwenden, z. B. für das Speichern Ihrer ausgewählten Metriken.

[Die Ganglia-Schicht ist eine Blaupause für eine Instanz, die Ihren Stack mithilfe von Ganglia Distributed Monitoring überwacht.](http://ganglia.sourceforge.net/) Ein Stack hat normalerweise nur eine Ganglia-Instanz. Die Ganglia-Schicht umfasst die folgenden optionalen Konfigurationseinstellungen:

**Ganglia URL (URL für Ganglia)**  
Den URL-Pfad der Statistik. Die vollständige URL lautet http://*DNSName**URLPath*, wobei *DNSName* der DNS-Name der zugehörigen Instanz steht. Der *URLPath* Standardwert ist „/ganglia“, was etwa entspricht: http://ec2-54-245-151-7.us-west-2.compute.amazonaws.com/ganglia.

**Ganglia user name (Benutzername für Ganglia)**  
Ein Benutzername für die Statistik-Webseite. Sie müssen den Benutzernamen angeben, wenn Sie die Seite aufrufen. Der Standardwert ist „opsworks“. 

**Ganglia password (Passwort für Ganglia)**  
Ein Passwort, mit dem der Zugriff auf die Statistik-Webseite kontrolliert wird. Zum Anzeigen der Seite müssen Sie das Passwort eingeben. Der Standardwert ist eine zufällig erstellte Zeichenfolge.   
Notieren Sie sich das Passwort für die spätere Verwendung. In OpsWorks Stacks können Sie das Passwort nicht anzeigen, nachdem Sie die Ebene erstellt haben. Sie können jedoch das Passwort aktualisieren, indem Sie die Bearbeitungsseite des Layers aufrufen und auf **Update password (Passwort aktualisieren)** klicken.

**Benutzerdefinierte Sicherheitsgruppen**  
Diese Einstellung wird angezeigt, wenn Sie Ihren Layern nicht automatisch eine integrierte OpsWorks Stacks-Sicherheitsgruppe zuordnen möchten. Sie müssen die mit der Ebene zu verknüpfende Sicherheitsgruppe angeben. Weitere Informationen finden Sie unter [Erstellen eines neuen Stacks](workingstacks-creating.md).

**Elastic Load Balancer**  
Sie können einen Elastic Load Balancing Load Balancer an die Instances des Layers anhängen.

**Wichtig**  
[Wenn Ihr Stack eine Ganglia-Schicht enthält, empfehlen wir, diese Ebene nach Möglichkeit zu deaktivieren SSLv3 , um die in CVE-2014-3566 beschriebenen Sicherheitslücken zu beheben.](http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566) Dazu müssen Sie die Vorlage `ssl.conf.erb` des Apache-Servers überschreiben, um die `SSLProtocol`-Einstellung zu ändern. Details hierzu finden Sie unter [Deaktivierung für Apache Server SSLv3](layers-java.md#layers-java-sslv3).

## Sehen Sie sich die Ganglia-Statistik an
<a name="w2ab1c14c71b9c21c29c11c15"></a>

OpsWorks Stacks-Rezepte installieren auf jeder Instanz einen Ganglia-Client mit geringem Overhead. Wenn Ihr Stack eine Ganglia-Ebene enthält, beginnt der Ganglia-Client automatisch mit der Berichterstattung an die Ganglia, sobald die Instanz online ist. Ganglia verwendet die Kundendaten, um eine Vielzahl von Statistiken zu berechnen, und zeigt die Ergebnisse grafisch auf seiner Statistik-Webseite an.

**So zeigen Sie Ganglia-Statistiken an**

1. Klicken Sie auf der Seite „**Ebenen**“ auf Ganglia, um die Detailseite der Ebene zu öffnen.

1. Klicken Sie im Navigationsbereich auf **Instances**. Klicken Sie unter **Ganglia** auf den Instanznamen.

1.  Kopieren Sie den **Public DNS**-Namen der Instance.

1. Verwenden Sie den DNS-Namen, um die Statistik-URL zu erstellen, die etwa wie folgt aussieht: http://ec2-54-245-151-7.us-west-2.compute.amazonaws.com/ganglia.

1. Kopieren Sie die vollständige URL in Ihren Browser, navigieren Sie zur Seite und geben Sie den Benutzernamen und das Passwort für Ganglia ein, um die Seite anzuzeigen. Ein Beispiel folgt.   
![\[ShortStack Cluster Report dashboard showing system metrics and load graph for the past hour.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/ganglia_stats.png)

# Memcached
<a name="workinglayers-mem"></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).

**Anmerkung**  
Dieser Layer ist nur für Chef 11 und frühere Linux-basierte Stacks verfügbar.

Ein Memcached-Layer ist ein OpsWorks Stacks-Layer, der eine Blaupause für Instances bereitstellt, die als [Memcached-Server fungieren — ein verteiltes Speicher-Caching-System](http://memcached.org/) für beliebige Daten. Die Memcached-Schicht umfasst die folgenden Konfigurationseinstellungen.

**Allocated memory (MB) (Zugewiesener Speicher (MB))**  
(Optional) Den Cache-Speicher (in MB) für jede Layer-Instance. Der Standardwert ist 512 MB.

**Benutzerdefinierte Sicherheitsgruppen**  
Diese Einstellung wird angezeigt, wenn Sie Ihren Layern nicht automatisch eine integrierte OpsWorks Stacks-Sicherheitsgruppe zuordnen möchten. Sie müssen die mit der Ebene zu verknüpfende Sicherheitsgruppe angeben. Weitere Informationen finden Sie unter [Erstellen eines neuen Stacks](workingstacks-creating.md).