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 Windows-Servern
Möglicherweise muss die Software, von der Ihre Anwendung abhängig ist, angepasst und konfiguriert werden. Bei diesen Dateien kann es sich um von der Anwendung benötigte Abhängigkeiten handeln, z. B. zusätzliche Pakete oder Services, die ausgeführt werden müssen. Allgemeine Informationen zum Anpassen und Konfigurieren der Elastic Beanstalk-Umgebungen finden Sie unter [Konfigurieren von Elastic-Beanstalk-Umgebungen](customize-containers.md).
**Anmerkung**
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 Windows-Server auswirken, auf denen die Anwendung ausgeführt wird.
**Topics**
+ [Pakete](#windows-packages)
+ [Quellen](#windows-sources)
+ [Dateien](#windows-files)
+ [Befehle](#windows-commands)
+ [Dienstleistungen](#windows-services)
+ [Container-Befehle](#windows-container-commands)
Schlüssel werden in der hier aufgeführten Reihenfolge verarbeitet.
**Anmerkung**
Ältere Versionen (ohne Versionsangabe) von .NET-Plattformversionen können die Konfigurationsdateien nicht in der richtigen Reihenfolge verarbeiten. Weitere Informationen finden Sie unter [Migration über die Hauptversionen der Elastic Beanstalk-Windows Server-Plattform hinweg](dotnet-v2migration.md).
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.
In Windows-Umgebungen unterstützt Elastic Beanstalk das Herunterladen und Installieren von MSI-Paketen. (Linux-Umgebungen unterstützen zusätzliche Paketmanager. Details dazu finden Sie unter [Pakete](customize-containers-ec2.md#linux-packages) auf der Seite *Anpassen von Software auf Linux-Servern*.)
Sie können auf einen beliebigen externen Speicherort verweisen, z. B. ein Amazon Simple Storage Service (Amazon S3)-Objekt, sofern die URL öffentlich zugänglich ist.
Wenn Sie mehrere `msi:` Pakete angeben, wird deren Installationsreihenfolge nicht garantiert.
### Syntax
Geben Sie einen Namen Ihrer Wahl als Paketnamen an, und eine URL zu einem MSI-Dateispeicherort als den Wert. Sie können mehrere Pakete unter dem `msi:`-Schlüssel angeben.
```
packages:
msi:
{{package name}}: {{package url}}
...
```
### Beispiele
Im folgenden Beispiel wird eine URL zum Herunterladen von **mysql** von `https://dev.mysql.com/` angegeben.
```
packages:
msi:
mysql: https://dev.mysql.com/get/Downloads/Connector-Net/mysql-connector-net-8.0.11.msi
```
Im folgenden Beispiel wird ein Amazon S3-Objekt als MSI-Dateispeicherort angegeben.
```
packages:
msi:
mymsi: https://{{amzn-s3-demo-bucket}}.s3.amazonaws.com/{{myobject}}.msi
```
## Quellen
Mit dem Schlüssel `sources` können Sie eine Archivdatei über eine öffentliche URL herunterladen und diese auf der EC2-Instance in einem Zielverzeichnis entpacken.
### Syntax
```
sources:
{{target directory}}: {{location of archive file}}
```
### Unterstützte Formate
In Windows-Umgebungen unterstützt Elastic Beanstalk das ZIP-Format. (Linux-Umgebungen unterstützen zusätzliche Formate. Details dazu finden Sie unter [Quellen](customize-containers-ec2.md#linux-sources) auf der Seite *Anpassen von Software auf Linux-Servern*.)
Sie können auf einen beliebigen externen Speicherort verweisen, z. B. ein Amazon Simple Storage Service (Amazon S3)-Objekt, sofern die URL öffentlich zugänglich ist.
### Beispiel
Das folgende Beispiel lädt eine öffentliche .zip-Datei von einem Amazon S3 herunter und entpackt sie in. `c:/myproject/myapp`
```
sources:
"c:/myproject/myapp": https://{{amzn-s3-demo-bucket}}.s3.amazonaws.com/{{myobject}}.zip
```
## Dateien
Mit dem Schlüssel `files` können Sie Dateien auf der EC2-Instance erstellen. Die Inhalte können entweder in der Konfigurationsdatei enthalten sein oder über eine URL abgerufen werden. Die Dateien werden in lexikalischer Reihenfolge auf den Datenträger geschrieben. Wenn private Dateien von Amazon S3 heruntergeladen werden sollen, stellen Sie ein Instance-Profil für die Autorisierung bereit.
### Syntax
```
files:
"{{target file location on disk}}":
source: {{URL}}
authentication: {{authentication name}}:
"{{target file location on disk}}":
content: |
{{this is my content}}
encoding: {{encoding format}}
```
### Optionen
`content`
(Optional) Eine Zeichenfolge.
`source`
(Optional) Die URL, über die diese Datei geladen wird. Diese Option kann nicht mit dem Inhaltsschlüssel angegeben werden.
`encoding`
(Optional) Das Codierungsformat. Diese Option wird nur für einen bereitgestellten Inhaltsschlüsselwert verwendet. Der Standardwert ist `plain`.
Zulässige Werte: `plain` \| `base64`
`authentication`
(Optional) Der Name der zu verwendenden [CloudFormation -Authentifizierungsmethode](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-authentication.html). Mit dem Ressourcenschlüssel können Sie Authentifizierungsmethoden zu den Metadaten der Auto Scaling-Gruppe hinzufügen.
### Beispiele
Das folgende Beispiel zeigt die beiden Möglichkeiten, Dateiinhalt bereitzustellen: von einer URL oder inline in der Konfigurationsdatei.
```
files:
"{{c:\\targetdirectory\\targetfile.txt}}":
source: {{http://foo.bar/myfile}}
"{{c:/targetdirectory/targetfile.txt}}":
content: |
{{# this is my file}}
{{# with content}}
```
**Anmerkung**
Falls im Dateipfad ein Backslash (\\) verwendet wird, muss diesem – wie im vorigen Beispiel – ein weiterer Backslash (das Escape-Zeichen) vorangestellt werden.
Das folgende Beispiel verwendet den Resources-Schlüssel, um eine Authentifizierungsmethode namens S3Auth hinzuzufügen und verwendet ihn, um eine private Datei von einem Amazon S3 herunterzuladen:
```
files:
"c:\\targetdirectory\\targetfile.zip":
source: {{https://elasticbeanstalk-us-east-2-123456789012.s3.amazonaws.com/prefix/myfile.zip}}
authentication: {{S3Auth}}
Resources:
AWSEBAutoScalingGroup:
Metadata:
AWS::CloudFormation::Authentication:
{{S3Auth}}:
type: "s3"
s: ["{{amzn-s3-demo-bucket}}"]
roleName:
"Fn::GetOptionSetting":
Namespace: "aws:autoscaling:launchconfiguration"
OptionName: "IamInstanceProfile"
DefaultValue: "aws-elasticbeanstalk-ec2-role"
```
## Befehle
Mit dem Schlüssel `commands` können Sie Befehle auf der EC2-Instance ausführen. Die Befehle werden in alphabetischer Reihenfolge nach Name verarbeitet und ausgeführt, bevor die Anwendung und der Webserver eingerichtet sind und die Anwendungsversionsdatei extrahiert wird.
Die angegebenen Befehle werden als Administrator-Benutzer ausgeführt.
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}}
```
### Optionen
`command`
Entweder ein Array oder eine Zeichenfolge, das bzw. die den auszuführenden Befehl angibt. Wenn Sie ein Array verwenden, müssen Sie Leerzeichen kein Escape-Zeichen voranstellen und Befehlsparameter nicht in Anführungszeichen angeben.
`cwd`
(Optional) Das Arbeitsverzeichnis. Standardmäßig sucht Elastic Beanstalk nach dem Verzeichnispfad des Projekts. Falls dieser nicht gefunden wird, gilt `c:\Windows\System32` als Standardwert.
`env`
(Optional) Legt Umgebungsvariablen für den Befehl fest. Diese Eigenschaft überschreibt die vorhandene Umgebung, anstatt sie anzuhängen.
`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`.
`test`
(Optional) Ein Befehl, der den Wert `true` (Beendigungscode 0) zurückgeben muss, damit Elastic Beanstalk den im Schlüssel `command` enthaltenen Befehl verarbeitet.
`waitAfterCompletion`
(Optional) Wartezeit in Sekunden, nachdem ein Befehl abgeschlossen ist, bevor der nächste Befehl ausgeführt wird. Die Standard-Wert ist **60** Sekunden. Sie können auch angeben. **forever**
Systemneustarts während der Bereitstellung werden nicht unterstützt. Wenn das System aufgrund eines Befehls neu gestartet wird, schlägt die Instanzinitialisierung fehl, sodass die Bereitstellung fehlschlägt.
Um das Problem zu umgehen, können Sie [https://github.com/awsdocs/elastic-beanstalk-samples/tree/main/configuration-files/aws-provided/instance-configuration/windows-configuration/scheduled-restart.config](https://github.com/awsdocs/elastic-beanstalk-samples/tree/main/configuration-files/aws-provided/instance-configuration/windows-configuration/scheduled-restart.config)damit Neustarts nach Abschluss der Bereitstellung planen.
### Beispiel
Im folgenden Beispiel wird die Ausgabe des Befehls `set` in der angegebenen Datei gespeichert. Wenn ein weiterer Befehl vorhanden ist, führt Elastic Beanstalk diesen unverzüglich nach Abschluss dieses Befehls aus. Falls dieser Befehl einen Neustart erforderlich macht, startet Elastic Beanstalk die Instance direkt nach Abschluss des Befehls neu.
```
commands:
test:
command: set > {{c:\\myapp\\set.txt}}
waitAfterCompletion: {{0}}
```
## 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:
windows:
{{name of service}}:
files:
- "{{file name}}"
sources:
- "{{directory}}"
packages:
{{name of package manager}}:
"{{package name}}[: {{version}}]"
commands:
- "{{name of command}}"
```
### Optionen
`ensureRunning`
(Optional) 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`
(Optional) 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.
### Beispiel
```
services:
windows:
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.
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.
Um Probleme mit Container-Befehlen zu beheben, schlagen Sie deren Ausgabe in den [Instance-Protokollen](using-features.logging.md) nach.
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}}
```
### 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.
`waitAfterCompletion`
(Optional) Wartezeit in Sekunden, nachdem ein Befehl abgeschlossen ist, bevor der nächste Befehl ausgeführt wird. Die Standard-Wert ist **60** Sekunden. Sie können auch angeben. **forever**
Systemneustarts während der Bereitstellung werden nicht unterstützt. Wenn das System aufgrund eines Befehls neu gestartet wird, schlägt die Instanzinitialisierung fehl, sodass die Bereitstellung fehlschlägt.
Um das Problem zu umgehen, können Sie [https://github.com/awsdocs/elastic-beanstalk-samples/tree/main/configuration-files/aws-provided/instance-configuration/windows-configuration/scheduled-restart.config](https://github.com/awsdocs/elastic-beanstalk-samples/tree/main/configuration-files/aws-provided/instance-configuration/windows-configuration/scheduled-restart.config)damit Neustarts nach Abschluss der Bereitstellung planen.
### Beispiel
Im folgenden Beispiel wird die Ausgabe des Befehls `set` in der angegebenen Datei gespeichert. Elastic Beanstalk führt den Befehl auf einer Instance aus und startet diese direkt nach Abschluss des Befehls neu.
```
container_commands:
foo:
command: set > {{c:\\myapp\\set.txt}}
leader_only: true
waitAfterCompletion: {{0}}
```