Mounting volume where host directory is different on CI server

Cross post - Mounting volume where host directory is different on CI server

Hi,

I’m encountering a problem and I’m not sure how to solve it. I have a docker compose file that mounts a volume from the host to the container. When running docker-compose up locally, the path on the host will always be the same. However, when running docker-compose up from the Continuous Integration (CI) server, the path is different.

For example, the docker-compose has the following

volumes:
  - ${HOME}/directory:/root/directory

I want to have the following when docker-compose is run on the CI server

volumes:
  - ${ANOTHER_VARIABLE}/mydir:/root/directory

I really don’t want to have two docker-compose.yml files. Does anyone have any ideas how to address this?

Why do you need to do this? What is in that directory? Bind mounts are usually eschewed when trying to be portable for this very reason.

The directory contains SSH keys. I actually found a solution.

I created a second docker-compose.ci_server.yml file, that contains the mount point. And in my CI server, I call

docker-compose -f docker-compose.yml -f docker-compose.ci_server.yml up

And it appears to replace the container /root/.ssh directory with the one I want from my CI server.

Glad you found a solution.

(Obligatory: Don’t run containers as root. Use USER)

Why not just use your own environment var and set it appropriately on both systems? That is sort of the point of env vars.

Alternatively, just use - “./mydir:/root/directory” and create a soft link to ./mydir from ${HOME}/mydir on one machine and from ${ANOTHER_VARIABLE}/directory on the other.

First, there may be multiple people running docker-compose locally.

Second, an environment variable requires system configuration. Since docker-compose doesn’t currently support advanced variable substitution, it’s not ideal since we would need to ensure that every local execution has this env var defined.

Third, a symbolic link requires every host to have it exist on the system. If the symlink isn’t on the system, the containers started from docker-compose won’t have the required volumes.

The solution I came up with has less chances of failing due to the host being “misconfigured”.