- Newest
- Most votes
- Most comments
In your case, it looks like Docker is creating additional volumes (e.g., ocis-v6_ocis-config and ocis-v6_ocis-data) despite the fact that you already specified volumes using EFS in your docker-compose.yml. This can be confusing, but it is likely due to how Docker handles named volumes versus bind mounts.
Let’s break it down and explore what's happening.
Named Volumes vs. Bind Mounts:
Named Volumes: Managed by Docker. These volumes are created in Docker’s internal storage (typically /var/lib/docker/volumes) and are useful for persistent storage across container restarts.
Bind Mounts: These directly map directories on your host machine to directories inside your container. In your case, you're using bind mounts to point to your EFS directories.
Your docker-compose.yml breakdown:
Service volumes:
volumes:
- ocis-config:/etc/ocis
- ocis-data:/var/lib/ocis
These lines are telling Docker to mount the volumes ocis-config and ocis-data into the container’s directories /etc/ocis and /var/lib/ocis.
Global volumes:
volumes:
ocis-config:
driver: local
driver_opts:
type: "none"
o: "bind"
device: "/mnt/efs/fs1/etc/ocis"
ocis-data:
driver: local
driver_opts:
type: "none"
o: "bind"
device: "/mnt/efs/fs1/var/lib/ocis"
These configurations are supposed to bind the Docker volumes to specific EFS directories on your host system (/mnt/efs/fs1/etc/ocis and /mnt/efs/fs1/var/lib/ocis).
Why are additional volumes being created?
When you define volumes in Docker Compose without explicitly configuring them, Docker automatically creates named volumes (like ocis-v6_ocis-config and ocis-v6_ocis-data) in Docker’s own storage space. In your case, even though you are trying to bind the volumes to EFS, Docker still creates named volumes with similar names because it thinks they are separate.
How to Fix This:
You can avoid Docker creating additional volumes by specifying the volume names consistently in both the service and the global volumes section. This ensures that Docker will use your bind-mounted EFS directories instead of creating new named volumes.
Here’s how to update your docker-compose.yml:
services:
your_service:
volumes:
- ocis-config:/etc/ocis
- ocis-data:/var/lib/ocis
volumes:
ocis-config:
driver: local
driver_opts:
type: "none"
o: "bind"
device: "/mnt/efs/fs1/etc/ocis"
ocis-data:
driver: local
driver_opts:
type: "none"
o: "bind"
device: "/mnt/efs/fs1/var/lib/ocis"
Important: Avoid Redefining Volume Names
Make sure that in your service volumes: section, you don't create new names (e.g., ocis-v6_ocis-config). This happens automatically when Docker Compose generates a unique project name prefix, but keeping the volume names consistent will prevent that.
Best Practices for Production:
Use Bind Mounts for Sensitive Data: As you’re already doing with EFS, bind mounts are great for sensitive information that needs to be shared across multiple containers and EC2 instances.
Avoid Named Volumes for External Storage: For production, it’s usually better to use bind mounts for volumes that need to persist on the host, especially when using EFS or other external storage solutions.
Ensure Consistent Volume Names: Always explicitly declare volumes in both the service and global sections of docker-compose.yml to avoid unintended volume creation.
Verifying Volume Usage:
After bringing up your services, you can inspect which volumes are actually in use with the following command:
docker inspect <container_name>
Relevant content
asked 2 years ago
In fact, this is the way I have it, I declare the global volumes and then in the service I put the name of the global volume, but it still keeps creating additional volumes, so I don't know what to do