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. # Bind-Mounts mit Amazon ECS verwenden Bei Bind-Mounts wird eine Datei oder ein Verzeichnis auf einem Host wie einer Amazon-EC2-Instance in einem Container gemountet. Bind-Mounts werden für Aufgaben unterstützt, die auf Fargate und Amazon-EC2-Instances gehostet werden. Bind-Mounts sind an den Lebenszyklus des Containers gebunden, in dem sie verwendet werden. Nachdem alle Container, die ein Bind-Mount verwenden, gestoppt wurden, z. B. wenn eine Aufgabe gestoppt wird, werden die Daten entfernt. Bei Aufgaben, die auf Amazon-EC2-Instances gehostet werden, können die Daten an den Lebenszyklus der Host-Amazon-EC2-Instance gebunden werden, indem ein `host` und optional ein `sourcePath`-Wert in der Aufgabendefinition festgelegt werden. Weitere Informationen finden Sie unter [Bind-Mounts](https://docs.docker.com/engine/storage/bind-mounts/) in der Docker-Dokumentation. Die folgenden Szenarien sind gängige Anwendungsfälle für Bind-Mounts. + So stellen Sie ein leeres Daten-Volume bereit, das in einem oder mehreren Containern bereitgestellt werden soll. + So stellen Sie ein Host-Daten-Volume in einem oder mehreren Containern bereit. + So geben Sie ein Daten-Volume aus einem Quell-Container für andere Container in derselben Aufgabe frei. + Um einen Pfad und seinen Inhalt aus einer Dockerdatei für einen oder mehrere Container verfügbar zu machen. ## Überlegungen zur Verwendung von Bind-Mounts Bei der Verwendung von Bind-Mounts sollte Folgendes berücksichtigt werden. + Standardmäßig erhalten Aufgaben, die auf der AWS Fargate Plattformversion `1.4.0` oder höher (Linux) `1.0.0` oder höher (Windows) gehostet werden, mindestens 20 GiB flüchtigen Speicher für Bind-Mounts. Sie können die Gesamtmenge des flüchtigen Speichers bis zu einem Maximum von 200 GiB erhöhen, indem Sie den `ephemeralStorage`-Parameter in Ihrer Aufgabendefinition angeben. + Um Dateien aus einer Docker-Datei auf einem Daten-Volume verfügbar zu machen, wenn eine Aufgabe ausgeführt wird, sucht die Amazon-ECS-Datenebene nach einer `VOLUME`-Richtlinie. Wenn der absolute Pfad, der in der `VOLUME`-Richtlinie angegeben ist der gleiche wie `containerPath` ist, die in der Aufgabendefinition angegeben sind, werden die Daten im `VOLUME`-Richtlinienpfad auf das Daten-Volume kopiert. Im folgenden Dockerfile-Beispiel wird eine Datei mit dem Namen `examplefile` im `/var/log/exported`-Verzeichnis auf den Host geschrieben und dann innerhalb des Containers gemountet. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` Standardmäßig sind die Volume-Berechtigungen auf `0755` und der Besitzer als `root` festgelegt. Sie können diese Berechtigungen in der Dockerfile anpassen. Das folgende Beispiel definiert den Eigentümer des Verzeichnisses als `node`. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN yum install -y shadow-utils && yum clean all RUN useradd node RUN mkdir -p /var/log/exported && chown node:node /var/log/exported RUN touch /var/log/exported/examplefile USER node VOLUME ["/var/log/exported"] ``` + Bei Aufgaben, die auf Amazon-EC2-Instances gehostet werden, wenn ein `host`- und `sourcePath`-Wert nicht angegeben ist, verwaltet der Docker-Daemon das Bind-Mount für Sie. Wenn keine Container auf dieses Bind-Mount verweisen, löscht der Aufgabenbereinigungsservice des Amazon-ECS-Container-Agenten es letztendlich. Standardmäßig geschieht dies drei Stunden nach dem Stoppen des Containers. Die Zeitspanne kann aber mit der Agenten-Variable `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` konfiguriert werden. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md). Wenn Sie diese Daten länger als den Lebenszyklus des Containers beibehalten möchten, geben Sie für den Bind-Mount einen `sourcePath`-Wert an. + Bei Aufgaben, die auf Amazon ECS Managed Instances gehostet werden, sind Teile des Root-Dateisystems schreibgeschützt. Read/write Bind-Mounts müssen beschreibbare Verzeichnisse verwenden, z. B. `/var` für persistente Daten oder für temporäre Daten. `/tmp` Der Versuch, read/write Bind-Mounts für andere Verzeichnisse zu erstellen, führt dazu, dass die Aufgabe nicht gestartet werden kann und ein Fehler ähnlich dem folgenden angezeigt wird: ``` error creating empty volume: error while creating volume path '/path': mkdir /path: read-only file system ``` Schreibgeschützte Bind-Mounts (mit `"readOnly": true` im `mountPoints` Parameter konfiguriert) können auf jedes beliebige Verzeichnis auf dem Host verweisen, auf das zugegriffen werden kann. Um eine vollständige Liste der beschreibbaren Pfade anzuzeigen, können Sie eine Aufgabe auf einer Amazon ECS Managed Instance ausführen und damit die Mount-Tabelle der Instance überprüfen. Erstellen Sie eine Aufgabendefinition mit den folgenden Einstellungen, um auf das Host-Dateisystem zuzugreifen: ``` { "pidMode": "host", "containerDefinitions": [{ "privileged": true, ... }] } ``` Führen Sie dann die folgenden Befehle innerhalb des Containers aus: ``` # List writable mounts cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^rw,/ || $4 == "rw" {print $2}' | sort # List read-only mounts cat /proc/1/root/proc/1/mounts | awk '$4 ~ /^ro,/ || $4 == "ro" {print $2}' | sort ``` **Wichtig** Die `privileged` Einstellung gewährt dem Container erweiterte Funktionen auf dem Host, was dem Root-Zugriff entspricht. In diesem Beispiel wird sie verwendet, um die Mount-Tabelle des Hosts zu Diagnosezwecken zu überprüfen. Weitere Informationen finden Sie unter [Vermeiden, Container als privilegiert auszuführen (Amazon EC2)](security-tasks-containers.md#security-tasks-containers-recommendations-avoid-privileged-containers). Weitere Hinweise zur interaktiven Ausführung von Befehlen in Containern finden Sie unter[Überwachen von Amazon-ECS-Containern mit ECS Exec](ecs-exec.md). # Ein Bind-Mount in einer Amazon-ECS-Aufgabendefinition angeben Für Amazon-ECS-Aufgaben, die entweder in Fargate oder auf Amazon-EC2-Instances gehostet sind, zeigt der folgende JSON-Ausschnitt einer Aufgabendefinition die Syntax für die `volumes`-, `mountPoints`-, und `ephemeralStorage`-Objekte für eine Aufgabendefinition. ``` { "family": "", ... "containerDefinitions" : [ { "mountPoints" : [ { "containerPath" : "/path/to/mount_volume", "sourceVolume" : "string" } ], "name" : "string" } ], ... "volumes" : [ { "name" : "string" } ], "ephemeralStorage": { "sizeInGiB": integer } } ``` Für Amazon-ECS-Aufgaben, die auf Amazon-EC2-Instances gehostet werden, können Sie den optionalen `host`-Parameter und `sourcePath` nutzen, wenn Sie die Details des Aufgaben-Volumes angeben. Sind diese angegeben, wird das Bind-Mount an den Lebenszyklus der Aufgabe und nicht an den Container gebunden. ``` "volumes" : [ { "host" : { "sourcePath" : "string" }, "name" : "string" } ] ``` Im Folgenden finden Sie weitere detaillierte Beschreibungen der einzelnen Aufgabendefinitionsparameter. `name` Typ: Zeichenfolge Erforderlich: Nein Der Name des Volumes. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche (`-`) und Unterstriche (`_`) sind erlaubt. Auf diesen Namen wird im Parameter `sourceVolume` des `mountPoints`-Objekts der Container-Definition verwiesen. `host` Erforderlich: Nein Der `host`-Parameter wird verwendet, um den Lebenszyklus des Bind-Mounts an die Amazon-EC2-Host-Instance und nicht an die Aufgabe zu binden und dort zu speichern. Wenn der Parameter `host` leer ist, weist der Docker-Daemon einen Host-Pfad für Ihr Daten-Volume zu, es wird aber nicht gewährleistet, dass die Daten beibehalten werden, nachdem die damit verknüpften Container nicht mehr ausgeführt werden. Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie `$env:ProgramData` einbinden. Der `sourcePath` Parameter wird nur unterstützt, wenn Aufgaben verwendet werden, die auf Amazon EC2-Instances oder Amazon ECS Managed Instances gehostet werden. `sourcePath` Typ: Zeichenfolge Erforderlich: Nein Wenn der Parameter `host` verwendet wird, geben Sie einen `sourcePath` an, um den Pfad auf der Amazon-EC2-Host-Instance zu deklarieren, die dem Container bereitgestellt wird. Wenn dieser Parameter leer ist, weist der Docker-Daemon einen Host-Pfad für Sie zu. Wenn der Parameter `host` den Speicherort `sourcePath` enthält, bleibt das Daten-Volume an der angegebenen Position der Amazon-EC2-Host-Instance erhalten, bis Sie es manuell löschen. Wenn der Wert `sourcePath` auf der Amazon-EC2-Host-Instance nicht vorhanden ist, wird er vom Docker-Daemon erstellt. Wenn der Speicherort nicht vorhanden ist, wird der Inhalt des Quellpfadordners exportiert. `mountPoints` Typ: Objekt-Array Erforderlich: Nein Die Mounting-Punkte für die Daten-Volumes in Ihrem Container. Dieser Parameter ist in der create-container-Docker-API der Option `Volumes` zugeordnet und die Option `--volume` ist der Docker-Ausführung zugeordnet. Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie `$env:ProgramData` einbinden. Windows-Container können keine Verzeichnisse auf einem anderen Laufwerk mounten, und es ist kein laufwerksübergreifender Mounting-Punkt möglich. Sie müssen Mounting-Punkte angeben, um ein Amazon-EBS-Volume direkt an eine Amazon-ECS-Aufgabe anzuhängen. `sourceVolume` Typ: Zeichenfolge Erforderlich: Ja, wenn `mountPoints` verwendet werden Der Name des einzubindenden Volumes. `containerPath` Typ: Zeichenfolge Erforderlich: Ja, wenn `mountPoints` verwendet werden Der Pfad in dem Container, in dem das Volume eingebunden wird. `readOnly` Typ: Boolesch Erforderlich: Nein Wenn dieser Wert `true` lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert `false`, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist `false`. Behalten Sie für Aufgaben, die auf EC2-Instances unter dem Windows-Betriebssystem ausgeführt werden, den Standardwert von `false` bei. `ephemeralStorage` Typ: Objekt Erforderlich: Nein Die Menge des flüchtigen Speichers, der für die Aufgabe zugewiesen werden soll. Dieser Parameter wird verwendet, um die Gesamtmenge an verfügbarem temporärem Speicher für Aufgaben, die auf der AWS Fargate verwendeten Plattformversion `1.4.0` oder höher (Linux) `1.0.0` oder höher (Windows) gehostet werden, über die Standardmenge hinaus zu erweitern. Sie können die Copilot-CLI, das AWS SDK oder die CLI verwenden CloudFormation, um kurzlebigen Speicher für einen Bind-Mount anzugeben. # Beispiele für Bind-Mounts für Amazon ECS In den folgenden Beispielen werden häufige Anwendungsfälle für die Verwendung eines Bind-Mounts für Ihre Container behandelt. **So weisen Sie einer Fargate-Aufgabe einen erhöhten flüchtigen Speicher zu** Für Amazon-ECS-Aufgaben, die auf Fargate mit Plattformversion `1.4.0` oder höher (Linux) oder `1.0.0` (Windows) gehostet werden können Sie mehr als die Standardmenge des flüchtigen Speichers für die zu verwendenden Container in Ihrer Aufgabe zuweisen. Dieses Beispiel kann in die anderen Beispiele integriert werden, um flüchtigen Speicher für Ihre Fargate-Aufgaben zuzuweisen. + Definieren Sie in der Aufgabendefinition ein `ephemeralStorage`-Objekt. `sizeInGiB` muss eine Ganzzahl zwischen den Werten von `21` und `200` sein und wird in GiB ausgedrückt. ``` "ephemeralStorage": { "sizeInGiB": integer } ``` **So stellen Sie ein leeres Daten-Volume für einen oder mehrere Container bereit** In einigen Fällen möchten Sie den Containern in einer Aufgabe einen Scratchspace bereitstellen. Möglicherweise besitzen Sie z. B. zwei Datenbank-Container, die während einer Aufgabe auf denselben Scratch-Dateispeicherort zugreifen müssen. Dies kann mit einem Bind-Mount erreicht werden. 1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Bind-Mount mit dem Namen `database_scratch`. ``` "volumes": [ { "name": "database_scratch" } ] ``` 1. Erstellen Sie im Abschnitt `containerDefinitions` die Datenbank-Containerdefinitionen, damit sie das Volume mounten. ``` "containerDefinitions": [ { "name": "database1", "image": "my-repo/database", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "database_scratch", "containerPath": "/var/scratch" } ] }, { "name": "database2", "image": "my-repo/database", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "database_scratch", "containerPath": "/var/scratch" } ] } ] ``` **So stellen Sie einen Pfad und seinen Inhalt in einer Dockerdatei einem Container zur Verfügung** In diesem Beispiel haben Sie eine Dockerdatei, die Daten schreibt, die Sie in einem Container mounten möchten. Dieses Beispiel funktioniert für Aufgaben, die auf Fargate oder Amazon-EC2-Instances gehostet werden. 1. Erstellen Sie eine Docker-Datei. Im folgenden Beispiel wird das öffentliche Amazon Linux 2-Container-Image verwendet und eine Datei mit dem Namen `examplefile` im `/var/log/exported`-Verzeichnis, das wir innerhalb des Containers einhängen möchten. Die `VOLUME`-Direktive sollte einen absoluten Pfad angeben. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN mkdir -p /var/log/exported RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` Standardmäßig sind die Volume-Berechtigungen auf `0755` und der Besitzer als `root` festgelegt. Diese Berechtigungen können in der Dockerdatei geändert werden. Im folgenden Beispiel wird der Besitzer des `/var/log/exported`-Verzeichnis auf `node` festgelegt. ``` FROM public.ecr.aws/amazonlinux/amazonlinux:latest RUN yum install -y shadow-utils && yum clean all RUN useradd node RUN mkdir -p /var/log/exported && chown node:node /var/log/exported USER node RUN touch /var/log/exported/examplefile VOLUME ["/var/log/exported"] ``` 1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Volume mit dem Namen `application_logs`. ``` "volumes": [ { "name": "application_logs" } ] ``` 1. Erstellen Sie im Abschnitt `containerDefinitions` die Containerdefinitionen der Anwendung, damit sie den Speicher mounten. Der `containerPath`-Wert muss mit dem absoluten Pfad übereinstimmen, der in der `VOLUME`-Richtlinie aus der Dockerfile angegeben ist. ``` "containerDefinitions": [ { "name": "application1", "image": "my-repo/application", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "application_logs", "containerPath": "/var/log/exported" } ] }, { "name": "application2", "image": "my-repo/application", "cpu": 100, "memory": 100, "essential": true, "mountPoints": [ { "sourceVolume": "application_logs", "containerPath": "/var/log/exported" } ] } ] ``` **So stellen Sie ein leeres Daten-Volume für einen Container bereit, der mit dem Lebenszyklus der Host-Amazon-EC2-Instance verknüpft ist** Bei Aufgaben, die auf Amazon-EC2-Instances gehostet werden, können Sie Bind-Mounts verwenden und die Daten an den Lebenszyklus der Host-Amazon-EC2-Instance binden. Das geschieht mithilfe des `host`-Parameters und durch Angeben eines `sourcePath`-Werts. Alle Dateien, die im `sourcePath` vorhanden sind, werden den Containern im `containerPath`-Wert angezeigt. Alle Dateien, die in den `containerPath`-Wert geschrieben werden, werden in den `sourcePath`-Wert auf der Host-Amazon-EC2-Instance geschrieben. **Wichtig** Amazon ECS synchronisiert Ihren Speicher nicht über Amazon-EC2-Instances hinweg. Aufgaben, die persistenten Speicher nutzen, können auf eine beliebige Amazon-EC2-Instance in Ihrem Cluster mit verfügbarer Kapazität platziert werden. Wenn Ihre Aufgaben nach dem Stoppen und Neustarten persistenten Speicher benötigen, geben Sie beim Start der Aufgabe immer dieselbe Amazon EC2 EC2-Instance mit dem Befehl AWS CLI [start-task](https://docs.aws.amazon.com/cli/latest/reference/ecs/start-task.html) an. Sie können Amazon EFS Volumes auch für persistenten Speicher verwenden. Weitere Informationen finden Sie unter [Amazon-EFS-Volumes mit Amazon ECS verwenden](efs-volumes.md). 1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Bind-Mount mit `name`- und `sourcePath`-Werten. Im folgenden Beispiel enthält die Host-Amazon-EC2-Instance Daten unter`/ecs/webdata`, die Sie im Container montieren möchten. ``` "volumes": [ { "name": "webdata", "host": { "sourcePath": "/ecs/webdata" } } ] ``` 1. Definieren Sie im Abschnitt `containerDefinitions` einen Container mit einem `mountPoints`-Wert, der auf den Namen des definierten Bind-Mounts verweist, und mit dem `containerPath`-Wert, auf dem das Bind-Mount auf dem Container gemountet werden soll. ``` "containerDefinitions": [ { "name": "web", "image": "public.ecr.aws/docker/library/nginx:latest", "cpu": 99, "memory": 100, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webdata", "containerPath": "/usr/share/nginx/html" } ] } ] ``` **So mounten Sie ein definiertes Volume auf mehreren Containern an verschiedenen Standorten** Sie können ein Daten-Volume in einer Aufgabendefinition definieren und das Volume an verschiedenen Speicherorten auf verschiedenen Containern mounten. Angenommen, Ihr Host-Container besitzt einen Website-Datenordner in `/data/webroot`. Möglicherweise möchten Sie dieses Daten-Volume schreibgeschützt auf zwei verschiedenen Web-Servern mounten, die über verschiedene Basis-Verzeichnisse verfügen. 1. Definieren Sie im Abschnitt `volumes` der Aufgabendefinition ein Daten-Volume mit dem Namen `webroot` und dem Quellpfad `/data/webroot`. ``` "volumes": [ { "name": "webroot", "host": { "sourcePath": "/data/webroot" } } ] ``` 1. Definieren Sie im Abschnitt `containerDefinitions` für jeden Webserver einen Container mit `mountPoints`-Werten, die das `webroot`-Volume dem `containerPath`-Wert zuordnen, der auf das Basisverzeichnis des betreffenden Containers verweist. ``` "containerDefinitions": [ { "name": "web-server-1", "image": "my-repo/ubuntu-apache", "cpu": 100, "memory": 100, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webroot", "containerPath": "/var/www/html", "readOnly": true } ] }, { "name": "web-server-2", "image": "my-repo/sles11-apache", "cpu": 100, "memory": 100, "portMappings": [ { "containerPort": 8080, "hostPort": 8080 } ], "essential": true, "mountPoints": [ { "sourceVolume": "webroot", "containerPath": "/srv/www/htdocs", "readOnly": true } ] } ] ``` **So mounten Sie mit `volumesFrom` Volumes aus einem anderen Container** Für Aufgaben, die auf Amazon-EC2-Instances gehostet werden, können Sie ein oder mehrere Volumes in einem Container definieren und dann den `volumesFrom`-Parameter in einer anderen Containerdefinition innerhalb derselben Aufgabe verwenden, um einer Mounting für alle Volumes von `sourceContainer` an ihrem ursprünglich definierten Mounting-Punkt herzustellen. Der Parameter `volumesFrom` gilt für alle Volumes, die in der Aufgabendefinition definiert sind, und für solche Volumes, die im Image mit einer Dockerfile integriert sind. 1. (Optional) Um ein Volume freizugeben, das in ein Image integriert ist, verwenden Sie die `VOLUME`-Anweisung in der Dockerfile. Im folgenden Beispiel verwendet die Dockerfile ein `httpd`-Image, fügt ein Volume hinzu und mountet es unter `dockerfile_volume` im Stammverzeichnis von Apache. Es ist der Ordner, der vom `httpd`-Webserver verwendet wird. ``` FROM httpd VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"] ``` Sie können ein Image mit dieser Dockerfile erstellen und direkt in ein Repository, wie z. B. den Docker-Hub, übertragen und in Ihrer Aufgabendefinition verwenden. Das in den folgenden Schritten verwendete `my-repo/httpd_dockerfile_volume`-Beispiel-Image wurde mit der oben genannten Dockerfile erstellt. 1. Erstellen Sie eine Aufgabendefinition, die Ihre Volumes und Mounting-Punkte für die Container definiert. In diesem `volumes`-Beispielabschnitt erstellen Sie ein leeres Volume namens `empty`, das vom Docker-Daemon verwaltet wird. Auch ein Host-Volume namens `host_etc` ist definiert. Es exportiert den `/etc`-Ordner auf der Host-Container-Instance. ``` { "family": "test-volumes-from", "volumes": [ { "name": "empty", "host": {} }, { "name": "host_etc", "host": { "sourcePath": "/etc" } } ], ``` Erstellen Sie im Abschnitt der Containerdefinitionen einen Container, der die zuvor definierten Volumes mountet. In diesem Beispiel mountet der `web`-Container die Volumes `empty` und `host_etc`. Dies ist der Container, der das mit einem Volume in der Dockerfile erstellte Image verwendet. ``` "containerDefinitions": [ { "name": "web", "image": "my-repo/httpd_dockerfile_volume", "cpu": 100, "memory": 500, "portMappings": [ { "containerPort": 80, "hostPort": 80 } ], "mountPoints": [ { "sourceVolume": "empty", "containerPath": "/usr/local/apache2/htdocs/empty_volume" }, { "sourceVolume": "host_etc", "containerPath": "/usr/local/apache2/htdocs/host_etc" } ], "essential": true }, ``` Erstellen Sie einen anderen Container, der mit `volumesFrom` alle Volumes mountet, die dem Container `web` zugeordnet sind. Alle Volumes im `web`-Container werden ebenfalls im `busybox`-Container gemountet. Das schließt das in der Dockerfile angegebene Volume ein, das zum Erstellen des `my-repo/httpd_dockerfile_volume`-Images verwendet wurde. ``` { "name": "busybox", "image": "busybox", "volumesFrom": [ { "sourceContainer": "web" } ], "cpu": 100, "memory": 500, "entryPoint": [ "sh", "-c" ], "command": [ "echo $(date) > /usr/local/apache2/htdocs/empty_volume/date && echo $(date) > /usr/local/apache2/htdocs/host_etc/date && echo $(date) > /usr/local/apache2/htdocs/dockerfile_volume/date" ], "essential": false } ] } ``` Wenn diese Aufgabe ausgeführt wird, mounten die beiden Container die Volumes, und der `command` im `busybox`-Container schreibt das Datum und die Uhrzeit in eine Datei. Diese Datei heißt `date` in jedem der Volume-Ordner. Die Ordner sind dann auf der Website sichtbar, die durch den Container `web` angezeigt wird. **Anmerkung** Da der `busybox`-Container einen Kurzbefehl ausführt und dann beendet wird, muss er in der Containerdefinition auf `"essential": false` gesetzt werden. Andernfalls wird die gesamte Aufgabe gestoppt, wenn er beendet wird.