Meaning of "device" and "mountpoint" in docker volumes

user_7875813 0
Viewed 981

I want to clarify the meaning of the "device" and "mountpoint" when I do the command

docker volume inspect

in Postgres container. I manually created test_postgresdb_vol_2 folder in /user/data/test_postgresdb_vol_2 to store persist the data from container, but now I'm confusing since I have two different paths. Can you clarify what is happening and what is the meaning of "device" path and "mountpoint" path.

Example of volume inspect:

[
    {
        "CreatedAt": "...",
        "Driver": "local",
        "Labels": {
            ....
        },
        "Mountpoint": "/var/lib/docker/volumes/test_pgdata/_data",
        "Name": "test_pgdata",
        "Options": {
            "device": "/user/data/test_postgresdb_vol_2",
            "o": "bind",
            "type": "none"
        },
        "Scope": "local"
    }
]

Example of docker-compose:

postgres:
  container_name: postgres
  image: postgres
  volumes:
    - pgdata:/var/lib/postgresql/data 
  environment:
    ...
    PGDATA: /var/lib/postgresql/data/pgdata
volumes:
  pgdata:
    driver: local
    driver_opts:
       o: bind
       type: none
       device: /user/data/test_postgresdb_vol_2
docker-volume docker-compose docker postgresql
1 Answers

Those details in the docker volume inspect output are implementation details that can be safely ignored.

Internally, the current standard implementation of Docker named volumes gives them a filesystem presence inside /var/lib/docker/volumes. In this case, you've told Docker that the volume should actually be created via the mount(2) system call, and more specifically as a bind-type mount. The options you see could be parameters to mount(8)

/sbin/mount -o bind $DEVICE $MOUNT_POINT

You might notice that the Driver and Options match things you've specified directly in the docker-compose.yml file, pgdata matches the name of the volume, test matches the name of the current directory (and more specifically the Compose project name, should you override that), and test_pgdata where it appears is a combination of the two.

None of this matters to standard application code. From the docker-compose file you've shown, you declare that the named volume is local and backed by a specific host directory, and it mounts into the postgres container on a specific path. The inspect-type commands produce low-level debugging data that you almost never need.

user_100081730
Related