Konfigurieren von Docker-Umgebungen

Es gibt mehrere Möglichkeiten, das Verhalten Ihrer Elastic Beanstalk-Docker-Umgebung zu konfigurieren.

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).

Konfigurieren von Software in Docker-Umgebungen

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-Konsole und wählen Sie in der Liste Regions (Regionen) Ihre AWS-Region aus.

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

   Anmerkung

   Wenn Sie viele Umgebungen haben, verwenden Sie die Suchleiste, um die Umgebungsliste zu filtern.

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

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

5. Nehmen Sie die notwendigen Konfigurationsänderungen vor.

6. 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 Umgebungseigenschaften und andere Softwareeinstellungen. Die folgenden Abschnitte behandeln Docker-spezifische Informationen.

Containeroptionen

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 erweiterte Zustandsberichte (Docker Compose).

Umgebungseigenschaften und Umgebungsvariablen

Im Bereich Environment Properties (Umgebungseigenschaften) können Sie die Einstellungen für die Umgebungskonfiguration der Amazon Elastic Compute Cloud (Amazon EC2)-Instances angeben, auf denen die Anwendung ausgeführt wird. Umgebungseigenschaften werden als Schlüssel-Wert-Paare an die Anwendung weitergeleitet. in einer Docker-Umgebung übergibt Elastic Beanstalk Umgebungseigenschaften als Umgebungsvariablen an Container.

Ihr Anwendungscode, der in einem Container ausgeführt wird, kann nach Namen auf eine Umgebungsvariable verweisen und dessen Wert lesen. Der Quellcode, von dem diese Umgebungsvariablen gelesen werden, 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 Umgebungseigenschaften und andere Softwareeinstellungen.

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.

Verweisen auf Umgebungsvariablen in Containern

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.

Verwendung des Interpolations-Features für Umgebungsvariablen (Docker Compose)

Ab der Plattformversion vom 28. Juli 2023 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 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 im Thema Erweiterung von Linux-Plattformen in diesem Handbuch.

Generieren von Protokollen für erweiterte Zustandsberichte (Docker Compose)

Der Elastic-Beanstalk-Zustandsagent 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

Angepasste Protokollierung für Docker-Container (Docker Compose)

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

Wenn sich Ihre Anwendungen auf einer Docker-Plattform befinden, von der Docker Compose nicht genutzt wird, können Sie das unter beschriebene Standardverfahren verwende Angepasste Protokollierung für Docker-Container (Docker Compose).

So konfigurieren Sie die Protokolldateien Ihres Service als abrufbare Fragmentdateien und Bundle-Protokolle

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

2. 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 <Name des Service>.

   • /var/log/nginx ist <Protokollverzeichnis innerhalb des Containers>.

   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 abrufbar.

Hinweise

• ${EB_LOG_BASE_DIR} 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

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. Die Multi-Container-Docker-Plattform unterstützt diese Funktionalität nicht.

Verwenden von Images aus einem Amazon ECR-Repository

Sie können Ihre benutzerdefinierten Docker-Images in AWS mit Amazon Elastic Container Registry (Amazon ECR) speichern. Wenn Sie Ihre Docker-Images in Amazon ECR speichern, authentifiziert sich Elastic Beanstalk automatisch bei der Amazon ECR-Registry mit dem Instance-Profil Ihrer Umgebung, so dass Sie keine Authentifizierungsdatei generieren und in Amazon Simple Storage Service (Amazon S3) hochladen müssen.

Sie müssen allerdings Ihren Instances die Berechtigung für den Zugriff auf die Images in Ihrem Amazon ECR-Repository erteilen, indem Sie Berechtigungen zum Instance-Profil Ihrer Umgebung hinzufügen. Sie können die verwaltete Richtlinie AmazonEC2ContainerRegistryReadOnly an das Instance-Profil anfügen, um schreibgeschützten Zugriff auf alle Amazon ECR-Repositorys in Ihrem Konto zu ermöglichen. Sie können auch Zugriff auf einzelne Repositorys gewähren, indem Sie eine benutzerdefinierte Richtlinie gemäß folgender Vorlage erstellen:

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "AllowEbAuth",
        "Effect": "Allow",
        "Action": [
          "ecr:GetAuthorizationToken"
        ],
        "Resource": [
          "*"
        ]
      },
      {
        "Sid": "AllowPull",
        "Effect": "Allow",
        "Resource": [
          "arn:aws:ecr:us-east-2:account-id:repository/repository-name"
        ],
        "Action": [
          "ecr:GetAuthorizationToken",
          "ecr:BatchCheckLayerAvailability",
          "ecr:GetDownloadUrlForLayer",
          "ecr:GetRepositoryPolicy",
          "ecr:DescribeRepositories",
          "ecr:ListImages",
          "ecr:BatchGetImage"
        ]
      }
    ]
  }

