Why CircleCI 2.0 does not support mounting folders?

docker
2.0

#1

In 2.0, mounting folders from docker is not supported, as documented at https://circleci.com/docs/2.0/building-docker-images/#mounting-folders. What’s the reason behind that?

For context, I was trying to migrate a build of one of my repos that requires this feature. Asking docker to mount the volume was fine, but no files were visible there.

This repo of mine is a docker tool, and has some very peculiar needs. If 2.0 doesn’t not support mounting volumes, I’ll probably migrate away from CircleCI altogether.

P.S.: my repo is open source. I can share the link to my migration attempt if that helps.


#2

You can mount volumes on the machine executor but not the base docker executor. The reason is because the Docket socket is over TCP. On the machine, Docker is just running so you have 100% control over how it behaves, inclusive of mounting volumes.


#3

are you saying that, with the docker executor, the daemon is on a different machine?

That “Potential Premium Feature Notice” is making me shun the machine executor. Perhaps, I’ll use the docker cp and run all my build from a secondary container. The level of inception is getting legendary here.


#4

You are correct. The Docker socket is on a virtual machine in both scenarios.


#5

This is absolutely ridiculous. You are not supporting two major features of docker: opening ports, and volumes. AND - this is not documented anywhere apart form these threads.

I suggest that this become a feature of the docker executor ASAP.


#6

I understand that they tried to maximise control over the docker host, but ended up creating some downsides. Unfortunately, these downsides make some things very hard to do.

I honestly think that this needs a solution or CircleCI will risk losing lots of existing clients. For my personal projects, I found it easier to migrate to a different service than to try to upgrade to CircleCI 2.0.


#7

You can’t build Docker within Docker. Use the machine executor if that’s a problem for you.


#8

That’s not a true statement. You can build docker within the docker executor. However, the following features are missing (at a minimum):

  1. You can’t open ports external to the docker network where the containers are running.
  2. Volumes don’t work.

There are two separate threads (but nowhere in the documentation) that point out that these two key features are missing.


#9

It is absolutely true. Short of sharing a Docker socket from a host, you can’t build Docker within Docker. We made setup_remote_docker for certain cases for simplicity. It sounds like your use case requires volumes so you should use the machine executor. The ports work there, too.


#10

Are you sure that’s absolutely true? Because below is an example of deploying a swarm within a docker executor:
https://circleci.com/gh/OpenIAM/openiam-docker-compose/335

Code is open-sourced:


#11

Apparently, none of the docker-compose.yml used in that repo (github.com/OpenIAM/openiam-docker-compose) mount the local directory where the source coed would be. This means that all the volumes that they did mount only exist in the docker host machine. The fact that the host is different than the machine that is directly executing your build becomes irrelevant in this scenario.

To be clear, volumes do work in CircleCI 2.0. The only part that won’t work directly is mounting the local directory, allowing the container to access the source code of the repo being tested. If you don’t need that, you shouldn’t have a problem with CircleCI 2.0.


#12

And this is only true for the docker executor. You can use the machine and not run into any issues whatsoever as it’s a full VM.


#13

Having ports and mounting volumes in the docker-compose in docker scenario should be possible via NFS:

Your remote-docker-host could have separated networks, that are automagically tunneled to the correct job-docker-instance. Also using tunnels you could use the NFS volume driver to mount those volumes. Of course it’s not straight forward, but I would also vote for such a feature. Using docker cp instead of mounts is to cumbersome.


#14

Just use the machine executor…


#15