

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.

# Konfiguration von Elastic Beanstalk Docker-Umgebungen
<a name="create_deploy_docker.container.console"></a>

In diesem Kapitel werden zusätzliche Konfigurationsinformationen für alle unterstützten Docker-Plattformzweige erläutert, einschließlich des von ECS verwalteten Docker-Plattformzweigs. Sofern in einem Abschnitt kein bestimmter Plattformzweig oder eine Komponente für Plattformzweige angegeben ist, gilt dies für alle Umgebungen, in denen unterstützte Docker- und ECS-verwaltete Docker-Plattformen ausgeführt werden. 

**Anmerkung**  
Wenn Ihre Elastic Beanstalk-Umgebung eine Amazon Linux AMI Docker-Plattformversion verwendet (Vorgängerversion von Amazon Linux 2), lesen Sie unbedingt die zusätzlichen Informationen unter [Docker-Konfiguration auf Amazon Linux AMI (Vorgängerversion von Amazon Linux 2)](#docker-alami).

**Topics**
+ [Konfigurieren von Software in Docker-Umgebungen](#docker-software-config)
+ [Verweisen auf Umgebungsvariablen in Containern](#docker-env-cfg.env-variables)
+ [Verwenden der Interpolationsfunktion für Umgebungsvariablen mit Docker Compose](#docker-env-cfg.env-variables-dc-interpolate)
+ [Generieren von Protokollen für verbesserte Gesundheitsberichte mit Docker Compose](#docker-env-cfg.healthd-logging)
+ [Benutzerdefinierte Protokollierung für Docker-Container mit Docker Compose](#docker-env-cfg.dc-customized-logging)
+ [Docker-Images](#docker-images)
+ [Konfigurieren von verwalteten Aktualisierungen für Docker-Umgebungen](#docker-managed-updates)
+ [Docker-Konfigurations-Namespaces](#docker-namespaces)
+ [Docker-Konfiguration auf Amazon Linux AMI (Vorgängerversion von Amazon Linux 2)](#docker-alami)

## Konfigurieren von Software in Docker-Umgebungen
<a name="docker-software-config"></a>

Sie können die Elastic Beanstalk-Konsole zum Konfigurieren der Software verwenden, die in den Instances der Umgebung ausgeführt wird.

**So konfigurieren Sie Ihre Docker-Umgebung in der Elastic Beanstalk-Konsole**

1. Öffnen Sie die [Elastic Beanstalk Beanstalk-Konsole](https://console.aws.amazon.com/elasticbeanstalk) und wählen Sie in der Liste **Regionen** Ihre aus. AWS-Region

1. Wählen Sie im Navigationsbereich **Environments (Umgebungen)** aus und wählen Sie dann in der Liste den Namen Ihrer Umgebung aus.

1. Wählen Sie im Navigationsbereich **Configuration (Konfiguration)** aus.

1. Wählen Sie in der Konfigurationskategorie **Updates, monitoring and logging ** (Updates, Überwachung und Protokolle) die Option **Edit** (Bearbeiten) aus.

1. Nehmen Sie die notwendigen Konfigurationsänderungen vor.

1. Wählen Sie unten auf der Seite die Option **Apply** (Anwenden) aus, um die Änderungen zu speichern.

Hinweise zum Konfigurieren von Software-Einstellungen in einer beliebigen Umgebung finden Sie unter [Umgebungsvariablen und andere Softwareeinstellungen](environments-cfg-softwaresettings.md). Die folgenden Abschnitte behandeln Docker-spezifische Informationen.

### Containeroptionen
<a name="docker-software-config.container"></a>

Der Abschnitt **Container options (Containeroptionen)** enthält plattformspezifische Optionen. Für Docker-Umgebungen können Sie auswählen, ob Ihre Umgebung den NGINX-Proxy-Server enthält.

**Umgebungen mit Docker Compose**  
Wenn Sie Ihre Docker-Umgebung mit Docker Compose verwalten, geht Elastic Beanstalk davon aus, dass Sie einen Proxy-Server als Container ausführen. Daher wird die Einstellung **Proxy-Server** standardmäßig auf **Keine** festgelegt und von Elastic Beanstalk wird keine NGINX-Konfiguration bereitgestellt.

**Anmerkung**  
Selbst wenn Sie **NGINX** als Proxy-Server auswählen, wird diese Einstellung in einer Umgebung mit Docker Compose ignoriert. Die Einstellung **Proxy-Server** wird trotzdem standardmäßig auf **Keine** festgelegt. 

Da der NGINX-Webserver-Proxy für die Amazon Linux 2-basierte Docker-Plattform mit Docker Compose deaktiviert ist, müssen Sie die Schritte zum Generieren von Protokollen für erweiterte Zustandsberichte ausführen. Weitere Informationen finden Sie unter [Generieren von Protokollen für verbesserte Gesundheitsberichte mit Docker Compose](#docker-env-cfg.healthd-logging).

### Umgebungseigenschaften (Umgebungsvariablen)
<a name="docker-software-config.env"></a>

Sie können Umgebungseigenschaften (auch als Umgebungsvariablen bezeichnet) verwenden, um Werte wie Endpunkte, Debug-Einstellungen und andere Informationen an Ihre Anwendung zu übergeben. Im Bereich **Umgebungsvariablen** der Konsole können Sie Umgebungsvariablen für die EC2-Instances angeben, auf denen Ihre Anwendung ausgeführt wird. Umgebungsvariablen werden als Schlüssel-Wert-Paare an die Anwendung übergeben.

Ihr Anwendungscode, der in einem Container ausgeführt wird, kann nach Namen auf eine Umgebungsvariable verweisen und dessen Wert lesen. Der Quellcode, der diese Umgebungsvariablen liest, variiert je nach Programmiersprache. Anweisungen zum Lesen von Werten der Umgebungsvariablen in den Programmiersprachen, die von Elastic Beanstalk verwaltete Plattformen unterstützen, finden Sie im jeweiligen Plattformthema. Eine Liste der Links zu diesen Themen finden Sie unter [Umgebungsvariablen und andere Softwareeinstellungen](environments-cfg-softwaresettings.md).

**Geheimnisse und Parameter in Elastic Beanstalk Beanstalk-Umgebungsvariablen**  
Elastic Beanstalk bietet die Möglichkeit, Daten in Umgebungsvariablen zu referenzieren AWS Secrets Manager und AWS Systems Manager Parameter zu speichern. Dies ist eine sichere Option für Ihre Anwendung, um nativ auf Geheimnisse und Parameter zuzugreifen, die von diesen Diensten gespeichert werden, ohne API-Aufrufe an sie verwalten zu müssen. Ihre Elastic Beanstalk Docker- und ECS-verwalteten Docker-Plattformen müssen eine Version sein, die am oder nach dem [26. März 2025 veröffentlicht wurde, um diese Funktion zu unterstützen](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2025-03-26-windows.html). Weitere Hinweise zur Verwendung von Umgebungsvariablen zur Referenzierung von Geheimnissen finden Sie unter. [Abrufen von Geheimnissen und Parametern für Elastic Beanstalk Beanstalk-Umgebungsvariablen](AWSHowTo.secrets.env-vars.md)

**Umgebungen mit Docker Compose**  
Wenn Sie Ihre Docker-Umgebung mit Docker Compose verwalten, sind einige zusätzliche Konfigurationsschritte erforderlich, um die Umgebungsvariablen in den Containern abzurufen. Damit die ausführbaren Dateien, die in Ihrem Container ausgeführt werden, auf diese Umgebungsvariablen zugreifen können, muss in der `docker-compose.yml` auf sie verwiesen werde. Weitere Informationen finden Sie unter [Verweisen auf Umgebungsvariablen in Containern](#docker-env-cfg.env-variables). 

## Verweisen auf Umgebungsvariablen in Containern
<a name="docker-env-cfg.env-variables"></a>

Wenn Sie das Docker Compose-Tool auf der Amazon Linux 2-Docker-Plattform verwenden, wird von Elastic Beanstalk im Stammverzeichnis Ihres Anwendungsprojekts eine Docker Compose-Umgebungsdatei mit der Bezeichnung `.env` generiert. In dieser Datei werden die für Elastic Beanstalk konfigurierten Umgebungsvariablen gespeichert.

**Anmerkung**  
 Wenn Sie eine `.env`-Datei in Ihr Anwendungspaket aufnehmen, wird von Elastic Beanstalk keine `.env`-Datei generiert. 

Damit ein Container auf die in Elastic Beanstalk definierten Umgebungsvariablen verweisen kann, muss mindestens einer der folgenden Konfigurationsansätze verwendet werden.
+ Fügen Sie die von Elastic Beanstalk generierte `.env`-Datei zur Konfigurationsoption `env_file` in der `docker-compose.yml`-Datei hinzu.
+ Definieren Sie die Umgebungsvariablen direkt in der `docker-compose.yml`-Datei.

Im Anschluss finden Sie entsprechende Beispieldateien. Die `docker-compose.yml`-Beispieldatei veranschaulicht beide Ansätze. 
+ Wenn Sie die Umgebungseigenschaften `DEBUG_LEVEL=1` und `LOG_LEVEL=error` definieren, erstellt Elastic Beanstalk die folgende `.env`-Datei für Sie:

  ```
  DEBUG_LEVEL=1
  LOG_LEVEL=error
  ```
+ In dieser `docker-compose.yml`-Datei verweist die Konfigurationsoption `env_file` auf die `.env`-Datei. Außerdem wird die Umgebungsvariable `DEBUG=1` direkt in der `docker-compose.yml`-Datei definiert.

  ```
  services:
    web:
      build: .
      environment:
        - DEBUG=1
      env_file:
        - .env
  ```

**Hinweise**  
Wenn Sie die gleiche Umgebungsvariable in beiden Dateien festlegen, hat die in der `docker-compose.yml`-Datei definierte Variable Vorrang vor der Variablen in der `.env`-Datei.
Achten Sie darauf, dass sich zwischen dem Gleichheitszeichen (=) und dem zugewiesenen Wert Ihrer Variablen keine Leerzeichen befinden. Andernfalls werden der Zeichenfolge Leerzeichen hinzugefügt.

Weitere Informationen zu Umgebungsvariablen in Docker Compose finden Sie unter [Environment variables in Compose](https://docs.docker.com/compose/environment-variables/). 

## Verwenden der Interpolationsfunktion für Umgebungsvariablen mit Docker Compose
<a name="docker-env-cfg.env-variables-dc-interpolate"></a>

Ab der Plattformversion vom [28. Juli 2023](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2023-07-28-al2.html) bietet der Plattformzweig von *Docker Amazon Linux 2* das *Docker-Compose-Interpolations-Feature*. Mit diesem Feature können Werte in einer Compose-Datei durch Variablen festgelegt und zur Laufzeit interpoliert werden. Weitere Informationen über dieses Feature finden Sie unter [Interpolation](https://docs.docker.com/compose/compose-file/12-interpolation/) auf der Docker-Dokumentationswebsite.

**Wichtig**  
Wenn Sie dieses Feature mit Ihren Anwendungen verwenden möchten, beachten Sie, dass Sie einen Ansatz implementieren müssen, der Plattform-Hooks verwendet.  
Dies ist aufgrund einer Maßnahme erforderlich, die wir in der Plattform-Engine implementiert haben. Diese Maßnahme stellt die Abwärtskompatibilität für Kunden sicher, die das neue Interpolations-Feature nicht kennen und bestehende Anwendungen haben, die Umgebungsvariablen mit dem Zeichen `$` verwenden. Die aktualisierte Plattform-Engine umgeht die Interpolation standardmäßig, indem sie das `$` Zeichen durch `$$` Zeichen ersetzt.

Im Folgenden finden Sie ein Beispiel für ein Plattform-Hook-Skript, das Sie einrichten können, um die Verwendung des Interpolations-Features zu ermöglichen.

```
#!/bin/bash

: '
example data format in .env file
key1=value1
key2=value2
'
envfile="/var/app/staging/.env"
tempfile=$(mktemp)

while IFS= read -r line; do
  # split each env var string at '='
  split_str=(${line//=/ })
  if [ ${#split_str[@]} -eq 2 ]; then
    # replace '$$' with '$'
    replaced_str=${split_str[1]//\$\$/\$}
    # update the value of env var using ${replaced_str}
    line="${split_str[0]}=${replaced_str}"
  fi
  # append the updated env var to the tempfile
  echo "${line}" ≫"${tempfile}"
done < "${envfile}"
# replace the original .env file with the tempfile
mv "${tempfile}" "${envfile}"
```

Platzieren Sie die Plattform-Hooks unter diesen beiden Verzeichnissen:
+ `.platform/confighooks/predeploy/`
+ `.platform/hooks/predeploy/`

Weitere Informationen finden Sie unter [Plattform-Hooks](platforms-linux-extend.hooks.md) im Thema *Erweiterung von Linux-Plattformen* in diesem Handbuch.

## Generieren von Protokollen für verbesserte Gesundheitsberichte mit Docker Compose
<a name="docker-env-cfg.healthd-logging"></a>

 Der [Elastic-Beanstalk-Zustandsagent](health-enhanced.md#health-enhanced-agent) stellt Betriebssystem- und Anwendungszustandsmetriken für Elastic-Beanstalk-Umgebungen bereit. Es nutzt Webserver-Protokollformate, die Informationen in einem bestimmten Format weiterleiten.

Elastic Beanstalk nimmt an, dass Sie einen Webserver-Proxy als Container ausführen. Daher ist der NGINX-Webserver-Proxy für Docker-Umgebungen deaktiviert, in denen Docker Compose ausgeführt wird. Sie müssen Ihren Server so konfigurieren, dass Protokolle an den vom Elastic Beanstalk-Zustandsagenten verwendeten Speicherort und im entsprechenden Format geschrieben werden. Dies ermöglicht die uneingeschränkte Nutzung der erweiterten Zustandsberichte, auch wenn der Webserver-Proxy deaktiviert ist.

Anweisungen dazu finden Sie unter [Konfiguration von Webserver-Protokollen](health-enhanced-serverlogs.md#health-enhanced-serverlogs.configure) 

## Benutzerdefinierte Protokollierung für Docker-Container mit Docker Compose
<a name="docker-env-cfg.dc-customized-logging"></a>

Zur effizienten Behandlung von Problemen sowie zur effizienten Überwachung Ihrer containerisierten Services können Sie von Elastic Beanstalk über die Umgebungsverwaltungskonsole oder über die EB CLI [Instance-Protokolle anfordern](using-features.logging.md). Instance-Protokolle umfassen kombinierte und verpackte Bundle-Protokolle und Protokollfragmente, um eine effiziente und unkomplizierte Betrachtung von Protokollen und aktuellen Ereignissen zu ermöglichen.

 Für jeden in der `docker-compose.yml`-Datei definierten Service wird von Elastic Beanstalk unter `/var/log/eb-docker/containers/<service name>` in der Container-Instance ein Protokollverzeichnis erstellt. Wenn Sie das Docker Compose-Feature auf der Amazon Linux 2-Docker-Plattform verwenden, können Sie diese Verzeichnisse an dem Speicherort innerhalb der Containerdateistruktur mounten, an dem Protokolle geschrieben werden. Wenn Sie Protokollverzeichnisse zum Schreiben von Protokolldaten mounten, kann Elastic Beanstalk Protokolldaten aus diesen Verzeichnissen erfassen.

**Um die Protokolldateien Ihres Dienstes so zu konfigurieren, dass sie abrufbare Tail-Dateien und Bundle-Logs sind**

1. Bearbeiten Sie die `docker-compose.yml`-Datei.

1. Fügen Sie unter dem Schlüssel `volumes` für Ihren Service ein Bind-Mount hinzu:

    ` "${EB_LOG_BASE_DIR}/<service name>:<log directory inside container> ` 

   In der folgenden `docker-compose.yml`-Beispieldatei gilt Folgendes:
   +  `nginx-proxy` ist *<service name>* 
   +  `/var/log/nginx` ist *<log directory inside container>* 

   ```
   services:
     nginx-proxy:
       image: "nginx"
       volumes:
         - "${EB_LOG_BASE_DIR}/nginx-proxy:/var/log/nginx"
   ```


+  Das Verzeichnis `var/log/nginx` enthält die Protokolle für den Dienst *nginx-proxy* im Container und wird dem Verzeichnis `/var/log/eb-docker/containers/nginx-proxy` auf dem Host zugeordnet. 
+  Alle Protokolle in diesem Verzeichnis sind nun als Bundle und als Protokollfragmente über die Elastic Beanstalk-Funktion zum [Anfordern von Instance-Protokollen](using-features.logging.md) abrufbar. 



**Hinweise**  
*\$1\$1EB\$1LOG\$1BASE\$1DIR\$1* ist eine Umgebungsvariable, die von Elastic Beanstalk mit dem Wert `/var/log/eb-docker/containers` versehen wird
Elastic Beanstalk erstellt das `/var/log/eb-docker/containers/<service name>`-Verzeichnis für jeden Service in der `docker-compose.yml`-Datei.

## Docker-Images
<a name="docker-images"></a>

Die von Docker und ECS verwalteten Docker-Plattformzweige für Elastic Beanstalk unterstützen die Verwendung von Docker-Images, die in einem öffentlichen oder privaten Online-Image-Repository gespeichert sind.

Geben Sie Images mit Namen in `Dockerrun.aws.json` an. Beachten Sie diese Konventionen:
+ Abbilder in offiziellen Repositorys in Docker Hub verwenden einen einzelnen Namen (z. B. `ubuntu` oder `mongo`).
+ Images in anderen Repositorys in Docker Hub sind mit einem Organisationsnamen qualifiziert (z. B, `amazon/amazon-ecs-agent`).
+ Images in anderen Online-Repositorys sind durch einen Domainnamen zusätzlich qualifiziert (z. B. `quay.io/assemblyline/ubuntu` oder `account-id.dkr.ecr.us-east-2.amazonaws.com/ubuntu:trusty`). 

Für Umgebungen, die nur die Docker-Plattform verwenden, können Sie auch während der Erstellung der Umgebung mit einer Docker-Datei ein eigenes Image erstellen. Details dazu finden Sie unter [Erstellen benutzerdefinierter Images mit einer Dockerfile-Datei](single-container-docker-configuration.md#single-container-docker-configuration.dockerfile). Die von ECS verwaltete Docker-Plattform unterstützt diese Funktionalität nicht.

## Konfigurieren von verwalteten Aktualisierungen für Docker-Umgebungen
<a name="docker-managed-updates"></a>

Mit [verwalteten Plattformaktualisierungen](environment-platform-update-managed.md) können Sie die Umgebung so konfigurieren, dass automatisch nach einem Zeitplan eine Aktualisierung auf die neueste Version einer Plattform durchgeführt wird.

Im Fall von Docker-Umgebungen können Sie entscheiden, ob eine automatische Plattformaktualisierung innerhalb von Docker-Versionen stattfinden soll – falls die neue Version der Plattform eine neue Docker-Version enthält. Elastic Beanstalk unterstützt verwaltete Plattform-Updates für alle Docker-Versionen, wenn von einer Umgebung aus aktualisiert wird, auf der eine Docker-Plattformversion neuer als 2.9.0 läuft. Wenn eine neue Plattformversion eine neue Version von Docker enthält, inkrementiert Elastic Beanstalk die Nebenversionsnummer der Aktualisierung. Um verwaltete Plattformaktualisierungen für Docker-Versionen zuzulassen, aktivieren Sie deshalb verwaltete Plattformaktualisierungen für Nebenversions- und Patch-Versionsaktualisierungen. Um verwaltete Plattformaktualisierungen innerhalb von Docker-Versionen zu verhindern, aktivieren Sie verwaltete Plattformaktualisierungen nur für Patch-Versionsaktualisierungen.

Die folgende [Konfigurationsdatei](ebextensions.md) beispielsweise ermöglicht verwaltete Plattformaktualisierungen jeden Dienstag um 9:00 Uhr UTC für Neben- und Patch-Versionsaktualisierungen und lässt damit verwaltete Aktualisierungen innerhalb von Docker-Versionen zu:

**Example .ebeextensions/ .config managed-platform-update**  

```
option_settings:
  aws:elasticbeanstalk:managedactions:
    ManagedActionsEnabled: true
    PreferredStartTime: "Tue:09:00"
  aws:elasticbeanstalk:managedactions:platformupdate:
    UpdateLevel: minor
```

Für Umgebungen mit Docker-Plattformversionen 2.9.0 oder früher führt Elastic Beanstalk nie verwaltete Plattformaktualisierungen durch, wenn die neue Plattformversion eine neue Docker-Version enthält.

## Docker-Konfigurations-Namespaces
<a name="docker-namespaces"></a>

Mithilfe einer [Konfigurationsdatei](ebextensions.md) können Sie im Rahmen der Bereitstellung Konfigurationsoptionen festlegen und andere Instance-Konfigurationsaufgaben ausführen. Die Konfigurationsoptionen können [plattformspezifisch](command-options-specific.md) sein oder für [alle Plattformen](command-options-general.md) im Elastic Beanstalk-Service als Ganzes gelten. *Die Konfigurationsoptionen sind in Namespaces organisiert.*

**Anmerkung**  
 Diese Informationen gelten nur für Docker-Umgebungen, in denen Docker Compose nicht ausgeführt wird. In Docker-Umgebungen, in denen Docker Compose ausgeführt wird, weist diese Option ein anderes Verhalten auf. Weitere Informationen zu Proxy-Services mit Docker Compose finden Sie unter [Containeroptionen](#docker-software-config.container). 

Die Docker-Plattform unterstützt neben den [unterstützten Optionen für alle Elastic Beanstalk-Umgebungen](command-options-general.md) auch Optionen in den folgenden Namespaces:
+ `aws:elasticbeanstalk:environment:proxy` – Wählen Sie den Proxy-Server für Ihre Umgebung aus. Docker unterstützt entweder die Ausführung von Nginx oder keinen Proxy-Server.

In der folgenden Beispielkonfigurationsdatei wird eine Docker-Umgebung so konfiguriert, dass kein Proxy-Server ausgeführt wird.

**Example .ebextensions/docker-settings.config**  

```
option_settings:
  aws:elasticbeanstalk:environment:proxy:
    ProxyServer: none
```

## Docker-Konfiguration auf Amazon Linux AMI (Vorgängerversion von Amazon Linux 2)
<a name="docker-alami"></a>

Wenn Ihre Elastic Beanstalk Docker-Umgebung eine Amazon Linux AMI-Plattformversion (Vorgängerversion von Amazon Linux 2) verwendet, lesen Sie die zusätzlichen Informationen in diesem Abschnitt.

### Verwenden einer Authentifizierungsdatei für ein privates Repository
<a name="docker-alami.images-private"></a>

Diese Informationen sind für Sie relevant, wenn Sie [Bilder aus einem privaten Repository verwenden](docker-configuration.remote-repo.md). Beginnend mit der Docker-Version 1.7 hat der Befehl **docker login** den Namen der Authentifizierungsdatei und das Format der Datei geändert. Amazon Linux AMI Docker-Plattformversionen (Vorgängerversion von Amazon Linux 2) erfordern die Konfigurationsdatei für ein älteres `~/.dockercfg` Format.

Ab Docker-Version 1.7 und höher erstellt der **docker login**-Befehl die Authentifizierungsdatei in `~/.docker/config.json` im folgenden Format:

```
{
    "auths":{
      "server":{
        "auth":"key"
      }
    }
  }
```

Ab Docker-Version 1.6.2 und früher erstellt der **docker login**-Befehl die Authentifizierungsdatei in `~/.dockercfg` im folgenden Format:

```
{
    "server" :
    {
      "auth" : "auth_token",
      "email" : "email"
    }
  }
```

Wenn Sie eine `config.json`-Datei konvertieren möchten, entfernen Sie den äußeren `auths`-Schlüssel, fügen Sie einen `email`-Schlüssel hinzu und reduzieren Sie das JSON-Dokument, um dem alten Format zu entsprechen.

Bei Amazon Linux 2 Docker-Plattformversionen verwendet Elastic Beanstalk den Namen und das Format der neueren Authentifizierungsdatei. Wenn Sie eine Amazon Linux 2-Docker-Plattformversion verwenden, können Sie die vom **docker login**-Befehl erstellte Authentifizierungsdatei ohne Konvertierung nutzen.

### Konfigurieren von zusätzlichen Speicher-Volumes
<a name="docker-alami.volumes"></a>

Zur Verbesserung der Amazon Linux AMI-Leistung konfiguriert Elastic Beanstalk zwei Amazon EBS-Speicher-Volumes für die Amazon EC2-Instances Ihrer Docker-Umgebung. Zusätzlich zum Stamm-Volume, das für alle Elastic Beanstalk-Umgebungen bereitgestellt wird, wird ein zweites 12-GB-Volume mit dem Namen `xvdcz` für die Image-Speicherung auf Docker-Umgebungen verfügbar gemacht.

Wenn Sie zusätzlichen Speicherplatz oder mehr IOPS für Docker-Images benötigen, können Sie das Image-Speicher-Volume mit der `BlockDeviceMapping`-Konfigurationsoption im [aws:autoscaling:launchconfiguration](command-options-general.md#command-options-general-autoscalinglaunchconfiguration)-Namespace anpassen.

Die folgende [Konfigurationsdatei](ebextensions.md) erhöht die Größe des Speicher-Volumes beispielsweise auf 100 GB mit 500 bereitgestellten IOPS:

**Example .ebextensions/blockdevice-xvdcz.config**  

```
option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:100::io1:500
```

Wenn Sie die `BlockDeviceMappings`-Option zur Konfiguration zusätzlicher Volumes für Ihre Anwendung verwenden, sollten Sie ein Mapping für `xvdcz` einschließen, um sicherzustellen, dass es erstellt wurde. Im folgenden Beispiel werden zwei Volumes konfiguriert, das Image-Speicher-Volume `xvdcz` mit Standardeinstellungen und ein zusätzliches 24-GB-Anwendungs-Volume mit dem Namen `sdh`:

**Example .ebextensions/blockdevice-sdh.config**  

```
option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:12:true:gp2,/dev/sdh=:24
```

**Anmerkung**  
Wenn Sie die Einstellungen in diesem Namespace ändern, ersetzt Elastic Beanstalk alle Instances in Ihrer Umgebung durch Instances, die mit der neuen Konfiguration ausgeführt werden. Details dazu finden Sie unter [Konfigurationsänderungen](environments-updating.md).