Ersetzen Sie den Amazon-Ressourcennamen (ARN) in der oben genannten Policy durch den ARN Ihres Repository.

Verweisen Sie in Ihrer Dockerrun.aws.json-Datei über die URL auf das Image. Für die Docker-Plattform lautet die URL in der Image-Definition:

  "Image": {
      "Name": "account-id.dkr.ecr.us-east-2.amazonaws.com/repository-name:latest",
      "Update": "true"
    },

Verwenden Sie bei der Multi-Container-Docker-Plattform den image-Schlüssel in einem Container-Definitionsobjekt:

"containerDefinitions": [
        {
        "name": "my-image",
        "image": "account-id.dkr.ecr.us-east-2.amazonaws.com/repository-name:latest",

Verwenden von Images aus einem privaten Repository

Für die Verwendung eines Docker-Image in einem privaten Repository, das von einem Online-Registry gehostet wird, müssen Sie eine Authentifizierungsdatei angeben, die Informationen enthält, die zur Authentifizierung mit dem Registry erforderlich sind.

Erstellen Sie eine Authentifizierungsdatei mit dem docker login-Befehl. Für Repositorys auf Docker Hub führen Sie au docker login:

$ docker login

Für andere Registrys fügen Sie die URL des Registry-Servers ein:

$ docker login registry-server-url

Anmerkung

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

Laden Sie eine Kopie mit dem Namen .dockercfg der Authentifizierungsdatei in einen sicheren Amazon S3-Bucket hoch. Der Amazon-S3-Bucket muss in derselben AWS Region gehostet sein wie die Umgebung, die ihn verwendet. Elastic Beanstalk kann keine Dateien von einem Amazon S3-Bucket herunterladen, der in anderen Regionen gehostet wird. Erteilen Sie Berechtigungen für den Vorgang s3:GetObject für die IAM-Rolle im Instance-Profil. Details hierzu finden Sie unter Elastic Beanstalk Instance-Profile verwalten.

Fügen Sie die Amazon S3-Bucket-Informationen zum Authentication- (v1) oder authentication- (v2) Parameter in der Dockerrun.aws.json-Datei hinzu.

Weitere Informationen zum Dockerrun.aws.json-Format für Docker-Umgebungen finden Sie unter Docker-Konfiguration. Informationen zu Multi-Container-Umgebungen finden Sie unter ECS-verwaltete Docker-Konfiguration.

Weitere Informationen zur Authentifizierungsdatei finden Sie unter Store images on Docker Hub und docker login auf der Docker-Website.

Konfigurieren von verwalteten Aktualisierungen für Docker-Umgebungen

Mit verwalteten Plattformaktualisierungen 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 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:

Beispiel .ebextensions/managed-platform-update.config

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

Mithilfe einer Konfigurationsdatei können Sie im Rahmen der Bereitstellung Konfigurationsoptionen festlegen und andere Instance-Konfigurationsaufgaben ausführen. Konfigurationsoptionen können durch den Elastic Beanstalk-Service oder die verwendete Plattform definiert und in Namespaces organisiert werden.

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.

Die Docker-Plattform unterstützt neben den unterstützten Optionen für alle Elastic Beanstalk-Umgebungen 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.

Beispiel .ebextensions/docker-settings.config

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

Docker-Konfiguration auf Amazon Linux AMI (Vorgängerversion von Amazon Linux 2)

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

Diese Informationen sind für Sie relevant, wenn Sie Bilder aus einem privaten Repository verwenden. 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

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-Namespace anpassen.

Die folgende Konfigurationsdatei erhöht die Größe des Speicher-Volumes beispielsweise auf 100 GB mit 500 bereitgestellten IOPS:

Beispiel .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:

Beispiel .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.