After a container is running, you cannot configure its contents until the container is stopped.
With bind mounts, a file or directory on a host, such as an Amazon EC2 instance or AWS Fargate, is mounted into a container. Bind mounts are supported for tasks that are hosted on both Fargate and Amazon EC2 instances. By default, bind mounts are tied to the lifecycle of the container that uses them. After all of the containers that use a bind mount are stopped, such as when a task is stopped, the data is removed. For tasks that are hosted on Amazon EC2 instances, the data can be tied to the lifecycle of the host Amazon EC2 instance by specifying a host and optional sourcePath value in your task definition. For more information, see Using bind mounts in the Docker documentation. Show The following are common use cases for bind mounts.
Considerations when using bind mountsWhen using bind mounts, consider the following.
Specifying a bind mount in your task definitionFor Amazon ECS tasks that are hosted on either Fargate or Amazon EC2 instances, the following task definition JSON snippet shows the syntax for the volumes, mountPoints, and ephemeralStorage objects for a task definition. { "family": "", ... "containerDefinitions" : [ { "mountPoints" : [ { "containerPath" : "/path/to/mount_volume", "sourceVolume" : "string" } ], "name" : "string" } ], ... "volumes" : [ { "name" : "string" } ], "ephemeralStorage": { "sizeInGiB": integer } }For Amazon ECS tasks that are hosted on Amazon EC2 instances, you can use the optional host parameter and a sourcePath when specifying the task volume details. When it's specified, it ties the bind mount to the lifecycle of the task rather than the container. "volumes" : [ { "host" : { "sourcePath" : "string" }, "name" : "string" } ]The following describes each task definition parameter in more detail. name Type: String Required: No The name of the volume. Up to 255 letters (uppercase and lowercase), numbers, hyphens, and underscores are allowed. This name is referenced in the sourceVolume parameter of container definition mountPoints. hostRequired: No This parameter is specified when using bind mounts. To use Docker volumes, specify a dockerVolumeConfiguration instead. The contents of the host parameter determine whether your bind mount data volume persists on the host container instance and where it is stored. If the host parameter is empty, then the Docker daemon assigns a host path for your data volume, but the data is not guaranteed to persist after the containers associated with it stop running. Bind mount host volumes are supported when using either the EC2 or Fargate launch types. Windows containers can mount whole directories on the same drive as $env:ProgramData. sourcePath Type: String Required: No When the host parameter is used, specify a sourcePath to declare the path on the host container instance that is presented to the container. If this parameter is empty, then the Docker daemon has assigned a host path for you. If the host parameter contains a sourcePath file location, then the data volume persists at the specified location on the host container instance until you delete it manually. If the sourcePath value does not exist on the host container instance, the Docker daemon creates it. If the location does exist, the contents of the source path folder are exported. mountPointsType: Object Array Required: No The mount points for data volumes in your container. This parameter maps to Volumes in the Create a container section of the Docker Remote API and the --volume option to docker run. Windows containers can mount whole directories on the same drive as $env:ProgramData. Windows containers cannot mount directories on a different drive, and mount point cannot be across drives. sourceVolume Type: String Required: Yes, when mountPoints are used The name of the volume to mount. containerPathType: String Required: Yes, when mountPoints are used The path on the container to mount the volume at. readOnlyType: Boolean Required: No If this value is true, the container has read-only access to the volume. If this value is false, then the container can write to the volume. The default value is false. ephemeralStorageType: Object Required: No The amount of ephemeral storage to allocate for the task. This parameter is used to expand the total amount of ephemeral storage available, beyond the default amount, for tasks hosted on AWS Fargate using platform version 1.4.0 or later (Linux) or 1.0.0 or later (Windows). You can use the Copilot CLI, CloudFormation, the AWS SDK or the CLI to specify ephemeral storage for a bind mount. Bind mount examplesThe following examples cover the most common use cases for using a bind mount for your containers. To allocate an increased amount of ephemeral storage space for a Fargate task For Amazon ECS tasks that are hosted on Fargate using platform version 1.4.0 or later (Linux) or 1.0.0 (Windows), you can allocate more than the default amount of ephemeral storage for the containers in your task to use. This example can be incorporated into the other examples to allocate more ephemeral storage for your Fargate tasks.
To provide an empty data volume for one or more containers In some cases, you want to provide the containers in a task some scratch space. For example, you might have two database containers that need to access the same scratch file storage location during a task. This can be achieved using a bind mount.
To expose a path and its contents in a Dockerfile to a container In this example, you have a Dockerfile that writes data that you want to mount inside a container. This example works for tasks that are hosted on Fargate or Amazon EC2 instances.
To provide an empty data volume for a container that's tied to the lifecycle of the host Amazon EC2 instance For tasks that are hosted on Amazon EC2 instances, you can use bind mounts and have the data tied to the lifecycle of the host Amazon EC2 instance. You can do this by using the host parameter and specifying a sourcePath value. Any files that exist at the sourcePath are presented to the containers at the containerPath value. Any files that are written to the containerPath value are written to the sourcePath value on the host Amazon EC2 instance. Amazon ECS doesn't sync your storage across Amazon EC2 instances. Tasks that use persistent storage can be placed on any Amazon EC2 instance in your cluster that has available capacity. If your tasks require persistent storage after stopping and restarting, always specify the same Amazon EC2 instance at task launch time with the AWS CLI start-task command. You can also use Amazon EFS volumes for persistent storage. For more information, see Amazon EFS volumes.
To mount a defined volume on multiple containers at different locations You can define a data volume in a task definition and mount that volume at different locations on different containers. For example, your host container has a website data folder at /data/webroot. You might want to mount that data volume as read-only on two different web servers that have different document roots.
To mount volumes from another container using volumesFrom For tasks hosted on Amazon EC2 instances, you can define one or more volumes on a container, and then use the volumesFrom parameter in a different container definition within the same task to mount all of the volumes from the sourceContainer at their originally defined mount points. The volumesFrom parameter applies to volumes defined in the task definition, and those that are built into the image with a Dockerfile.
|