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.
# Layer
**Wichtig**
Der AWS OpsWorks Stacks Service hat am 26. Mai 2024 das Ende seiner Nutzungsdauer erreicht und wurde sowohl für neue als auch für bestehende Kunden deaktiviert. Wir empfehlen Kunden dringend, ihre Workloads so bald wie möglich auf andere Lösungen zu migrieren. Wenn Sie Fragen zur Migration haben, wenden Sie sich an das AWS Support Team auf [AWS re:POST](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
Jeder Stack umfasst einen oder mehrere Layer, die jeweils eine Stack-Komponente repräsentieren, z. B. einen Load Balancer oder eine Gruppe von Anwendungsservern.
Beachten Sie bei der Arbeit mit OpsWorks Stacks-Ebenen Folgendes:
+ Jeder Layer in einem Stack muss mindestens eine Instance haben und kann optional jedoch auch mehrere Instances aufweisen.
+ Jede Instance in einem Stack muss ein Element von mindestens einem Layer sein, mit Ausnahme von [registrierten Instances](registered-instances.md).
Sie können eine Instance nicht direkt konfigurieren, mit Ausnahme von einigen grundlegenden Einstellungen wie dem SSH-Schlüssel und dem Hostnamen. Sie müssen einen geeigneten Layer erstellen und konfigurieren und die Instance dem Layer hinzufügen.
EC2 Amazon-Instances können optional Mitglied mehrerer Ebenen sein. In diesem Fall führt OpsWorks Stacks die Rezepte zur Installation und Konfiguration von Paketen, zur Bereitstellung von Anwendungen usw. für jede Ebene der Instance aus.
Wenn Sie eine Instance mehreren Layern zuweisen, können Sie folgende Schritte durchführen:
+ Senken Sie Kosten, indem Sie den Datenbankserver und den Load Balancer auf einer einzelnen Instance hosten.
+ Verwenden Sie einen Ihrer Anwendungsserver für die Verwaltung.
Erstellen Sie einen benutzerdefinierten Verwaltungs-Layer und fügen Sie eine der Anwendungsserver-Instances hinzu. Die Rezepte des Verwaltungs-Layers konfigurieren die Anwendungsserver-Instance, um Verwaltungsaufgaben durchzuführen und jede zusätzlich erforderliche Software zu installieren. Die anderen Anwendungsserver-Instances sind nur Anwendungsserver.
In diesem Abschnitt wird beschrieben, wie Sie mit Layern arbeiten.
**Topics**
+ [OpsWorks Grundlagen von Layern](workinglayers-basics.md)
+ [Elastic Load Balancing Lastenausgleichsebene](layers-elb.md)
+ [Amazon RDS-Serviceschicht](workinglayers-db-rds.md)
+ [ECS-Cluster-Ebenen](workinglayers-ecscluster.md)
+ [Benutzerdefinierte OpsWorks Stapel (Ebenen)](workinglayers-custom.md)
+ [Paketinstallationen für Ihr Betriebssystem pro Layer](per-layer-os-package-install.md)
# OpsWorks Grundlagen von Layern
**Wichtig**
Der AWS OpsWorks Stacks Dienst hat am 26. Mai 2024 das Ende seiner Lebensdauer erreicht und wurde sowohl für neue als auch für bestehende Kunden deaktiviert. Wir empfehlen Kunden dringend, ihre Workloads so bald wie möglich auf andere Lösungen zu migrieren. Wenn Sie Fragen zur Migration haben, wenden Sie sich an das AWS Support Team auf [AWS re:POST](https://repost.aws/) oder über den [AWS Premium-Support](https://aws.amazon.com/support).
In diesem Abschnitt wird beschrieben, wie Operationen ausgeführt werden, die allen OpsWorks Stacks-Ebenen gemeinsam sind.
**Topics**
+ [Eine OpsWorks Ebene erstellen](workinglayers-basics-create.md)
+ [Bearbeiten der Konfiguration einer Ebene OpsWorks](workinglayers-basics-edit.md)
+ [Verwenden von Auto Healing zum Austausch fehlgeschlagener Instances](workinginstances-autohealing.md)
+ [Löschen einer Ebene OpsWorks](workinglayers-basics-delete.md)
# Eine OpsWorks Ebene erstellen
**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).
Wenn Sie einen neuen Stack erstellen, wird folgende Seite angezeigt:
![\[AnotherStack interface showing an empty stack with a prompt to add the first layer.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/new_stack_page_layers.png)
**Um die erste Ebene hinzuzufügen OpsWorks**
1. Klicken Sie auf **Add a layer (Einen Layer hinzufügen)**.
1. Wählen Sie auf der Seite **Add Layer (Einen Layer hinzufügen)** den entsprechenden Layer aus, auf dem die Konfigurationsoptionen des Layers angezeigt werden.
1. Konfigurieren Sie den Layer entsprechend und klicken Sie auf **Add Layer (Einen Layer hinzufügen)**, um ihn zum Stack hinzuzufügen. In den folgenden Abschnitten wird die Konfiguration der verschiedenen Layer beschrieben.
**Anmerkung**
Die Seite **Add Layer (Einen Layer hinzufügen)** zeigt nur die am häufigsten verwendeten Konfigurationseinstellungen für jeden Layer an. Sie können zusätzliche Einstellungen durch [Bearbeiten des Layers](workinglayers-basics-edit.md) festlegen.
1. Fügen Sie Instances zum Layer hinzu und starten Sie sie.
**Anmerkung**
Wenn eine Instance zu mehreren Layern gehört, müssen Sie sie zu allen Layern hinzufügen, bevor Sie die Instance starten. Sie können eine Online-Instance nicht zu einem Layer hinzufügen.
Um weitere Layer hinzuzufügen, öffnen Sie die Seite **Layers (Layers)** und klicken Sie auf **\$1 Layer (\$1 Layer)**, um die Seite **Add Layer (Layer hinzufügen)** zu öffnen.
Wenn Sie eine Instanz starten, führt OpsWorks Stacks automatisch die Setup- und Deploy-Rezepte für jede Ebene der Instanz aus, um die entsprechenden Pakete zu installieren und zu konfigurieren und die entsprechenden Anwendungen bereitzustellen. Sie können den [Einrichtungs- und Konfigurationsprozess einer Ebene auf verschiedene Weise anpassen](customizing.md), z. B. indem Sie den entsprechenden Lebenszyklusereignissen benutzerdefinierte Rezepte zuweisen. OpsWorks Stacks führt benutzerdefinierte Rezepte nach den Standardrezepten für jedes Ereignis aus. Weitere Informationen finden Sie unter [Cookbooks und Rezepte](workingcookbook.md).
In den folgenden layerspezifischen Abschnitten wird beschrieben, wie die Schritte 2 und 3 für die verschiedenen OpsWorks Stacks-Ebenen gehandhabt werden. Weitere Informationen zum Hinzufügen von Instances finden Sie unter [Hinzufügen einer Instance zu einem Layer](workinginstances-add.md).
# Bearbeiten der Konfiguration einer Ebene OpsWorks
**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).
Nach dem Erstellen eines Layers sind einige Eigenschaften (z. B. AWS-Region) unveränderbar, aber Sie können die meisten Parameter der Layer-Konfiguration jederzeit ändern. Beim Bearbeiten des Layers besteht auch Zugriff auf Konfigurationseinstellungen, die nicht auf der Seite **Add Layer (Layer hinzufügen)** verfügbar sind. Die Einstellungen werden wirksam, sobald Sie die neue Konfiguration speichern.
**Um eine Ebene zu bearbeiten OpsWorks**
1. Klicken Sie im Navigationsbereich auf **Layers (Layers)**.
1. Wählen Sie auf der Seite **Layers (Layers)** den Namen eines Layers aus, um die Detailseite mit der aktuellen Konfiguration zu öffnen.
**Anmerkung**
Durch Auswahl eines Namens unterhalb des Layer-Namens werden Sie direkt zur entsprechenden Registerkarte auf der Detailseite geleitet.
1. Klicken Sie auf **Edit (Bearbeiten)** und wählen Sie dann die entsprechende Registerkarte aus: **General Settings (Allgemeine Einstellungen)**, **Recipes (Rezepte)**, **Network (Netzwerk)**, **EBS Volumes (EBS-Volumes)** oder **Security (Sicherheit)**.
In den folgenden Abschnitten werden die Einstellungen für verschiedene, in allen Layern verfügbare Registerkarten beschrieben. Einige Layer haben zusätzliche, Layer-spezifische Einstellungen, die oben auf der Seite angezeigt werden. Darüber hinaus sind einige Einstellungen nur für Linux-basierte Stacks verfügbar, wie angegeben.
**Topics**
+ [Allgemeine Einstellungen](#workinglayers-basics-edit-general)
+ [Rezepte](#workinglayers-basics-edit-recipes)
+ [Netzwerk](#workinglayers-basics-edit-network)
+ [EBS-Volumes](#workinglayers-basics-edit-ebs)
+ [Sicherheit](#workinglayers-basics-edit-security)
+ [CloudWatch Logs](#w2ab1c14c53c21c11c23)
+ [Tags (Markierungen)](#w2ab1c14c53c21c11c25)
## Allgemeine Einstellungen
Alle Layer haben die folgenden Einstellungen:
**Auto Healing aktiviert**
Bestimmt, ob [Auto Healing (Auto Healing)](workinginstances-autohealing.md) für die Instances des Layers aktiviert ist. Die Standardeinstellung ist **Yes (Ja)**.
**Custom JSON**
Daten im JSON-Format, die an die Chef-Rezepte für alle Instances in diesem Layer übergeben werden. Auf diese Weise können Sie beispielsweise Daten an Ihre eigenen Rezepte übergeben. Weitere Informationen finden Sie unter [Nutzen eines benutzerdefinierten JSON-Objekts](workingstacks-json.md).
Sie können benutzerdefinierte JSON-Objekte auf Bereitstellungs-, Layer- und Stacks-Ebene deklarieren. Diese Lösung bietet sich an, wenn Sie möchten, dass einige benutzerdefinierte JSON-Objekte im gesamten Stack oder nur für eine einzelne Bereitstellung sichtbar sind. Oder Sie möchten die auf Layer-Ebene deklarierte benutzerdefinierte JSON-Objekte mit einem benutzerdefinierten JSON-Objekt auf Bereitstelĺungsebene überschreiben. Wenn Sie benutzerdefinierte JSON-Objekte auf mehreren Ebenen deklarieren, werden die auf Layer- und Stack-Ebene deklarierten benutzerdefinierten JSON-Objekte von dem auf der Bereitstellungsebene deklarierten benutzerdefinierten JSON-Objekt überschrieben. Benutzerdefiniertes JSON-Objekt, das nur auf Stack-Ebene deklariert ist, wird von jeglichen, nur auf Layer-Ebene deklarierten benutzerdefinierten JSON-Objekten überschrieben.
Um mit der OpsWorks Stacks-Konsole benutzerdefiniertes JSON für eine Bereitstellung anzugeben, wählen Sie auf der Seite **App bereitstellen** die Option **Erweitert** aus. Geben Sie das benutzerdefinierte JSON-Objekt in das Feld **Custom Chef JSON (Benutzerdefiniertes Chef JSON)** ein und wählen Sie dann **Save (Speichern)** aus.
**Um mit der OpsWorks Stacks-Konsole benutzerdefiniertes JSON für einen Stack anzugeben, geben Sie auf der Seite mit den Stack-Einstellungen das benutzerdefinierte JSON in das Feld **Benutzerdefiniertes JSON** ein und wählen Sie dann Speichern aus.**
Weitere Informationen erhalten Sie unter [Nutzen eines benutzerdefinierten JSON-Objekts](workingstacks-json.md) und [Bereitstellen von Anwendungen](workingapps-deploying.md).
**Zeitbeschränkung beim Instance-Shutdown**
Gibt an, wie lange (in Sekunden) OpsWorks Stacks wartet, nachdem es ein [Shutdown-Lifecycle-Ereignis](workingcookbook-events.md) ausgelöst hat, bevor es die Amazon-Instance stoppt oder beendet. EC2 Der Standardwert beträgt 120 Sekunden. Mit dieser Einstellung erhalten die Shutdown-Rezepte der Instance ausreichend Zeit, ihre Aufgaben abzuschließen, bevor die Instance beendet wird. Wenn Ihre benutzerdefinierten Shutdown-Rezepte mehr Zeit benötigen, ändern Sie die Einstellung entsprechend. Weitere Informationen zum Instance-Shutdown finden Sie unter [Anhalten einer Instance](workinginstances-starting.md#workinginstances-starting-stop).
Die restlichen Einstellungen auf dieser Registerkarte variieren je nach Layer-Typ und sind mit den Einstellungen auf der Seite **Add Layer (Layer hinzufügen)** des Layers identisch.
## Rezepte
Die Registerkarte **Recipes (Rezepte)** enthält folgende Einstellungen.
**Custom Chef recipes (Benutzerdefinierte Chef-Rezepte)**
Sie können den Lebenszyklusereignissen eines Layers benutzerdefinierte Chef-Rezepte zuweisen. Weitere Informationen finden Sie unter [Ausführen von Rezepten](workingcookbook-executing.md).
## Netzwerk
Die Registerkarte **Network (Netzwerk)** enthält folgende Einstellungen.
**Elastic Load Balancing**
Sie können einen Elastic Load Balancing Load Balancer einem beliebigen Layer anfügen. OpsWorks Stacks registriert dann automatisch die Online-Instances des Layers beim Load Balancer und meldet sie ab, wenn sie offline gehen. Wenn Sie die Funktion zum Entleeren von Verbindungen des Load Balancers aktiviert haben, können Sie angeben, ob Stacks sie unterstützt. OpsWorks Weitere Informationen finden Sie unter [Elastic Load Balancing Lastenausgleichsebene](layers-elb.md).
**Automatically Assign IP Addresses (IP-Adressen automatisch zuweisen)**
Sie können steuern, ob OpsWorks Stacks den Instances des Layers automatisch öffentliche oder elastische IP-Adressen zuweist. Folgendes geschieht, wenn Sie diese Option aktivieren:
+ OpsWorks Stacks weist zum Beispiel bei Instances mit Store-Backed bei jedem Start der Instance automatisch eine Adresse zu.
+ Für Amazon EBS-gestützte Instances weist OpsWorks Stacks automatisch eine Adresse zu, wenn die Instance zum ersten Mal gestartet wird.
+ Wenn eine Instance zu mehr als einer Ebene gehört, weist OpsWorks Stacks automatisch eine Adresse zu, wenn Sie die automatische Zuweisung für mindestens eine der Ebenen aktiviert haben.
Wenn Sie die automatische Zuweisung von öffentlichen IP-Adressen aktivieren, gilt dies nur für neue Instanzen. OpsWorks Stacks können die öffentliche IP-Adresse für bestehende Instanzen nicht aktualisieren.
Wenn Ihr Stack in einer VPC ausgeführt wird, verfügen Sie über separate Einstellungen für öffentliche und Elastic IP-Adressen. In der folgenden Tabelle wird beschrieben, wie diese interagieren:
![\[Table showing interactions between public IP addresses, Elastic IP addresses, and instance network configurations.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/ip-address.png)
Instanzen müssen über eine Möglichkeit verfügen, mit dem OpsWorks Stacks-Dienst, den Linux-Paket-Repositorys und den Cookbook-Repositorys zu kommunizieren. Wenn Sie keine öffentlichen IP-Adressen oder Elastic IP-Adresse angeben, muss VPC ein Element wie z. B. NAT enthalten, damit die Instance des Layers mit externen Stellen kommunizieren kann. Weitere Informationen finden Sie unter [Ausführen eines Stacks in einer VPC](workingstacks-vpc.md).
Wenn der Stack nicht in einem VPC ausgeführt wird, ist **Elastic IP addresses (Elastic IP-Adressen)** die einzige verfügbare Einstellungsoption:
+ **Yes (Ja)**: Instances erhalten eine Elastic IP-Adresse, wenn sie zum ersten Mal gestartet werden, oder eine öffentliche IP-Adresse, wenn die Zuweisung einer Elastic IP-Adresse nicht möglich ist.
+ **No (Nein)**: Instances erhalten bei jedem Start eine öffentliche IP-Adresse.
## EBS-Volumes
Die Registerkarte **EBS Volumes (EBS-Volumes)** enthält folgende Einstellungen.
EBS-optimierte Instances
Ob die Instances des Layers für Amazon Elastic Block Store (Amazon EBS) optimiert werden sollen. Weitere Informationen finden Sie unter [Amazon EBS-Optimierte Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html).
**Additional EBS Volumes (Zusätzliche EBS-Volumes)**
(Nur Linux) Sie können [Amazon EBS-Volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) zu den Instances des Layers hinzufügen oder aus ihnen entfernen. Wenn Sie eine Instance starten, erstellt OpsWorks Stacks automatisch die Volumes und hängt sie den Instances an. Sie können auf der Seite **Resources (Ressourcen)** die EBS-Volumes eines Stacks verwalten. Weitere Informationen finden Sie unter [Ressourcenmanagement](resources.md).
+ **Bereitstellungspunkt** — (Erforderlich) Geben Sie den Bereitstellungspunkt oder das Verzeichnis an, in dem das EBS-Volume bereitgestellt werden soll.
+ **\$1 Festplatten** — (Optional) Wenn Sie ein RAID-Array angegeben haben, die Anzahl der Festplatten im Array.
Jeder RAID-Layer verfügt über eine standardmäßige Anzahl von Festplatten. Sie können jedoch eine größere Anzahl aus der Liste auswählen.
+ **Gesamtgröße (GiB)** — (Erforderlich) Die Größe des Volumes in GiB.
Für ein RAID-Array gibt diese Einstellung die gesamte Array-Größe und nicht die Größe der einzelnen Festplatten an.
Die folgende Tabelle zeigt die Mindest- und die maximale Volume-Größe, die für die einzelnen Volume-Typen zulässig sind.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/workinglayers-basics-edit.html)
+ **Datenträgertyp** — (Optional) Geben Sie an, ob ein magnetisches Allzweck-SSD-Volume, ein durchsatzoptimiertes HDD-, Cold HDD- oder PIOPS-Volume erstellt werden soll.
Der Standardwert ist **Magnetic (Magnetisch)**.
+ **Verschlüsselt** — (Optional) Geben Sie an, ob der Inhalt des EBS-Volumes verschlüsselt werden soll.
+ **IOPS pro Festplatte** **— (Erforderlich für bereitgestellte IOPS-SSD- und Allzweck-SSD-Volumes) Wenn Sie ein bereitgestelltes IOPS-SSD- oder Allzweck-SSD-Volume angeben, müssen Sie auch die IOPS pro Festplatte angeben.**
Bei bereitgestellten IOPS-Volumes können Sie beim Erstellen des Volumes die IOPS-Rate angeben. Das Verhältnis zwischen der bereitgestellten IOPS und der Volume-Größe darf maximal 30 betragen (d. h., ein Volume mit 3 000 IOPS muss mindestens 100 GB groß sein). Für Allzweck-Volumes-Typen (SSD) beträgt die IOPS-Basisleistung die dreifache Volume-Größe mit maximal 10 000 IOPS, die über einen Zeitraum von 30 Minuten um 3 000 IOPS erweitert werden kann.
Wenn Sie Volumes aus einem Layer hinzufügen oder entfernen möchten, beachten Sie Folgendes:
+ Wenn Sie ein Volume hinzufügen, erhält jede neue Instance Zugriff auf das neue Volume, allerdings aktualisiert OpsWorks Stacks nicht die vorhandenen Instances.
+ Wenn Sie ein Volume entfernen, gilt dies nur für neue Instances. Die vorhandenen Instances behalten ihre Volumes.
### Angabe eines Mounting-Punkts
Sie können einen beliebigen Mounting-Punkt angeben. Beachten Sie jedoch, dass einige Bereitstellungspunkte für die Verwendung durch OpsWorks Stacks oder Amazon reserviert sind EC2 und nicht für Amazon EBS-Volumes verwendet werden sollten. Verwenden Sie keine typischen Linux-Systemordner wie `/home` oder `/etc`.
Die folgenden Bereitstellungspunkte sind für die Verwendung durch OpsWorks Stacks reserviert.
+ `/srv/www`
+ `/var/log/apache2` (Ubuntu)
+ `/var/log/httpd` (Amazon Linux)
+ `/var/log/mysql`
+ `/var/www`
Beim Start oder Neustart einer Instance verwendet autofs (Daemon für automatisches Mounting) flüchtige Geräte-Mounting-Punkte wie z. B. `/media/ephemeral0` zum Erstellen von Verzeichnissen (bind mounts). Dieser Vorgang findet statt, bevor Amazon EBS-Volumes bereitgestellt werden. Um sicherzustellen, dass der Bereitstellungspunkt Ihres Amazon EBS-Volumes nicht mit autofs kollidiert, geben Sie keinen temporären Geräte-Einhängepunkt an. Die möglichen Einhängepunkte für kurzlebige Geräte hängen vom jeweiligen Instance-Typ ab und davon, ob es sich um einen Instance-Store oder einen Amazon EBS-gestützten Instance-Speicher handelt. Um Konflikte mit autofs zu vermeiden, gehen Sie folgendermaßen vor:
+ Überprüfen Sie die flüchtigen Geräte-Mounting-Punkte für den bestimmten Instance-Typ und den zu verwendenden Sicherungsspeicher.
+ Beachten Sie, dass ein Bereitstellungspunkt, der für eine vom Instance-Speicher unterstützte Instance funktioniert, zu Konflikten mit autofs führen kann, wenn Sie zu einer Amazon EBS-gestützten Instance wechseln oder umgekehrt.
**Anmerkung**
Wenn Sie die Instance-Speicher-Blockgerät-Zuweisung ändern möchten, können Sie ein benutzerdefiniertes AMI erstellen. Weitere Informationen finden Sie im [Amazon EC2 Instance Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html). Weitere Informationen zum Erstellen eines benutzerdefinierten AMI für OpsWorks Stacks finden Sie unter[Benutzerdefiniert verwenden AMIs](workinginstances-custom-ami.md).
Das folgende Beispiel zeigt, wie Sie mit einem benutzerdefinierten Rezept sicherstellen, dass ein Volume-Mounting-Punkt nicht mit autofs in Konflikt gerät. Sie können es für Ihren speziellen Anwendungsfall anpassen.
**So vermeiden Sie einen konfliktiven Mounting-Punkt**
1. Weisen Sie der gewünschten Ebene ein Amazon EBS-Volume zu, verwenden Sie jedoch einen Bereitstellungspunkt`/mnt/workspace`, der niemals zu Konflikten mit autofs führt.
1. Implementieren Sie das folgende benutzerdefinierte Rezept, das ein Anwendungsverzeichnis auf dem Amazon EBS-Volume erstellt und von dort aus `/srv/www/` Links zu diesem enthält. Weitere Informationen zur Implementierung von benutzerdefinierten Rezepten finden Sie unter [Cookbooks und Rezepte](workingcookbook.md) und [Stacks anpassen OpsWorks](customizing.md).
```
mount_point = node['ebs']['raids']['/dev/md0']['mount_point'] rescue nil
if mount_point
node[:deploy].each do |application, deploy|
directory "#{mount_point}/#{application}" do
owner deploy[:user]
group deploy[:group]
mode 0770
recursive true
end
link "/srv/www/#{application}" do
to "#{mount_point}/#{application}"
end
end
end
```
1. Fügen Sie eine `depends 'deploy'`-Zeile in die Datei des benutzerdefinierten Rezeptbuchs `metadata.rb` hinzu.
1. [Weisen Sie dieses Rezept dem Einrichtungsereignis des Layers zu.](workingcookbook-executing.md)
## Sicherheit
Die Registerkarte **Security (Sicherheit)** enthält folgende Einstellungen.
**Sicherheitsgruppen**
Einem Layer muss mindestens eine Sicherheitsgruppe zugewiesen sein. Sie geben an, wie Sicherheitsgruppen verknüpft werden sollen, wenn Sie einen Stack [erstellen](workingstacks-creating.md) oder [aktualisieren](workingstacks-edit.md). OpsWorks Stacks bietet einen Standardsatz integrierter Sicherheitsgruppen.
+ Die Standardoption besteht darin, dass OpsWorks Stacks jeder Ebene automatisch die entsprechende integrierte Sicherheitsgruppe zuordnet.
+ Sie können auch die nicht automatische Zuweisung von Sicherheitsgruppen auswählen und stattdessen jedem Layer bei dessen Erstellung eine benutzerdefinierte Sicherheitsgruppe zuweisen.
Weitere Informationen zu Sicherheitsgruppen finden Sie unter [Verwenden von Sicherheitsgruppen](workingsecurity-groups.md).
Nachdem der Layer erstellt wurde, können Sie mit **Security Groups (Sicherheitsgruppen)** mehrere Sicherheitsgruppen zum Layer hinzufügen, indem Sie sie aus der Liste **Custom security groups (Benutzerdefinierte Sicherheitsgruppen)** auswählen. Nachdem Sie einer Ebene eine Sicherheitsgruppe hinzugefügt haben, fügt OpsWorks Stacks sie allen neuen Instanzen hinzu. (Beachten Sie, dass Instance-Store-Instances, die neu gestartet werden, als neue Instanzen angezeigt werden, sodass sie auch über die neuen Sicherheitsgruppen verfügen.) OpsWorks Stacks fügt Online-Instances keine Sicherheitsgruppen hinzu.
Sie können vorhandene Sicherheitsgruppen löschen, indem Sie auf **x** klicken. Gehen Sie dazu folgendermaßen vor:
+ Wenn Sie festlegen, dass OpsWorks Stacks integrierte Sicherheitsgruppen automatisch zuordnen soll, können Sie benutzerdefinierte Sicherheitsgruppen, die Sie zuvor hinzugefügt haben, löschen, indem Sie auf das **X** klicken, aber Sie können die integrierte Gruppe nicht löschen.
+ Wenn Sie sich dazu entscheiden, die integrierten Sicherheitsgruppen nicht automatisch zuzuweisen, können Sie alle existierenden Sicherheitsgruppen, auch die ursprünglichen, löschen, solange dem Layer mindesten eine Gruppe zugeordnet ist.
Nachdem Sie eine Sicherheitsgruppe aus einer Ebene entfernt haben, fügt OpsWorks Stacks sie keinen neuen oder neu gestarteten Instanzen hinzu. OpsWorks Stacks entfernt keine Sicherheitsgruppen aus Online-Instanzen.
Wenn Ihr Stack in einer VPC läuft, können Sie mithilfe der EC2 Amazon-Konsole, API oder CLI eine Sicherheitsgruppe für eine Online-Instance hinzufügen oder entfernen. Diese Sicherheitsgruppe wird jedoch in der OpsWorks Stacks-Konsole nicht sichtbar sein. Wenn Sie die Sicherheitsgruppe entfernen möchten, müssen Sie auch Amazon verwenden EC2. Weitere Informationen finden Sie unter [Sicherheitsgruppen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html).
Beachten Sie Folgendes:
+ Sie können die Zugriffseinstellungen des Ports der integrierten Sicherheitsgruppe durch Hinzufügen einer restriktiveren Sicherheitsgruppe nicht einschränken. Wenn es mehrere Sicherheitsgruppen gibt, EC2 verwendet Amazon die tolerantesten Einstellungen.
+ Ändern Sie nicht die Konfiguration einer integrierten Sicherheitsgruppe. Wenn Sie einen Stack erstellen, überschreibt OpsWorks Stacks die Konfigurationen der integrierten Sicherheitsgruppen, sodass alle Änderungen, die Sie vornehmen, verloren gehen, wenn Sie das nächste Mal einen Stack erstellen.
Wenn Sie feststellen, dass Sie restriktivere Sicherheitsgruppen-Einstellungen für einen oder mehrere Layer benötigen, führen Sie die folgenden Schritte aus:
1. Erstellen Sie benutzerdefinierte Sicherheitsgruppen mit den entsprechenden Einstellungen und fügen Sie sie zu den entsprechenden Layern hinzu.
Jeder Layer in Ihrem Stack muss mindestens über eine Sicherheitsgruppe zusätzlich zu der integrierten Gruppe verfügen, auch wenn nur für einen Layer benutzerdefinierte Einstellungen erforderlich sind.
1. [Bearbeiten Sie die Stack-Konfiguration](workingstacks-edit.md) **und setzen Sie die Einstellung ** OpsWorksSicherheitsgruppen verwenden** auf Nein.**
OpsWorks Stacks entfernt automatisch die integrierte Sicherheitsgruppe aus jeder Ebene.
Weitere Informationen zu Sicherheitsgruppen finden Sie unter [Amazon EC2 Security Groups](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html).
**EC2 Instance-Profil**
Sie können das EC2 Profil für die Instances des Layers ändern. Weitere Informationen finden Sie unter [Angeben von Berechtigungen für Apps, die auf Instanzen ausgeführt werden EC2](opsworks-security-appsrole.md).
## CloudWatch Logs
Auf der Registerkarte **CloudWatch Logs** können Sie Amazon CloudWatch Logs aktivieren oder deaktivieren. CloudWatch Die Logs-Integration funktioniert mit den Linux-basierten Stacks Chef 11.10 und Chef 12. Weitere Informationen zur Aktivierung der CloudWatch Log-Integration und zur Angabe der Logs, die Sie in der CloudWatch Logs-Konsole verwalten möchten, finden Sie unter. [Amazon CloudWatch Logs mit OpsWorks Stacks verwenden](monitoring-cloudwatch-logs.md)
## Tags (Markierungen)
Mit der Registerkarte **Tags** können Sie Kostenzuordnungs-Tags für Ihren Layer anwenden. Nachdem Sie Tags hinzugefügt haben, können Sie sie in der AWS Fakturierung und Kostenmanagement Konsole aktivieren. Wenn Sie ein Tag erstellen, wenden Sie das Tag auf alle Ressourcen innerhalb der gekennzeichneten Struktur an. Wenn Sie beispielsweise ein Tag auf eine Ebene anwenden, wenden Sie das Tag auf jede Instance, jedes Amazon EBS-Volume oder jeden Elastic Load Balancing Load Balancer in der Ebene an. Weitere Informationen dazu, wie Sie Ihre Tags aktivieren und damit die Kosten Ihrer OpsWorks Stacks-Ressourcen verfolgen und verwalten können, finden Sie unter Verwenden von [Kostenzuordnungs-Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) und [Aktivieren von benutzerdefinierten Kostenzuordnungs-Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html) im *Billing and Cost Management-Benutzerhandbuch*. Weitere Informationen zum Erstellen von Tags in OpsWorks Stacks finden Sie unter [Tags (Markierungen)](tagging.md).
# Verwenden von Auto Healing zum Austausch fehlgeschlagener Instances
**Wichtig**
Der AWS OpsWorks Stacks Dienst hat am 26. Mai 2024 das Ende seiner Lebensdauer erreicht und wurde sowohl für Neu- als auch für Bestandskunden 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 hat einen OpsWorks Stacks-Agenten, der regelmäßig mit dem Service kommuniziert. OpsWorks Stacks verwendet diese Kommunikation, um den Zustand der Instance zu überwachen. Wenn ein Agent länger als etwa fünf Minuten nicht mit dem Service kommuniziert, geht OpsWorks Stacks davon aus, dass die Instanz ausgefallen ist.
Auto Healing wird auf Layer-Ebene festgelegt. Sie können Auto Healing auch festlegen, indem Sie die Einstellungen des Layers bearbeiten, wie in der nachstehenden Abbildung dargestellt.
![\[Layer settings interface showing Auto healing enabled option set to Yes.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/layer_auto_healing.png)
**Anmerkung**
Eine Instance kann zu mehreren Layern gehören. Wenn bei einer dieser Ebenen die auto Heilung deaktiviert ist, repariert OpsWorks Stacks die Instanz nicht, wenn sie fehlschlägt.
Wenn für eine Ebene die auto Heilung aktiviert ist (Standardeinstellung), ersetzt OpsWorks Stacks die ausgefallenen Instanzen der Ebene automatisch wie folgt:
**Instance-Speicher-gestützte Instance**
1. Stoppt die EC2 Amazon-Instance und überprüft, ob sie heruntergefahren wurde.
1. Löscht die Daten auf dem Stamm-Volume.
1. Erstellt eine neue EC2 Amazon-Instance mit demselben Hostnamen, derselben Konfiguration und derselben Layer-Mitgliedschaft.
1. Fügt alle Amazon EBS-Volumes erneut an, einschließlich Volumes, die nach dem ursprünglichen Start der alten Instance angehängt wurden.
1. Weist eine neue öffentliche und private IP-Adresse zu.
1. Wenn die alte Instance mit einer Elastic IP-Adresse verknüpft war, wird die neue Instance mit derselben IP-Adresse verknüpft.
**Amazon EBS-gestützte Instance**
1. Stoppt die EC2 Amazon-Instance und überprüft, ob sie gestoppt wurde.
1. Startet die EC2 Instance.
Nachdem die automatisch reparierte Instanz wieder online ist, löst OpsWorks Stacks ein Configure [Lifecycle-Ereignis](workingcookbook-events.md) für alle Instanzen des Stacks aus. Die zugeordneten [Stack-Konfigurations- und Bereitstellungsattribute](workingcookbook-json.md) enthalten die öffentlichen und privaten IP-Adressen der Instance. Mit benutzerdefinierten Konfigurationsrezepten können neue IP-Adressen vom Knotenobjekt bezogen werden.
Wenn Sie [ein Amazon EBS-Volume für die Instances einer Ebene angeben](workinglayers-basics-edit.md#workinglayers-basics-edit-ebs), erstellt OpsWorks Stacks ein neues Volume und hängt es jeder Instance an, wenn die Instance gestartet wird. Wenn Sie das Volume später von einer Instance trennen möchten, verwenden Sie die Seite [Resources (Ressourcen)](resources.md).
Wenn OpsWorks Stacks eine Instanz einer Ebene auto heilt, werden Volumen wie folgt behandelt:
+ Wenn das Volume an die Instance angehängt wurde, als die Instance ausfiel, werden das Volume und seine Daten gespeichert, und OpsWorks Stacks fügt es der neuen Instanz hinzu.
+ Wenn das Volume zum Zeitpunkt des Fehlschlagens der Instance dieser nicht zugewiesen war, erstellt OpsWorks Stacks ein neues, leeres Volume mit der von dem Layer definierten Konfiguration und ordnet es der neuen Instance zu.
Auto Healing ist standardmäßig aktiviert, aber Sie können es durch [Bearbeiten der allgemeinen Einstellungen des Layers](workinglayers-basics-edit.md) deaktivieren.
**Wichtig**
Wenn Sie Auto Healing aktiviert haben, stellen Sie sicher, dass Sie die folgenden Schritte ausführen:
Verwenden Sie nur die OpsWorks Stacks-Konsole, CLI oder API, um Instanzen zu stoppen.
Wenn Sie eine Instance auf andere Weise beenden, z. B. über die EC2 Amazon-Konsole, behandelt OpsWorks Stacks die Instance als ausgefallen und repariert sie auto.
Verwenden Sie Amazon EBS-Volumes, um alle Daten zu speichern, die Sie nicht verlieren möchten, wenn die Instance auto repariert wird.
Auto Healing stoppt die alte EC2 Amazon-Instance, wodurch alle Daten zerstört werden, die nicht auf einem Amazon EBS-Volume gespeichert sind. Amazon EBS-Volumes werden wieder an die neue Instance angehängt, wodurch alle gespeicherten Daten erhalten bleiben.
# Löschen einer Ebene OpsWorks
**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).
Wenn du eine OpsWorks Stacks-Ebene nicht mehr benötigst, kannst du sie aus deinem Stack löschen.
**Um eine OpsWorks Ebene zu löschen**
1. Klicken Sie im Navigationsbereich auf **Instances**.
1. Klicken Sie auf der Seite **Instances** unterhalb des Namens des zu löschenden Layers für jede Instance in der Spalte **Actions** auf **stop**.
![\[Confirmation dialog to stop a PHP app server instance, warning of potential data loss.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/stop_instance.png)
1. Nachdem jede Instance beendet worden ist, klicken Sie auf **delete (Löschen)**, um es aus dem Layer zu entfernen.
1. Klicken Sie im Navigationsbereich auf **Layers (Layers)**.
1. Wählen Sie auf der Seite **Layers (Layers)** die Option **Delete (Löschen)** aus.
![\[PHP App Server settings page with options for Recipes, Network, EBS Volumes, and Security.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/delete_layer.png)
# Elastic Load Balancing Lastenausgleichsebene
**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).
Elastic Load Balancing funktioniert etwas anders als eine OpsWorks Stacks-Ebene. Anstatt eine Ebene zu erstellen und ihr Instances hinzuzufügen, verwenden Sie die Elastic Load Balancing Balancing-Konsole oder API, um einen Load Balancer zu erstellen und ihn dann an einen vorhandenen Layer anzuhängen. Elastic Load Balancing verteilt nicht nur den Traffic auf die Instances des Layers, sondern macht auch Folgendes:
+ Erkennt fehlerhafte EC2 Amazon-Instances und leitet den Datenverkehr an die verbleibenden fehlerfreien Instances weiter, bis die fehlerhaften Instances wiederhergestellt wurden.
+ Er skaliert als Reaktion auf den eingehenden Datenverkehr automatisch die Kapazität zur Anforderungsbearbeitung.
+ Wenn Sie die Funktion [Connection Draining](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-conn-drain.html) aktivieren, schickt der Load Balancer keine neuen Anforderungen mehr an fehlerhafte oder abgemeldete Instances, sondern hält die Verbindung bis zu einem festgelegten Zeitüberschreitungswert aufrecht, damit die Instances laufende Anforderungen abschließen können.
Nachdem Sie einen Load Balancer an eine Ebene angehängt haben, führt Stacks die folgenden Schritte aus: OpsWorks
+ Meldet alle derzeit registrierten Instances ab.
+ Registriert automatisch die Instances der Ebene, einschließlich last- und zeitbasierter Instances, wenn sie online gehen, und meldet sie automatisch wieder ab, wenn sie offline gehen.
+ Startet automatisch das Routing von Anfragen an registrierte Instances in ihren Availability Zones.
Wenn Sie die Funktion zum [Entleeren von Verbindungen](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/config-conn-drain.html) des Load Balancers aktiviert haben, können Sie angeben, ob OpsWorks Stacks sie unterstützt. Wenn Sie die Unterstützung für Verbindungsabbau aktivieren (Standardeinstellung), führt OpsWorks Stacks nach dem Herunterfahren einer Instance Folgendes aus:
+ Meldet die Instance vom Load Balancer ab.
Der Load Balancer sendet keine neuen Anforderungen mehr und startet den Verbindungsausgleich.
+ Verzögert das Auslösen eines [Shutdown-Lebenszyklusereignisses](workingcookbook-events.md) bis der Load Balancer den Verbindungsausgleich abgeschlossen hat.
Wenn Sie die Unterstützung für Verbindungsverlust nicht aktivieren, löst OpsWorks Stacks das Shutdown-Ereignis aus, sobald die Instance heruntergefahren wird, auch wenn die Instance immer noch mit dem Load Balancer verbunden ist.
Um Elastic Load Balancing mit einem Stack zu verwenden, müssen Sie zunächst mithilfe der Elastic Load Balancing-Konsole, CLI oder API einen oder mehrere Load Balancer in derselben Region erstellen. Dabei sollten Sie Folgendes beachten:
+ Sie können einem Layer nur einen Load Balancer anfügen.
+ Jeder Load Balancer ist nur für einen Layer zuständig.
+ OpsWorks Stacks unterstützt den Application Load Balancer nicht. Sie können Classic Load Balancer nur mit OpsWorks Stacks verwenden.
Das bedeutet, dass Sie für jede Ebene in jedem Stack, den Sie ausgleichen möchten, einen separaten Elastic Load Balancing Load Balancer erstellen und ihn nur für diesen Zweck verwenden müssen. Es wird empfohlen, jedem Elastic Load Balancing Load Balancer, den Sie mit OpsWorks Stacks verwenden möchten, einen eindeutigen Namen zuzuweisen, z. B. MyStack 1- RailsLayer -ELB, um zu vermeiden, dass ein Load Balancer für mehr als einen Zweck verwendet wird.
**Wichtig**
Wir empfehlen, neue Elastic Load Balancing Load Balancer für Ihre OpsWorks Stacks-Layer zu erstellen. Wenn Sie sich dafür entscheiden, einen vorhandenen Elastic Load Balancing Load Balancer zu verwenden, sollten Sie zunächst sicherstellen, dass er nicht für andere Zwecke verwendet wird und keine angehängten Instances hat. Nachdem der Load Balancer an die Ebene angehängt wurde, werden alle vorhandenen Instances OpsWorks entfernt und der Load Balancer so konfiguriert, dass er nur die Instances der Ebene verarbeitet. Es ist zwar technisch möglich, die Elastic Load Balancing Balancing-Konsole oder API zu verwenden, um die Konfiguration eines Load Balancers zu ändern, nachdem er an eine Ebene angehängt wurde, aber Sie sollten dies nicht tun, da die Änderungen nicht dauerhaft sind.
**So fügen Sie einem Layer einen Elastic Load Balancing Load Balancer hinzu**
1. Falls Sie dies noch nicht getan haben, verwenden Sie die [Elastic Load Balancing Balancing-Konsole](https://console.aws.amazon.com/ec2/#s=LoadBalancers), API oder CLI, um einen Load Balancer in der Region des Stacks zu erstellen. Wenn Sie einen Load Balancer erstellen, führen Sie die folgenden Schritte aus:
+ Stellen Sie sicher, dass Sie eine Zustandsprüfung für den Ping-Pfad angeben, der für Ihre Anwendung geeignet ist.
Das Standard-Ping-Pfad ist `/index.html`. Wenn Ihre Anwendung `index.html` nicht umfasst, müssen Sie einen entsprechenden Ping-Pfad angeben oder die Zustandsprüfung schlägt fehl.
+ Wenn Sie die Funktion [Connection Draining](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/config-conn-drain.html) verwenden möchten, stellen Sie sicher, dass die Funktion aktiviert ist und einen geeigneten Zeitüberschreitungswert hat.
Weitere Informationen finden Sie unter [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/Welcome.html).
1. [Erstellen Sie den Layer](workinglayers-basics-create.md), für den ein Verbindungausgleich erfolgen soll oder [bearbeiten Sie die Netzwerk-Einstellungen eines vorhandenen Layers](workinglayers-basics-edit.md).
**Anmerkung**
Sie können keinen Load Balancer anfügen, wenn Sie einen benutzerspezifischen Layer erstellen. Sie müssen die Layer-Einstellungen bearbeiten.
1. Wählen Sie unter **Elastic Load Balancing** den Load Balancer aus, den Sie an den Layer anhängen möchten, und geben Sie an, ob OpsWorks Stacks Connection Draining unterstützen sollen.
Nachdem Sie einen Load Balancer an eine Ebene angehängt haben, löst OpsWorks Stacks ein [Configure-Lifecycle-Ereignis](workingcookbook-events.md) auf den Instances des Stacks aus, um sie über die Änderung zu informieren. OpsWorks Stacks löst auch ein Configure-Ereignis aus, wenn Sie einen Load Balancer trennen.
**Anmerkung**
Nach dem Booten einer Instanz führt OpsWorks Stacks die [Setup- und Deploy-Rezepte aus, mit denen Pakete installiert und](workingcookbook-executing.md) Anwendungen bereitgestellt werden. Nachdem diese Rezepte abgeschlossen sind, befindet sich die Instance im Online-Status und OpsWorks Stacks registriert die Instance bei Elastic Load Balancing. OpsWorks Stacks löst auch ein Configure-Ereignis aus, nachdem die Instance online gegangen ist. Das bedeutet, dass die Elastic Load Balancing Balancing-Registrierung und die Configure-Rezepte gleichzeitig ausgeführt werden können und die Instance möglicherweise registriert wird, bevor die Configure-Rezepte abgeschlossen sind. Um sicherzustellen, dass ein Rezept abgeschlossen ist, bevor eine Instance bei Elastic Load Balancing registriert wird, sollten Sie das Rezept zu den Lifecycle-Ereignissen Setup oder Deploy des Layers hinzufügen. Weitere Informationen finden Sie unter [Ausführen von Rezepten](workingcookbook-executing.md).
Manchmal ist es sinnvoll, eine Instance von einem Load Balancer zu entfernen. Wenn Sie beispielsweise eine Anwendung aktualisieren, empfehlen wir, dass Sie die Anwendung zunächst für eine einzelne Instance bereitstellen und prüfen, ob sie ordnungsgemäß funktioniert, bevor Sie die Anwendung für alle Instances bereitstellen. In der Regel entfernen Sie die Instance aus dem Load Balancer, sodass sie keine Benutzeranforderungen erhält, bis die Aktualisierung überprüft wurde.
Sie müssen die Elastic Load Balancing Balancing-Konsole oder API verwenden, um eine Online-Instance vorübergehend von einem Load Balancer zu entfernen. Im Folgenden wird beschrieben, wie Sie die Konsole verwenden.
**Vorübergehendes Entfernen einer Instance von einem Load Balancer**
1. Öffnen Sie die [ EC2 Amazon-Konsole](https://console.aws.amazon.com/ec2/) und wählen Sie **Load Balancers**.
1. Wählen Sie einen geeigneten Load Balancer und öffnen Sie die Registerkarte **Instances (Instances)**.
1. Wählen Sie **Remove from Load Balancer (Vom Load Balancer entfernen)** in der Spalte **Actions (Aktionen)** der Instance aus.
1. Wenn Sie fertig sind, wählen Sie **Edit Instances (Instances bearbeiten)** aus und schicken die Instance an den Load Balancer zurück.
**Wichtig**
Wenn Sie die Elastic Load Balancing-Konsole oder API verwenden, um eine Instance aus einem Load Balancer zu entfernen, müssen Sie sie auch mit Elastic Load Balancing wiederherstellen. OpsWorks Stacks kennt keine Operationen, die Sie mit anderen Servicekonsolen oder ausführen APIs, und es wird die Instance auch nicht für Sie an den Load Balancer zurückgeben. Manchmal kann OpsWorks Stacks die Instance wieder zum ELB hinzufügen, aber dieses Verhalten ist nicht garantiert und tritt nicht in allen Fällen auf.
Sie können mehrere Load Balancer an eine bestimmte Gruppe von Instances anfügen:
**Anfügen mehrerer Load Balancer**
1. Verwenden Sie die [Elastic Load Balancing Balancing-Konsole](https://console.aws.amazon.com/ec2/#s=LoadBalancers), API oder CLI, um eine Reihe von Load Balancern zu erstellen.
1. [Erstellen Sie einen benutzerspezifischen Layer](workinglayers-custom.md) für jeden Load Balancer und fügen Sie einen der Load Balancer an. Sie müssen keine benutzerspezifischen Rezepte für diese Layer implementieren, ein Standard-Layer ist ausreichend.
1. [Fügen Sie die Gruppe der Instances](workinginstances-add.md) jedem benutzerspezifischen Layer hinzu.
Sie können die Eigenschaften eines Load Balancers überprüfen, indem Sie die Seite "Instances" aufrufen und auf den Namen des entsprechenden Load Balancers klicken.
![\[PHP App Server table showing two online instances with their details and status.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/elb_view.png)
Die Seite **ELB (ELB)** zeigt die grundlegenden Eigenschaften des Load Balancers an, einschließlich seines DNS-Namens und des Zustandsprüfungsstatus der dazugehörigen Instances. Wenn der Stack in einem VPC ausgeführt wird, zeigt die Seite Subnetze statt der Availability Zones an. Ein grünes Häkchen verweist auf eine funktionierende Instance. Klicken Sie auf den Namen, um über den Load Balancer eine Verbindung mit einem Server herzustellen.
![\[ELB My-Stack-PHP settings showing DNS name, layer, region, and instance status.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/elb_properties.png)
# Amazon RDS-Serviceschicht
**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).
Eine Amazon RDS-Service-Schicht stellt eine Amazon RDS-Instance dar. Die Ebene kann nur bestehende Amazon RDS-Instances darstellen, die Sie separat mithilfe der [Amazon RDS-Konsole](https://console.aws.amazon.com/rds/) oder API erstellen müssen.
Das grundlegende Verfahren für die Integration einer Amazon RDS-Serviceschicht in Ihren Stack lautet wie folgt:
1. Verwenden Sie die Amazon RDS-Konsole, API oder CLI, um eine Instance zu erstellen.
Stellen Sie sicher, dass Sie die Instance-ID, den Master-Benutzernamen, das Master-Passwort und den Datenbanknamen erfassen.
1. Um Ihrem Stack eine Amazon RDS-Ebene hinzuzufügen, registrieren Sie die Amazon RDS-Instance beim Stack.
1. Hängen Sie den Layer an eine App an, wodurch die Verbindungsinformationen der Amazon RDS-Instance zu den [`deploy`Attributen](workingcookbook-json.md#workingcookbook-json-deploy) der App hinzugefügt werden.
1. Verwenden Sie die sprachspezifischen Dateien oder die Informationen in den `deploy` Attributen, um die Anwendung mit der Amazon RDS-Instance zu verbinden.
Weitere Informationen zum Verbinden einer Anwendung mit einem Datenbankserver finden Sie unter [Verbinden einer Anwendung mit einem Datenbankserver](workingapps-connectdb.md)
**Warnung**
Stellen Sie sicher, dass die Zeichen, aus denen das Master-Passwort und der -Benutzername Ihrer Instance bestehen, mit Ihrem Anwendungsserver kompatibel sind. Wenn beispielsweise die Java App Server-Ebene `&` in einer der beiden Zeichenketten enthalten ist, wird ein XML-Analysefehler verursacht, der den Start des Tomcat-Servers verhindert.
**Topics**
+ [Angeben von Sicherheitsgruppen](#workinglayers-db-rds-security)
+ [Registrierung einer Amazon RDS-Instance mit einem Stack](#workinglayers-db-rds-register)
+ [Amazon RDS Service Layers mit Apps verknüpfen](#workinglayers-db-rds-register-attach)
+ [Entfernen eines Amazon RDS-Service Layers aus einem Stack](#workinglayers-db-rds-register-remove)
## Angeben von Sicherheitsgruppen
Um eine Amazon RDS-Instance mit OpsWorks Stacks zu verwenden, müssen die Datenbank- oder VPC-Sicherheitsgruppen den Zugriff von den entsprechenden IP-Adressen aus zulassen. Für den Produktivbetrieb beschränkt die Sicherheitsgruppe in der Regel den Zugriff auf die IP-Adressen, die auf die Datenbank zugreifen müssen. Dazu gehören in der Regel die Adressen der Systeme, die Sie zur Verwaltung der Datenbank verwenden, und der OpsWorks Stacks-Instances, die auf die Datenbank zugreifen müssen. OpsWorks Stacks erstellt automatisch eine EC2 Amazon-Sicherheitsgruppe für jeden Layer-Typ, wenn Sie Ihren ersten Stack in einer Region erstellen. Eine einfache Möglichkeit, Zugriff für OpsWorks Stacks-Instances zu gewähren, besteht darin, der Amazon RDS-Instance oder VPC die entsprechenden OpsWorks Stacks-Sicherheitsgruppen zuzuweisen.
**So geben Sie Sicherheitsgruppen für eine bestehende Amazon RDS-Instance an**
1. Öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Klicken Sie im Navigationsbereich auf **Instances** und wählen Sie die entsprechende Amazon RDS-Instance aus. Klicken Sie auf **Instance Actions (Instance-Aktionen)**, **Modify (Ändern)**.
1. Wählen Sie die folgenden Sicherheitsgruppen aus der Liste **Security Group (Sicherheitsgruppe)** aus und klicken Sie dann auf **Continue (Weiter)** und **Modify DB Instance (DB-Instance ändern)**, um die Instance zu aktualisieren.
+ Die **Sicherheitsgruppe AWS- OpsWorks -DB-Master-Server** (). *security\$1group\$1id*
+ Die Sicherheitsgruppe für den Anwendungsserver-Layer, dessen Instances eine Verbindung zur Datenbank aufnehmen. Der Gruppenname enthält den Layer-Namen. Um beispielsweise Datenbankzugriff auf PHP App Server-Instances bereitzustellen, geben Sie die Gruppe **AWS- OpsWorks -PHP-App-Server** an.
Wenn Sie eine neue Amazon RDS-Instance erstellen, können Sie die entsprechenden OpsWorks Stacks-Sicherheitsgruppen auf der Seite „**Erweiterte Einstellungen konfigurieren**“ des Assistenten zum Starten einer DB-Instance angeben. Eine Beschreibung zur Verwendung dieses Assistenten finden Sie unter [Erstellen einer MySQL DB-Instance und Verbinden mit einer Datenbank auf einer MySQL-DB-Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.CreatingConnecting.MySQL.html).
Weitere Informationen zum Festlegen von VPC-Sicherheitsgruppen finden Sie unter [Sicherheitsgruppen für Ihre VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html).
## Registrierung einer Amazon RDS-Instance mit einem Stack
Um einen Amazon RDS-Service Layer zu einem Stack hinzuzufügen, müssen Sie eine Instance beim Stack registrieren.
**So registrieren Sie eine Amazon RDS-Instance bei einem Stack**
1. Klicken Sie in der OpsWorks Stacks-Konsole im Navigationsbereich auf **Layer**, klicken Sie auf **\$1 Layer oder Layer** **hinzufügen, um die Seite „Layer** **hinzufügen**“ zu öffnen, und klicken Sie dann auf die Registerkarte **RDS**.
1. Falls erforderlich, aktualisieren Sie die Stack-Servicerolle wie in [Aktualisieren der Stack-Servicerolle](#workinglayers-db-rds-register-role) beschrieben.
1. Klicken Sie auf die Registerkarte RDS, um die verfügbaren Amazon RDS-Instances aufzulisten.
**Anmerkung**
Wenn Ihr Konto keine Amazon RDS-Instances hat, können Sie eine erstellen, indem Sie auf der Registerkarte RDS auf **RDS-Instance hinzufügen** klicken. Dadurch gelangen Sie zur Amazon RDS-Konsole und **starten den Assistenten zum Starten einer DB-Instance**. Sie können auch direkt zur [Amazon RDS-Konsole](https://console.aws.amazon.com/rds/) gehen und auf **Eine DB-Instance starten** klicken oder die Amazon RDS-API oder CLI verwenden. Weitere Informationen zum Erstellen einer Amazon RDS-Instance finden Sie unter [Erste Schritte mit Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.html).
1. Wählen Sie die geeignete Instance aus, tragen Sie bei **User (Benutzer)** und **Password (Passwort)** den richtigen Benutzer und das richtige Passwort ein und klicken Sie dann auf **Register to Stack (Beim Stack registrieren)**.
**Wichtig**
Sie müssen sicherstellen, dass der Benutzer und das Passwort, die Sie zur Registrierung der Amazon RDS-Instance verwenden, einem gültigen Benutzer und Passwort entsprechen. Ist dies nicht der Fall, können die Anwendungen keine Verbindung zur Instance herstellen. Sie können jedoch den [Layer bearbeiten](workinglayers-basics-edit.md), um einen gültigen Benutzer und ein gültiges Passwort zu erstellen und dann die Anwendung erneut bereitstellen.
![\[RDS instance details showing connection information for opsinstance2 with MySQL engine.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/rds-register.png)
Wenn Sie einen Amazon RDS-Service Layer zu einem Stack hinzufügen, weist OpsWorks Stacks ihm eine ID zu und fügt die zugehörige Amazon RDS-Konfiguration dem Attribut der [Stack-Konfiguration und dem Attribut des Deployment-Attributs [`[:opsworks][:stack]`](attributes-json-opsworks-stack.md)](workingcookbook-json.md)hinzu.
**Anmerkung**
Wenn Sie das Passwort einer registrierten Amazon RDS-Instance ändern, müssen Sie das Passwort in OpsWorks Stacks manuell aktualisieren und dann Ihre Apps erneut bereitstellen, um die Stack-Konfiguration und die Bereitstellungsattribute auf den Stack-Instances zu aktualisieren.
**Topics**
+ [Aktualisieren der Stack-Servicerolle](#workinglayers-db-rds-register-role)
### Aktualisieren der Stack-Servicerolle
Jeder Stack hat eine [IAM-Servicerolle](opsworks-security-servicerole.md), die angibt, welche Aktionen OpsWorks Stacks in Ihrem Namen mit anderen AWS-Services ausführen kann. Um eine Amazon RDS-Instance bei einem Stack zu registrieren, muss ihre Service-Rolle OpsWorks Stacks Berechtigungen für den Zugriff auf Amazon RDS gewähren.
Wenn Sie zum ersten Mal einen Amazon RDS-Service-Layer zu einem Ihrer Stacks hinzufügen, fehlen der Service-Rolle möglicherweise die erforderlichen Berechtigungen. Wenn dies der Fall ist, sehen Sie Folgendes, wenn Sie auf die Registerkarte RDS auf der Seite **Add Layer (layer hinzufügen)** klicken.
![\[Warning message about OpsWorksIAM role needing RDS instances access policy.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/rds-iam-update.png)
Klicken Sie auf **Aktualisieren**, damit OpsWorks Stacks die Richtlinie der Servicerolle wie folgt aktualisiert.
```
{"Statement": [{"Action": ["ec2:*", "iam:PassRole",
"cloudwatch:GetMetricStatistics",
"elasticloadbalancing:*",
"rds:*"],
"Effect": "Allow",
"Resource": ["*"] }]
}
```
**Anmerkung**
Sie müssen das Update nur einmal ausführen. Die aktualisierte Rolle wird dann automatisch von allen Ihren Stacks verwendet.
## Amazon RDS Service Layers mit Apps verknüpfen
Nachdem Sie einen Amazon RDS-Service-Layer hinzugefügt haben, können Sie ihn mit einer App verknüpfen.
+ Sie können einer App einen Amazon RDS-Layer zuordnen, wenn Sie [die App erstellen](workingapps-creating.md), oder später, indem Sie [die Konfiguration der App bearbeiten](workingapps-editing.md).
+ Um eine Amazon RDS-Ebene von einer App zu trennen, bearbeiten Sie die Konfiguration der App, um einen anderen Datenbankserver oder keinen Server anzugeben.
Die Amazon RDS-Ebene bleibt Teil des Stacks und kann mit einer anderen App verknüpft werden.
Nachdem Sie eine Amazon RDS-Instance mit einer App verknüpft haben, platziert OpsWorks Stacks die Datenbankverbindungsinformationen auf den Servern der App. Diese Informationen können dann von der Anwendung auf jeder Server-Instance verwendet werden, um eine Verbindung mit der Datenbank herzustellen. Weitere Informationen zum Herstellen einer Verbindung mit einer Amazon RDS-Instance finden Sie unter[Verbinden einer Anwendung mit einem Datenbankserver](workingapps-connectdb.md).
## Entfernen eines Amazon RDS-Service Layers aus einem Stack
Um einen Amazon RDS-Service Layer aus einem Stack zu entfernen, müssen Sie ihn deregistrieren.
**So melden Sie einen Amazon RDS-Service Layer ab**
1. Klicken Sie im Navigationsbereich auf **Layers** und dann auf den Namen des Amazon RDS-Service-Layers.
1. Klicken Sie auf **Deregister (Abmelden)** und bestätigen Sie, dass Sie den Layer abmelden möchten.
Dieses Verfahren entfernt die Ebene aus dem Stack, löscht jedoch nicht die zugrunde liegende Amazon RDS-Instance. Die Instance und alle Datenbanken verbleiben in Ihrem Konto und können mit anderen Stacks registriert werden. Sie müssen die Amazon RDS-Konsole, API oder CLI verwenden, um die Instance zu löschen. Weitere Informationen finden Sie unter [ Löschen einer DB-Instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.html#CHAP_GettingStarted.Deleting).
# ECS-Cluster-Ebenen
**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).
Der [Amazon Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) (Amazon ECS) verwaltet Docker-Container in einem Cluster von Amazon Elastic Compute Cloud (Amazon EC2) -Instances, den sogenannten Container-Instances. Eine ECS-Cluster-Schicht stellt einen Amazon ECS-Cluster dar und vereinfacht die Clusterverwaltung, indem sie Funktionen wie die folgenden bietet:
+ Optimierte Bereitstellung und Verwaltung der Container-Instance
+ Betriebssystem und Paketaktualisierungen der Container-Instance
+ Verwaltung von Benutzerberechtigungen
+ Leistungsüberwachung der Container-Instance
+ Volumenverwaltung für Amazon Elastic Block Store (Amazon EBS)
+ Verwaltung von öffentlichen und Elastic IP-Adressen
+ Verwaltung der Sicherheitsgruppe
Für die ECS-Cluster-Schicht gelten die folgenden Einschränkungen und Anforderungen:
+ Der Layer ist nur für Chef 11.10- oder Chef 12-Linux-Stacks verfügbar, die in einer VPC ausgeführt werden, einschließlich einer [Standard-VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-supported-platforms.html).
+ Auf den Instances des Layers muss eines der folgenden Betriebssysteme ausgeführt werden.
+ Amazon Linux 2
+ Amazon Linux 2018.03
+ Amazon Linux 2017.09
+ Amazon Linux 2017.03
+ Amazon Linux 2016.09
+ Amazon Linux 2016.03
+ Amazon Linux 2015.09
+ Amazon Linux 2015.03
+ Ubuntu 18.04 LTS
+ Ubuntu 16.04 LTS
+ Ubuntu 14.04 LTS
+ Benutzerdefiniert
+ Die [OpsWorks Stacks-Agent-Version](workingstacks-creating.md#workingstacks-creating-advanced) auf den Layer-Instances muss `3425-20150727112318` oder später sein.
**Topics**
+ [Hinzufügen einer ECS-Clusterschicht zu einem Stack](#workinglayers-ecscluster-add)
+ [Verwalten des ECS-Clusters](#workinglayers-ecscluster-manage)
+ [Löschen eines ECS-Cluster-Layers aus einem Stack](#workinglayers-ecscluster-delete)
## Hinzufügen einer ECS-Clusterschicht zu einem Stack
OpsWorks Stacks vereinfacht das Starten und Verwalten von Container-Instances für bestehende Amazon ECS-Cluster. Verwenden Sie die Amazon ECS-Konsole, die Befehlszeilenschnittstelle (CLI) oder die API, um andere Amazon ECS-Entitäten wie Cluster und Aufgaben zu erstellen oder zu starten. (Weitere Informationen finden Sie im [Amazon Elastic Container Service Developer Guide](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/).) Anschließend können Sie einem Stack einen Cluster zuordnen, indem Sie eine ECS-Cluster-Ebene erstellen, mit der Sie den Cluster in OpsWorks Stacks verwalten können.
Sie können Cluster wie folgt mit Stacks verknüpfen:
+ Jeder Stack kann eine ECS-Cluster-Schicht haben, die einen einzelnen Cluster darstellt.
+ Ein Cluster kann mit nur einem Stack verknüpft werden.
Bevor Sie ECS-Cluster-Layer zu Ihren Stacks hinzufügen können, müssen Sie die Servicerolle OpsWorks Stacks AWS Identity and Access Management (IAM) aktualisieren, die normalerweise benannt ist`aws-opsworks-service-role`, damit OpsWorks Stacks in Ihrem Namen mit Amazon ECS interagieren kann. Weitere Informationen zur Servicerolle finden Sie unter [OpsWorks Stacks erlauben, in Ihrem Namen zu handeln](opsworks-security-servicerole.md).
Wenn Sie zum ersten Mal eine ECS-Cluster-Ebene erstellen, bietet die Konsole eine Schaltfläche „**Aktualisieren**“, mit der Sie OpsWorks Stacks anweisen können, die Rolle für Sie zu aktualisieren. OpsWorks Stacks zeigt dann die Seite „**Ebene hinzufügen**“ an, auf der Sie die Ebene zum Stack hinzufügen können. Sie müssen die Servicerolle nur einmal aktualisieren. Anschließend können Sie die aktualisierte Rolle verwenden, um einem beliebigen Stack eine ECS-Cluster-Ebene hinzuzufügen.
**Anmerkung**
Wenn Sie möchten, können Sie die Richtlinie der Servicerolle auch manuell aktualisieren, indem Sie die Berechtigung `ecs:*` wie folgt zur vorhandenen Richtlinie hinzufügen:
```
{
"Statement": [
{
"Action": [
"ec2:*",
"iam:PassRole",
"cloudwatch:GetMetricStatistics",
"elasticloadbalancing:*",
"rds:*",
"ecs:*"
],
"Effect": "Allow",
"Resource": ["*"]
}
]
}
```
Für die Verknüpfung eines Clusters mit einem Stack sind zwei Vorgänge erforderlich: Registrieren des Clusters beim Stack und Erstellen des zugehörigen Layers. Die OpsWorks Stacks-Konsole kombiniert diese Schritte. Bei der Layererstellung wird der angegebene Cluster automatisch registriert. Wenn Sie die OpsWorks Stacks-API, CLI oder das SDK verwenden, müssen Sie separate Operationen verwenden, um den Cluster zu registrieren und die zugehörige Ebene zu erstellen. Um die Konsole zu verwenden, um Ihrem Stack eine ECS-Cluster-Ebene hinzuzufügen, wählen Sie **Layers**, wählen Sie **\$1Layer** oder **Add a Layer** und dann den Layer-Typ ECS-Cluster.
![\[Form for adding an ECS Cluster Layer, showing layer type, Cluster selection, and EC2 instance profile options.\]](http://docs.aws.amazon.com/de_de/opsworks/latest/userguide/images/add_layer_ecs.png)
Auf der Seite **Add Layer (Layer hinzufügen)** stehen folgende Konfigurationsoptionen zur Verfügung:
**ECS-Cluster**
Der Amazon ECS-Cluster, den Sie beim Stack registrieren möchten.
**EC2 Instanzprofil**
Das Amazon Elastic Compute Cloud (Amazon EC2) -Instanzprofil des Clusters. Dieses Profil gewährt Anwendungen, die auf den Container-Instances des Clusters ausgeführt werden, die Erlaubnis, auf andere AWS-Services, einschließlich Amazon ECS, zuzugreifen. Wenn Sie Ihre erste ECS-Cluster-Ebene erstellen, wählen Sie **Neues Profil mit ECS-Zugriff**, um OpsWorks Stacks anzuweisen, das erforderliche Profil mit dem Namen `aws-opsworks-ec2-role-with-ecs` zu erstellen. Sie können dieses Profil dann für alle nachfolgenden ECS-Cluster-Ebenen verwenden. Weitere Informationen zum Instance-Profil finden Sie unter [Angeben von Berechtigungen für Apps, die auf Instanzen ausgeführt werden EC2](opsworks-security-appsrole.md).
Sie können andere Einstellungen durch [Bearbeiten der Layer-Konfiguration](workinglayers-basics-edit.md) festlegen, darunter:
+ [Einen Elastic Load Balancing Load Balancer an die Ebene anhängen](workinglayers-basics-edit.md#workinglayers-basics-edit-network).
Dieser Ansatz mag für einige Anwendungsfälle geeignet sein, Amazon ECS bietet jedoch anspruchsvollere Optionen. Weitere Informationen finden Sie unter [Service Load Balancing](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html).
+ Festlegen, ob den Container-Instances automatisch [öffentliche IP-Adressen oder Elastic IP-Adressen](workinglayers-basics-edit.md#workinglayers-basics-edit-network) zugewiesen werden sollen.
Wenn Sie die automatische Zuweisung für beide Adresstypen deaktivieren, geht die Instance nicht online, es sei denn, das Subnetz besitzt einen ordnungsgemäß konfigurierten NAT. Weitere Informationen finden Sie unter [Ausführen eines Stacks in einer VPC](workingstacks-vpc.md).
## Verwalten des ECS-Clusters
Nachdem Sie eine ECS-Cluster-Ebene erstellt haben, können Sie OpsWorks Stacks verwenden, um den Cluster wie folgt zu verwalten:
**Bereitstellen und Verwalten von Container-Instances**
Anfänglich umfasst eine ECS-Cluster-Ebene keine Container-Instances, selbst wenn dies im ursprünglichen Cluster der Fall war. Eine Möglichkeit besteht darin, die Instances des Layers durch eine geeignete Kombination der folgenden Verfahren zu verwalten:
+ Fügen Sie [24/7-Instances](workinginstances-add.md) manuell zum Layer hinzu und [löschen Sie sie](workinginstances-delete.md), wenn sie nicht mehr benötigt werden.
+ Fügen Sie Instances zu einem Zeitplan hinzu bzw. löschen Sie sie, indem Sie [zeitbasierte Instances](workinginstances-autoscaling-timebased.md) zum Layer hinzufügen.
+ Fügen Sie Instanzen auf der Grundlage von OpsWorks Stacks-Host-Metriken oder CloudWatch -Alarmen hinzu oder löschen Sie sie, indem Sie der [Ebene lastbasierte Instances](workinginstances-autoscaling-loadbased.md) hinzufügen.
Wenn Amazon ECS für das Standardbetriebssystem des Stacks nicht unterstützt wird, müssen Sie explizit ein unterstütztes Betriebssystem angeben — Amazon Linux 2, Amazon Linux 2018.03, Amazon Linux 2017.09, Amazon Linux 2017.03, Amazon Linux 2016.09, Amazon Linux 2016.03, Amazon Linux 2015.09, Amazon Linux 2015.03, Ubuntu 18.04 LTS, Ubuntu 16.04 LTS, Ubuntu 14.04 LTS oder Benutzerdefiniert — wenn Sie erstellen Sie die Container-Instances. Verwenden Sie das ECS-optimierte AMI nicht, um Instances in einer ECS-Schicht zu erstellen, da dieses AMI den ECS-Agenten bereits enthält. OpsWorks Stacks versucht außerdem, den ECS-Agenten während der Einrichtung der Instanz zu installieren, und der Konflikt kann dazu führen, dass die Installation fehlschlägt.
Weitere Informationen finden Sie unter[Optimieren der Serveranzahl](best-practices-autoscale.md). OpsWorks Stacks weist jeder Instance die **OpsWorksAWS-ECS-Cluster-Sicherheitsgruppe** zu. Nachdem jede neue Instance fertig gebootet wurde, konvertiert OpsWorks Stacks sie in eine Container-Instance, indem Docker und der Amazon ECS-Agent installiert und die Instance anschließend im Cluster registriert werden.
Wenn Sie lieber vorhandene Container-Instances verwenden möchten, können Sie [sie beim Stack registrieren und sie der](registered-instances-register.md) [ECS-Cluster-Ebene zuweisen](registered-instances-assign.md). Beachten Sie, dass auf den Instances ein unterstütztes Betriebssystem ausgeführt werden muss: Amazon Linux 2015.03 oder höher oder Ubuntu 14.04 LTS oder höher.
Eine Container-Instance kann nicht sowohl zu einer ECS-Cluster-Ebene als auch zu einer anderen integrierten Schicht gehören. Eine Container-Instance *kann* jedoch zu einer ECS-Cluster-Ebene und einer oder mehreren [benutzerdefinierten Ebenen](workinglayers-custom.md) gehören.
**Ausführen von Betriebssystem- und Paketaktualisierungen**
Nachdem das Booten einer neuen Instance abgeschlossen ist, installiert OpsWorks Stacks die neuesten Updates. Anschließend können Sie OpsWorks Stacks verwenden, um die Container-Instances auf dem neuesten Stand zu halten. Weitere Informationen finden Sie unter [Verwalten von Sicherheitsupdates](workingsecurity-updates.md).
**Benutzerberechtigungen verwalten**
OpsWorks Stacks bietet eine einfache Möglichkeit, Berechtigungen für die Container-Instances zu verwalten, einschließlich der Verwaltung der SSH-Schlüssel der Benutzer. Weitere Informationen erhalten Sie unter [Verwalten von Benutzerberechtigungen](opsworks-security-users.md) und [Verwalten des SSH-Zugriffs](security-ssh-access.md).
**Überwachen der Leistungskennzahlen**
OpsWorks Stacks bietet eine Vielzahl von Möglichkeiten, Leistungskennzahlen für den Stack, die Ebene oder einzelne Instances zu überwachen. Weitere Informationen finden Sie unter [Überwachen](monitoring.md).
Andere Verwaltungsaufgaben, wie das Erstellen von Aufgaben oder Services, erledigen Sie über Amazon ECS. Weitere Informationen finden Sie im [Amazon Elastic Container Service-Entwicklerhandbuch](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/).
**Anmerkung**
Um direkt zur Seite des Clusters in der Amazon ECS-Konsole zu gelangen, wählen Sie **Instances** und dann **ECS-Cluster** aus, was sich in der oberen rechten Ecke des Abschnitts der ECS-Cluster-Ebene befindet.
## Löschen eines ECS-Cluster-Layers aus einem Stack
Wenn Sie den Cluster nicht mehr benötigen, löschen Sie die ECS-Cluster-Schicht und melden Sie den zugehörigen Cluster ab. Für das Entfernen eines Clusters aus einem Stack sind zwei Vorgänge erforderlich: Abmelden des Clusters und Löschen des zugehörigen Layers. Die OpsWorks Stacks-Konsole kombiniert diese Schritte. Durch das Löschen der Ebene wird der angegebene Cluster automatisch deregistriert. Wenn Sie die OpsWorks Stacks-API, CLI oder das SDK verwenden, müssen Sie separate Operationen verwenden, um den Cluster abzumelden und die zugehörige Ebene zu löschen.
**Um die Konsole zum Löschen einer ECS-Cluster-Ebene zu verwenden**
1. Wenn Sie kontrollieren möchten, wie Aufgaben heruntergefahren werden, verwenden Sie die Amazon ECS-Konsole, API oder CLI, um die Dienste des Clusters herunterzuskalieren und zu löschen. Weitere Informationen finden Sie unter [Aufräumen Ihrer Amazon ECS-Ressourcen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_CleaningUp.html).
1. [Stoppen Sie die Instances des Layers](workinginstances-starting.md#workinginstances-starting-stop) und [löschen Sie sie dann](workinginstances-delete.md). Wenn Sie eine Container-Instance beenden, stoppt OpsWorks Stacks automatisch alle laufenden Aufgaben, meldet die Instance vom Cluster ab und beendet die Instance.
**Anmerkung**
Wenn Sie vorhandene Container-Instances beim Stack registriert haben, können Sie die [Zuweisung der Instances vom Stack aufheben](registered-instances-unassign.md) und [sie dann abmelden](registered-instances-deregister.md), wodurch die Instances wieder durch ECS gesteuert werden.
1. [Löschen Sie die Ebene.](workinglayers-basics-delete.md) OpsWorks Stacks hebt die Registrierung des zugehörigen Clusters auf, löscht ihn jedoch nicht. Der Cluster verbleibt in Amazon ECS.
# Benutzerdefinierte OpsWorks Stapel (Ebenen)
**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).
Ein benutzerspezifischer Layer verfügt nur über eine minimale Anzahl an Rezepten. Anschließend fügen Sie dem Layer entsprechende Funktionen hinzu, indem Sie [benutzerspezifische Rezepte](workingcookbook.md) implementieren und sie den [Lebenszyklusereignissen](workingcookbook-events.md) des Layers zuordnen.
Der benutzerspezifische Layer hat die folgenden Konfigurationseinstellungen.
**Anmerkung**
OpsWorks Stacks installiert Ruby automatisch auf den Instanzen der Ebene. Wenn Sie Ruby-Code auf der Instance ausführen möchten, aber nicht die Standard-Ruby-Version verwenden möchten, können Sie benutzerspezifisches JSON-Format oder benutzerspezifische Attributdateien verwenden, um die gewünschte Version anzugeben. Weitere Informationen finden Sie unter [Ruby-Versionen](workingcookbook-ruby.md).
Die grundlegenden Schritte zum Erstellen eines benutzerspezifischen Layers sind wie folgt:
1. Implementieren Sie ein [Rezeptbuch](workingcookbook.md), das die Rezepte und die zugeordneten Dateien enthält, die bei der Installation und Konfiguration von Paketen, bei der Bearbeitung von Konfigurationsänderungen, der Bereitstellung von Anwendungen etc. erforderlich sind.
Je nach Ihren Anforderungen benötigen Sie unter Umständen auch Rezepte, die Bereitstellungen aufheben und Shutdowns ausführen. Weitere Informationen finden Sie unter [Cookbooks und Rezepte](workingcookbook.md).
1. Erstellen eines benutzerspezifischen Layers.
1. Weisen Sie Ihre Rezepte den entsprechenden [Lebenszyklusereignissen](workingcookbook-events.md) zu.
Anschließend fügen Sie dem Layer die Instances hinzu, starten diese und stellen Anwendungen für diese Instances bereit.
**Wichtig**
Um Anwendungen für Instances eines benutzerdefinierten Layers bereitzustellen, müssen Sie Rezepte implementieren, die Bereitstellungsvorgänge verarbeiten und sie dem Bereitstellungsereignis des Layers zuordnen.
# Paketinstallationen für Ihr Betriebssystem pro Layer
**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).
Ab Chef 12 müssen Sie benutzerdefinierte Rezepte verwenden, um Pakete auf Layer zu installieren, die auf verschiedenen Betriebssystemen ausgeführt werden. Auf diese Weise erhalten Sie maximale Flexibilität und Kontrolle über Paketinstallationen.
Nehmen wir beispielsweise an, Sie möchten Apache auf Layern installieren RedHat, auf denen Ubuntu- und Amazon-Versionen des Linux-Betriebssystems ausgeführt werden. Das Apache-Paket für RedHat und Amazon Linux heißt`httpd`, aber auf Ubuntu heißt es`apache2`.
Für unterschiedliche Paketbezeichnungen können Sie die Syntax wie im folgenden Beispielrezept verwenden. Mit dem Rezept wird das geeignete Apache-Paket für jedes Betriebssystem installiert. Dieses Beispiel basiert auf der [Chef-Dokumentation](https://docs.chef.io/).
```
package "Install Apache" do
case node[:platform]
when "redhat", "amazon"
package_name "httpd"
when "ubuntu"
package_name "apache2"
end
end
```
Detaillierte Informationen zur Verwendung der `package`-Ressource zum Verwalten von Paketen finden Sie in der Chef-Dokumentation auf der Seite [Package](https://docs.chef.io/resource_package.html).
Alternativ können Sie die Hilfsmethode `value_for_platform` von der Chef-Rezept-DSL (domänenspezifische Sprache) verwenden, mit der Sie schneller zum gleichen Ergebnis gelangen:
```
package "Install Apache" do
package_name value_for_platform(
["redhat", "amazon"] => { "default" => "httpd" },
["ubuntu"] => { "default" => "apache2" }
)
end
```
Weitere Informationen zur Verwendung der Hilfsmethode `value_for_platform` finden Sie unter [About the Recipe DSL](https://docs.chef.io/dsl_recipe.html).