Bind mount examples

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.

In the task definition, define an ephemeralStorage object. The sizeInGiB must be an integer between the values of 21 and 200 and is expressed in GiB.
```
"ephemeralStorage": {
    "sizeInGiB": integer
}
```

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.

In the task definition volumes section, define a bind mount with the name database_scratch.
```
  "volumes": [
    {
      "name": "database_scratch"
    }
  ]
```

In the containerDefinitions section, create the database container definitions. This is so that they mount the volume.


"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"
        }
      ]
    }
  ]

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.

Create a Dockerfile. The following example uses the public Amazon Linux 2 container image and creates a file that's named examplefile in the /var/log/exported directory that we want to mount inside the container. The VOLUME directive should specify an absolute path.
```
FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN mkdir -p /var/log/exported
RUN touch /var/log/exported/examplefile
VOLUME ["/var/log/exported"]
```
By default, the volume permissions are set to 0755 and the owner as root. These permissions can be changed in the Dockerfile. In the following example, the owner of the /var/log/exported directory is set to 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					    
USER node
RUN touch /var/log/exported/examplefile
VOLUME ["/var/log/exported"]
```
In the task definition volumes section, define a volume with the name application_logs.
```
  "volumes": [
    {
      "name": "application_logs"
    }
  ]
```

In the containerDefinitions section, create the application container definitions. This is so they mount the storage. The containerPath value must match the absolute path that's specified in the VOLUME directive from the Dockerfile.


  "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"
        }
      ]
    }
  ]

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.

Important

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 Amazon CLI start-task command. You can also use Amazon EFS volumes for persistent storage. For more information, see Use Amazon EFS volumes with Amazon ECS.

In the task definition volumes section, define a bind mount with name and sourcePath values. In the following example, the host Amazon EC2 instance contains data at /ecs/webdata that you want to mount inside the container.
```
  "volumes": [
    {
      "name": "webdata",
      "host": {
        "sourcePath": "/ecs/webdata"
      }
    }
  ]
```

In the containerDefinitions section, define a container with a mountPoints value that references the name of the bind mount and the containerPath value to mount the bind mount at on the container.


  "containerDefinitions": [
    {
      "name": "web",
      "image": "nginx",
      "cpu": 99,
      "memory": 100,
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80
        }
      ],
      "essential": true,
      "mountPoints": [
        {
          "sourceVolume": "webdata",
          "containerPath": "/usr/share/nginx/html"
        }
      ]
    }
  ]

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.

In the task definition volumes section, define a data volume with the name webroot and the source path /data/webroot.


  "volumes": [
    {
      "name": "webroot",
      "host": {
        "sourcePath": "/data/webroot"
      }
    }
  ]

In the containerDefinitions section, define a container for each web server with mountPoints values that associate the webroot volume with the containerPath value pointing to the document root for that container.


  "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
        }
      ]
    }
  ]

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.

(Optional) To share a volume that is built into an image, use the VOLUME instruction in the Dockerfile. The following example Dockerfile uses an httpd image, and then adds a volume and mounts it at dockerfile_volume in the Apache document root. It is the folder used by the httpd web server.
```
FROM httpd
VOLUME ["/usr/local/apache2/htdocs/dockerfile_volume"]
```
You can build an image with this Dockerfile and push it to a repository, such as Docker Hub, and use it in your task definition. The example my-repo/httpd_dockerfile_volume image that's used in the following steps was built with the preceding Dockerfile.
Create a task definition that defines your other volumes and mount points for the containers. In this example volumes section, you create an empty volume called empty, which the Docker daemon manages. There's also a host volume defined that's called host_etc. It exports the /etc folder on the host container instance.
```
{
  "family": "test-volumes-from",
  "volumes": [
    {
      "name": "empty",
      "host": {}
    },
    {
      "name": "host_etc",
      "host": {
        "sourcePath": "/etc"
      }
    }
  ],
```
In the container definitions section, create a container that mounts the volumes defined earlier. In this example, the web container mounts the empty and host_etc volumes. This is the container that uses the image built with a volume in the Dockerfile.
```
"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
    },
```
Create another container that uses volumesFrom to mount all of the volumes that are associated with the web container. All of the volumes on the web container are likewise mounted on the busybox container. This includes the volume that's specified in the Dockerfile that was used to build the my-repo/httpd_dockerfile_volume image.
```
    {
      "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
    }
  ]
}
```
When this task is run, the two containers mount the volumes, and the command in the busybox container writes the date and time to a file. This file is called date in each of the volume folders. The folders are then visible at the website displayed by the web container.

Note
Because the busybox container runs a quick command and then exits, it must be set as "essential": false in the container definition. Otherwise, it stops the entire task when it exits.