I tried this as well but no luck - it kept hanging. Also the plugin set-up didn’t seem to be too convenient when it comes to swarm setup. In the end I decided to go with “docker service create …” form as this works. Will give the “copose/swarm” another try in some time.
We have gotten it working with a stack file (aka compose v3+).
Unfortunately I do not have a sample handy, because we went a different route (will explain that below).
One thing I do remember about the compose option is that you MUST have the NFS client install on all swarm hosts your container might run on.
Ok, so after I discovered that docker will not insulate you from the requirement that the storage client (NFS in this case) MUST be installed on the host in ANYWAY, we decided to handle the NFS mount on the host level.
Fairly easy to achieve with tools such as ansible, chef, puppet or whatever.
You could also create a “golden VM” that has the mount config baked in, and just start all your hosts from that.
The container mount then is just a simple, normal “external file system” mount.
For example:
my-server:
image: someimage
volumes:
- /data/myapp/:/myapp/data
As a general side note: if you are unhappy with persistent storage options in swarm setups at the moment, believe me, you are NOT alone.
Basically it all sorta sucks, although I hear good things about rexray. BUT, again, host-level intervention is required afaik.
As I matter of fact I got it working too - last night I decided to give it another try and TA-DA! It worked! Looks like I was fairly close to it before. You are right though, you do need the NFS client on the host installed.
I tried also with mounting it on the host but that works only when one container is trying to then use this mount as a volume with every next one failed to do so.
I am thinking of adding NFS mounts to my “farm” right now I am using a SMB mount since the host OS is Windows. However, I am missing some key things that some container images such as GitLab require specifically permissions.
My question about using NFS is primarily with regards to concurrency and write conflicts on a larger scale. I am also thinking that the NFS mounts will be proper VMs just configured to be NFS stores not docker containers.
BTW I recommend you use the TLS connection from Jenkins to docker if you plan to use the docker-slaves plugin rather than giving full control of the socket.