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.
# Anpassen von Software auf Linux-Servern
In diesem Abschnitt wird beschrieben, welche Art von Informationen Sie in eine Konfigurationsdatei aufnehmen können, um die Software auf Ihren EC2 Linux-Instances anzupassen. Allgemeine Informationen zum Anpassen und Konfigurieren der Elastic Beanstalk-Umgebungen finden Sie unter [Konfigurieren von Elastic-Beanstalk-Umgebungen](customize-containers.md). Informationen zum Anpassen der Software auf Ihren EC2 Instanzen, auf denen Windows ausgeführt wird, finden Sie unter[Anpassen von Software auf Windows-Servern](customize-containers-windows-ec2.md).
Möglicherweise muss die Software, von der Ihre Anwendung abhängig ist, angepasst und konfiguriert werden. Sie können Befehle hinzufügen, die während der Instance-Bereitstellung ausgeführt werden sollen, Linux-Benutzer und -Gruppen definieren und Dateien auf Ihre Umgebungs-Instances herunterladen oder dort direkt erstellen. Bei diesen Dateien kann es sich entweder um von der Anwendung benötigte Abhängigkeiten (z. B. zusätzliche Pakete aus dem yum-Repository) oder um Konfigurationsdateien handeln (wie z. B. ein Ersatz für eine Proxykonfigurationsdatei zum Überschreiben bestimmter Standardeinstellungen von Elastic Beanstalk).
**Hinweise**
Wir empfehlen dringend, auf Amazon Linux 2-Plattformen *Buildfile* zu verwenden, anstatt Dateien und Befehle in .ebextensions-Konfigurationsdateien bereitzustellen. *Procfile* und *Plattform-Hooks* möglichst zum Konfigurieren und Ausführen von benutzerdefiniertem Code auf Ihren Umgebungs-Instances während der Instance-Bereitstellung. Details zu diesen Mechanismen finden Sie unter [Erweitern von Elastic Beanstalk-Linux-Plattformen](platforms-linux-extend.md).
Für YAML sind konsistente Einrückungen erforderlich. Wählen Sie die entsprechende Einrückungsebene aus, wenn Sie Inhalte in einer Beispielkonfigurationsdatei ersetzen, und stellen Sie sicher, dass Ihr Texteditor Leerzeichen statt Tabulatorzeichen zum Einrücken verwendet.
Konfigurationsdateien unterstützen die folgenden Schlüssel, die sich auf die Linux-Server auswirken, auf denen die Anwendung ausgeführt wird.
**Topics**
+ [Pakete](#linux-packages)
+ [Gruppen](#linux-groups)
+ [Benutzer](#linux-users)
+ [Quellen](#linux-sources)
+ [Dateien](#linux-files)
+ [Befehle](#linux-commands)
+ [Dienstleistungen](#linux-services)
+ [Container-Befehle](#linux-container-commands)
+ [Beispiel: Verwendung benutzerdefinierter CloudWatch Amazon-Metriken](customize-containers-cw.md)
Schlüssel werden in der hier aufgeführten Reihenfolge verarbeitet.
Beobachten Sie die [Ereignisse](using-features.events.md) in der Umgebung, während Sie Konfigurationsdateien entwickeln und testen. Elastic Beanstalk ignoriert eine Konfigurationsdatei, die Validierungsfehler enthält, z. B. einen ungültigen Schlüssel, und verarbeitet keinen der in der betreffenden Datei enthaltenen Schlüssel. Wenn dies geschieht, fügt Elastic Beanstalk eine Warnung in das Ereignisprotokoll ein.
## Pakete
Mit dem Schlüssel `packages` können Sie vorgefertigte Anwendungen und Komponenten herunterladen und installieren.
### Syntax
```
packages:
name of package manager:
package name: version
...
name of package manager:
package name: version
...
...
```
Sie können unter jedem Paketmanager-Schlüssel mehrere Pakete angeben.
### Unterstützte Paketformate
Elastic Beanstalk unterstützt derzeit die folgenden Paketmanager: yum, rubygems, python und rpm. Pakete werden in der folgenden Reihenfolge verarbeitet: rpm, yum und dann rubygems und python. Es gibt keine Reihenfolge zwischen rubygems und python. Innerhalb jedes Paketmanagers ist die Reihenfolge der Paketinstallation nicht garantiert. Verwenden Sie einen Paketmanager, der vom Betriebssystem unterstützt wird.
**Anmerkung**
Elastic Beanstalk unterstützt zwei zugrundeliegende Paketmanager für Python, pip und easy\$1install. In der Syntax der Konfigurationsdatei müssen Sie den Namen des Paketmanagers als `python` angeben. Wenn Sie eine Konfigurationsdatei verwenden, um einen Python-Paketmanager anzugeben, verwendet Elastic Beanstalk Python 2.7. Wenn Ihre Anwendung sich auf eine andere Version von Python stützt, können Sie die zu installierenden Pakete in einer `requirements.txt`-Datei angeben. Weitere Informationen finden Sie unter [Angeben von Abhängigkeiten mithilfe einer Anforderungsdatei auf Elastic Beanstalk](python-configuration-requirements.md).
### Angeben von Versionen
Innerhalb jedes Paketmanagers ist jedes Paket als ein Paketname und eine Liste der Versionen angegeben. Die Version kann eine Zeichenfolge, eine Liste von Versionen oder eine leere Zeichenfolge oder Liste sein. Eine leere Zeichenfolge oder Liste gibt an, dass Sie die neueste Version verwenden möchten. Bei RPM-Manager wird die Version als ein Pfad zu einer Datei auf einem Datenträger oder eine URL angegeben. Relative Pfade werden nicht unterstützt.
Wenn Sie eine Version eines Pakets angeben, versucht Elastic Beanstalk, diese Version zu installieren, auch wenn auf der Instance bereits eine neuere Version des Pakets installiert ist. Wenn eine neuere Version bereits installiert ist, schlägt die Bereitstellung fehl. Einige Paketmanager unterstützen mehrere Versionen, andere wiederum nicht. In der Dokumentation zu Ihrem Paketmanager finden Sie weitere Informationen. Wenn Sie keine Version angeben und bereits eine Version des Pakets installiert ist, installiert Elastic Beanstalk keine neue Version. Es wird angenommen, dass Sie die bestehende Version behalten und verwenden möchten.
### Beispielausschnitt
Der folgende Codeausschnitt gibt eine Versions-URL für RPM an, fordert die neueste Version von yum und Version 0.10.2 von chef von rubygems an.
```
packages:
yum:
libmemcached: []
ruby-devel: []
gcc: []
rpm:
epel: http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
rubygems:
chef: '0.10.2'
```
## Gruppen
Sie können den `groups` Schlüssel verwenden, um Linux/UNIX Gruppen zu erstellen und Gruppen zuzuweisen IDs. Um eine Gruppe zu erstellen, fügen Sie ein neues Schlüssel-Wert-Paar hinzu, das einer optionalen Gruppen-ID einen neuen Gruppennamen zuordnet. Der Gruppenschlüssel kann einen oder mehrere Gruppennamen enthalten. In der folgenden Tabelle werden die verfügbaren Schlüssel aufgeführt.
### Syntax
```
groups:
name of group: {}
name of group:
gid: "group id"
```
### Optionen
`gid`
Eine Gruppen-ID-Nummer.
Wenn eine Gruppen-ID angegeben ist und die Gruppe nach Name bereits vorhanden ist, schlägt die Gruppenerstellung fehl. Wenn eine andere Gruppe die angegebene Gruppen-ID aufweist, lehnt das Betriebssystem die Gruppenerstellung möglicherweise ab.
### Beispielausschnitt
Der folgende Codeausschnitt gibt eine Gruppe mit dem Namen groupOne an, ohne eine Gruppen-ID zuzuweisen, und eine Gruppe mit dem Namen groupTwo, die den Gruppen-ID-Wert 45 angegeben hat.
```
groups:
groupOne: {}
groupTwo:
gid: "45"
```
## Benutzer
Sie können den `users` Schlüssel verwenden, um Linux/UNIX Benutzer auf der EC2 Instanz zu erstellen.
### Syntax
```
users:
name of user:
groups:
- name of group
uid: "id of the user"
homeDir: "user's home directory"
```
### Optionen
`uid`
Eine Benutzer-ID. Der Erstellungsprozess ist nicht erfolgreich, wenn der Benutzername mit einer anderen Benutzer-ID vorhanden ist. Wenn die Benutzer-ID bereits einem vorhandenen Benutzer zugewiesen ist, lehnt das Betriebssystem die Erstellungsanforderung möglicherweise ab.
`groups`
Eine Liste von Gruppennamen. Der Benutzer wird jeder Gruppe in der Liste hinzugefügt.
`homeDir`
Das Stammverzeichnis des Benutzers.
Benutzer werden als nicht interaktive Systembenutzer mit der Shell `/sbin/nologin` erstellt. Dies ist beabsichtigt und kann nicht geändert werden.
### Beispielausschnitt
```
users:
myuser:
groups:
- group1
- group2
uid: "50"
homeDir: "/tmp"
```
## Quellen
Sie können den `sources` Schlüssel verwenden, um eine Archivdatei von einer öffentlichen URL herunterzuladen und sie in ein Zielverzeichnis auf der EC2 Instanz zu entpacken.
### Syntax
```
sources:
target directory: location of archive file
```
### Unterstützte Formate
Unterstützte Formate sind tar, tar\$1gzip, tar\$1bz2 und zip. Sie können auf externe Speicherort wie Amazon Simple Storage Service (Amazon S3) verweisen (z. B. `https://amzn-s3-demo-bucket.s3.amazonaws.com/myobject`), sofern die URL öffentlich zugänglich ist.
### Beispielausschnitt
Im folgenden Beispiel wird eine öffentliche ZIP-Datei von einem Amazon S3-Bucket heruntergeladen und in `/etc/myapp` entpackt:
```
sources:
/etc/myapp: https://amzn-s3-demo-bucket.s3.amazonaws.com/myobject
```
**Anmerkung**
Mehrere Extraktionen sollten nicht den gleichen Zielpfad wiederverwenden. Das Extrahieren einer anderen Quelle in denselben Zielpfad ersetzt den Inhalt, statt an den Inhalt angefügt zu werden.
## Dateien
Sie können den `files` Schlüssel verwenden, um Dateien auf der EC2 Instanz zu erstellen. Der Inhalt kann entweder in die Konfigurationsdatei eingebettet sein oder von einer URL abgerufen werden. Die Dateien werden in lexikalischer Reihenfolge auf den Datenträger geschrieben.
Wenn private Dateien mit dem Schlüssel `files` von Amazon S3 heruntergeladen werden sollen, stellen Sie ein Instance-Profil für die Autorisierung bereit.
Wenn der von Ihnen angegebene Dateipfad bereits auf der Instance vorhanden ist, wird die vorhandene Datei beibehalten, wobei die Erweiterung `.bak` an ihren Namen angehängt wird.
### Syntax
```
files:
"target file location on disk":
mode: "six-digit octal value"
owner: name of owning user for file
group: name of owning group for file
source: URL
authentication: authentication name:
"target file location on disk":
mode: "six-digit octal value"
owner: name of owning user for file
group: name of owning group for file
content: |
# this is my
# file content
encoding: encoding format
authentication: authentication name:
```
### Optionen
`content`
Zeichenfolgeninhalt zum Hinzufügen zur Datei. Geben Sie `content` oder `source` an, jedoch nicht beides.
`source`
URL einer Datei zum Herunterladen. Geben Sie `content` oder `source` an, jedoch nicht beides.
`encoding`
Das Codierungsformat der angegebene Zeichenfolge mit der `content`-Option.
Zulässige Werte: `plain` \$1 `base64`
`group`
Linux-Gruppe, der die Datei gehört.
`owner`
Linux-Benutzer, dem die Datei gehört.
`mode`
Ein sechsstelliger Oktalwert, der für den Modus für diese Datei steht. Wird für Windows-Systeme nicht unterstützt. Verwenden Sie die ersten drei Ziffern für Symlinks und die letzten drei Ziffern für das Einrichten von Berechtigungen. Um einen Symlink zu erstellen, geben Sie `120xxx` an, wobei `xxx` die Berechtigungen der Zieldatei definiert. Um Berechtigungen für eine Datei anzugeben, verwenden Sie die letzten drei Ziffern, z. B. `000644`.
`authentication`
Der Name einer [CloudFormation -Authentifizierungsmethode](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-authentication.html), die verwendet werden soll. Mit dem Ressourcenschlüssel können Sie Authentifizierungsmethoden zu den Metadaten der Auto Scaling-Gruppe hinzufügen. Ein Beispiel finden Sie unten.
### Beispielausschnitt
```
files:
"/home/ec2-user/myfile" :
mode: "000755"
owner: root
group: root
source: http://foo.bar/myfile
"/home/ec2-user/myfile2" :
mode: "000755"
owner: root
group: root
content: |
this is my
file content
```
Beispiel mit einem Symlink. Dies erzeugt einen Link `/tmp/myfile2.txt`, der auf die Datei `/tmp/myfile1.txt` verweist.
```
files:
"/tmp/myfile2.txt" :
mode: "120400"
content: "/tmp/myfile1.txt"
```
In dem folgenden Beispiel wird der Ressourcenschlüssel zum Hinzufügen einer Authentifizierungsmethode mit dem Namen S3Auth und zum Herunterladen einer privaten Datei aus einem Amazon S3-Bucket verwendet:
```
Resources:
AWSEBAutoScalingGroup:
Metadata:
AWS::CloudFormation::Authentication:
S3Auth:
type: "s3"
buckets: ["amzn-s3-demo-bucket2"]
roleName:
"Fn::GetOptionSetting":
Namespace: "aws:autoscaling:launchconfiguration"
OptionName: "IamInstanceProfile"
DefaultValue: "aws-elasticbeanstalk-ec2-role"
files:
"/tmp/data.json" :
mode: "000755"
owner: root
group: root
authentication: "S3Auth"
source: https://elasticbeanstalk-us-west-2-123456789012.s3-us-west-2.amazonaws.com/data.json
```
## Befehle
Sie können den `commands` Schlüssel verwenden, um Befehle auf der EC2 Instanz auszuführen. Die Befehle werden ausgeführt, bevor die Anwendung und der Webserver eingerichtet sind und die Anwendungsversionsdatei extrahiert wird.
Die angegebenen Befehle werden als Root-Benutzer ausgeführt und in alphabetischer Reihenfolge dem Namen nach verarbeitet. Befehle werden standardmäßig im Stammverzeichnis ausgeführt. Um die Befehle aus einem anderen Verzeichnis auszuführen, verwenden Sie die `cwd`-Option.
Um Probleme mit Befehlen zu beheben, schlagen Sie deren Ausgabe in den [Instance-Protokollen](using-features.logging.md) nach.
### Syntax
```
commands:
command name:
command: command to run
cwd: working directory
env:
variable name: variable value
test: conditions for command
ignoreErrors: true
```
### Optionen
`command`
Ein Array ([Blocksequenzsammlung](http://yaml.org/spec/1.2/spec.html#id2759963) in YAML-Syntax) oder eine Zeichenfolge, das bzw. die den auszuführenden Befehl angibt. Einige wichtige Hinweise:
+ Wenn Sie eine Zeichenfolge verwenden, müssen Sie die Zeichenfolge nicht in Anführungszeichen einschließen. Wenn Sie Anführungszeichen verwenden, muss literal verwendeten Anführungszeichen desselben Typs ein Escape-Zeichen vorangestellt werden.
+ Wenn Sie ein Array verwenden, müssen Sie Leerzeichen kein Escape-Zeichen voranstellen und Befehlsparameter nicht in Anführungszeichen angeben. Jedes Arrayelement ist ein einzelnes Befehlsargument. Verwenden Sie ein Array nicht, um mehrere Befehle anzugeben.
Die folgenden Beispiele sind gleichwertig:
```
commands:
command1:
command: git commit -m "This is a comment."
command2:
command: "git commit -m \"This is a comment.\""
command3:
command: 'git commit -m "This is a comment."'
command4:
command:
- git
- commit
- -m
- This is a comment.
```
Wenn Sie mehrere Befehle angeben, verwenden Sie ein [literales Blockskalar](http://yaml.org/spec/1.2/spec.html#id2760844), wie im folgenden Beispiel gezeigt.
```
commands:
command block:
command: |
git commit -m "This is a comment."
git push
```
`env`
(Optional) Legt Umgebungsvariablen für den Befehl fest. Diese Eigenschaft überschreibt die vorhandene Umgebung, anstatt sie anzuhängen.
`cwd`
(Optional) Das Arbeitsverzeichnis. Sofern nicht definiert, werden Befehle aus dem Stammverzeichnis (/) ausgeführt.
`test`
(Optional) Ein Befehl, der den Wert `true` (Beendigungscode 0) zurückgeben muss, damit Elastic Beanstalk den im Schlüssel `command` enthaltenen Befehl, wie ein Shell-Skript, verarbeitet.
`ignoreErrors`
(Optional) Ein boolescher Wert, der bestimmt, ob andere Befehle ausgeführt werden sollen, wenn der im Schlüssel `command` enthaltene Befehl fehlschlägt (gibt einen Wert ungleich null zurück). Legen Sie diesen Wert auf `true` fest, damit weiterhin Befehle ausgeführt werden, selbst wenn der Befehl fehlschlägt. Legen Sie den Wert auf `false` fest, um anzugeben, dass keine Befehle mehr ausgeführt werden sollen, wenn der Befehl fehlschlägt. Der Standardwert ist `false`.
### Beispielausschnitt
Der folgende Beispielausschnitt führt ein Python-Skript aus.
```
commands:
python_install:
command: myscript.py
cwd: /home/ec2-user
env:
myvarname: myvarvalue
test: "[ -x /usr/bin/python ]"
```
## Dienstleistungen
Mit dem Schlüssel `services` definieren Sie, welche Services beim Start der Instance gestartet oder gestoppt werden sollen. Zudem lassen sich mit dem Schlüssel `services` auch Abhängigkeiten von Quellen, Paketen und Dateien angeben, sodass Elastic Beanstalk im Falle eines Neustarts aufgrund von installierten Dateien den Service neu startet.
### Syntax
```
services:
sysvinit:
name of service:
enabled: "true"
ensureRunning: "true"
files:
- "file name"
sources:
- "directory"
packages:
name of package manager:
"package name[: version]"
commands:
- "name of command"
```
### Optionen
`ensureRunning`
Legen Sie den Wert auf `true` fest, um sicherzustellen, dass der Service ausgeführt wird, nachdem Elastic Beanstalk abgeschlossen wurde.
Legen Sie den Wert auf `false` fest, um sicherzustellen, dass der Service nicht ausgeführt wird, nachdem Elastic Beanstalk abgeschlossen wurde.
Lassen Sie diesen Schlüssel aus, um keine Änderungen am Servicestatus vorzunehmen.
`enabled`
Legen Sie den Wert auf `true` fest, um sicherzustellen, dass der Service beim Systemstart automatisch gestartet wird.
Legen Sie den Wert auf `false` fest, um sicherzustellen, dass der Service beim Systemstart nicht automatisch gestartet wird.
Lassen Sie diesen Schlüssel aus, um keine Änderungen an dieser Eigenschaft vorzunehmen.
`files`
Eine Liste von Dateien. Wenn Elastic Beanstalk eine Datei direkt über den Dateienblock ändert, wird der Service neu gestartet.
`sources`
Eine Liste von Verzeichnissen. Wenn Elastic Beanstalk ein Archiv in eines dieser Verzeichnisse erweitert, wird der Service neu gestartet.
`packages`
Eine Zuordnung des Paket-Managers zu einer Liste von Paketnamen. Wenn Elastic Beanstalk eines dieser Pakete installiert oder aktualisiert, wird der Service neu gestartet.
`commands`
Eine Liste von Befehlsnamen. Wenn Elastic Beanstalk den angegebenen Befehl ausführt, wird der Service neu gestartet.
### Beispielausschnitt
Es folgt ein Beispiel für einen Ausschnitt:
```
services:
sysvinit:
myservice:
enabled: true
ensureRunning: true
```
## Container-Befehle
Mit dem Schlüssel `container_commands` können Sie Befehle ausführen, die sich auf den Anwendungsquellcode auswirken. Container-Befehle werden ausgeführt, nachdem die Anwendung und der Webserver eingerichtet sind und die Anwendungsversionsdatei extrahiert wurde, aber bevor die Anwendungsversion bereitgestellt wird. Nicht-Container-Befehle und andere Anpassungen werden vor der Extraktion des Anwendungsquellcodes ausgeführt.
Die angegebenen Befehle werden als Root-Benutzer ausgeführt und in alphabetischer Reihenfolge dem Namen nach verarbeitet. Container-Befehle werden aus dem Staging-Verzeichnis ausgeführt, aus dem der Quellcode vor der Bereitstellung auf dem Anwendungsserver extrahiert wird. Alle Änderungen, die Sie mithilfe eines Container-Befehls am Quellcode im Staging-Verzeichnis vornehmen, werden bei der Bereitstellung der Quelle am endgültigen Speicherort einbezogen.
**Anmerkung**
Die Ausgabe Ihrer Container-Befehle wird im `cfn-init-cmd.log`-Instance-Protokoll protokolliert. Weitere Informationen zum Abrufen und Anzeigen von Instance-Logs finden Sie unter [Logs von EC2 Amazon-Instances anzeigen](using-features.logging.md).
Verwenden Sie den Befehl `leader_only`, wenn der Befehl nur auf einer einzelnen Instance ausgeführt werden soll, oder konfigurieren Sie `test` so, dass der Befehl nur ausgeführt wird, sofern der Testbefehl den Wert `true` ergibt. Die Ausführung von Container-Befehlen des Leader-only-Typs erfolgt nur während der Umgebungserstellung und -bereitstellung, wohingegen andere Befehle und Serveranpassungen bei jeder Instance-Bereitstellung oder -Aktualisierung ausgeführt werden. Container-Befehle des Leader-only-Typs werden bei Startkonfigurationsänderungen nicht ausgeführt, so z. B. eine Änderung der AMI-ID oder des Instance-Typs.
### Syntax
```
container_commands:
name of container_command:
command: "command to run"
leader_only: true
name of container_command:
command: "command to run"
```
### Optionen
`command`
Eine auszuführende Zeichenfolge bzw. ein Array von Zeichenfolgen.
`env`
(Optional) Legen Sie Umgebungsvariablen vor der Befehlsausführung fest, um alle vorhandenen Werte zu überschreiben.
`cwd`
(Optional) Das Arbeitsverzeichnis. Standardmäßig ist dies das Staging-Verzeichnis der nicht komprimierten Anwendung.
`leader_only`
(Optional) Führen Sie den Befehl nur auf einer einzelnen, von Elastic Beanstalk ausgewählten Instance aus. Container-Befehle des Leader-only-Typs werden vor anderen Container-Befehlen ausgeführt. Ein Befehl kann vom Typ Leader-only oder `test` sein, aber nicht beides (`leader_only` hat Vorrang).
`test`
(Optional) Führen Sie einen Testbefehl aus, der `true` zurückgeben muss, damit der Container-Befehl ausgeführt wird. Ein Befehl kann vom Typ Leader-only oder `test` sein, aber nicht beides (`leader_only` hat Vorrang).
`ignoreErrors`
(Optional) Bereitstellungen schlagen nicht fehl, sofern der Container-Befehl einen anderen Wert als 0 (Erfolg) zurückgibt. Legen Sie den Wert auf `true` fest, um dies zu aktivieren.
### Beispielausschnitt
Es folgt ein Beispiel für einen Ausschnitt.
```
container_commands:
collectstatic:
command: "django-admin.py collectstatic --noinput"
01syncdb:
command: "django-admin.py syncdb --noinput"
leader_only: true
02migrate:
command: "django-admin.py migrate"
leader_only: true
99customize:
command: "scripts/customize.sh"
```