为什么我安装的docker卷文件会变成容器内的文件夹？

Question

The scenario is docker inside/beside docker via a sock binding for the purpose of having an easily deployable and scalable runner agent for CI/CD tools (in this particular case, VSTS). The reason for this set up is that the various projects that I want to test use docker/compose to run tests, and configuring a CI/CD worker to be compatible with docker/compose a bunch of times gets cumbersome and time consuming. (This'll eventually be deployed to 4+ Kubernetes Clusters)

Anyway, the problem:

Steps to replicate

1. Run the vsts-agent image

docker run \\ -it \\ -v /var/run/docker.sock:/var/run/docker.sock \\ nullvoxpopuli/vsts-agent-with-aws-ecr:latest \\ /bin/bash

2. Run another image (to emulate docker/compose running tests)

echo 'test' > test-file.txt docker run -it -v file-test.txt:/file-test.txt busybox /bin/sh

3. Check for existence of test-file.txt

cd / ls -la # shows that test-file.txt is a directory

So,
- why are files being mounted as folders inside containers?
- what do I need to do to make the volumes mount correctly?

Solution A - thanks to @BMitch

# On Host machine
docker run -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /tmp/vsts/work/:/tmp/vsts/work \
   nullvoxpopuli/vsts-agent-with-aws-ecr:latest \
   /bin/bash

# In vsts-agent-with-aws-ecr
cd /tmp/vsts/work/
git clone https://NullVoxPopuli@bitbucket.org/group/project.git
cd project/
./scripts/run/eslint.sh
# Success! (this uses docker-compose to map files to the node-based docker image)

Answer 1

Docker creates containers and mounts volumes from the docker host. Any time a file or directory in a volume mount doesn't exist, it gets initialized as an empty directory. So if you are running docker commands from inside of a container to the docker socket those commands get interpreted outside the container on the docker host, where the file doesn't exist. Additionally, the docker run command requires a full path to the volume being mounted when you want a host volume, otherwise it's interpreted as a named volume.

What you likely want to do at this point is:

docker volume rm file-test.txt
docker run -it -v $(pwd)/file-test.txt:/file-test.txt busybox /bin/sh

If instead you are trying to include a file from inside the container to another container, you can initialize a named volume with input redirection like this:

tar -cC . . | docker run -i --rm -v file-test:/target busybox tar -xC /target
docker run -it -v file-test:/data busybox /bin/sh

That uses tar to copy the contents of the current directory to stdout which is processed by the interactive docker command which then extracts those directory contents into /target inside the container which is a named volume. Note that I didn't mount the volume in root in this second example since named volumes are directories and I didn't want to replace the root filesystem.

Another option is to share a volume mount point between multiple containers on the docker host so that files you edit inside one container go to the host where they are mounted into the other container and visible there:

docker run \
  -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /container-data:/container-data \
  nullvoxpopuli/vsts-agent-with-aws-ecr:latest \
  /bin/bash
echo 'test' > /container-data/test-file.txt
docker run -it -v /container-data:/container-data busybox /bin/sh

I don't recommend mounting individual files into a container if these files may be modified while the container is running. File changes often result in a changed inode and docker will have the old inode mounted into the container. As a result, changes either inside or outside of the container to the file may not be seen on the other side, and if you modify the file inside the container, that change may be lost when you delete the container. The solution to the inode issue is to mount the entire directory into the container.