Allow configuration of container capabilities

[bitwisekaizen]

In the same spirit of #13, I have the same requirement to set a custom MAC address for my container at runtime. I know that there's a separate issue open for more customized parameters, but I'd like to submit a PR for an approach that is similar to the one that was taken for DNS. Let me know if there any objections, otherwise, I will take this up in the next couple of days. Thanks!

[bitwisekaizen]

After inspecting the code and the service API, it looks like this will not be possible (without work on the docker engine as well...and I don't want to hassle with that). A workaround would be to set the MAC address within the container, but we'd need to allow for certain capabilities to be set. The API does not expose this either in the most recent releases (which also prevents us from being able to build docker containers using the swarm plugin). A change is pending release that will allow us to do this (moby/moby#39173). Perhaps, we should wait for the next Docker release and then add capabilities to a label instead so that we kill two birds with one stone.

[bitwisekaizen]

Just saw the "dind" code after my last post. I suppose I can use that for now as a workaround, but will leave this open to have a tighter integration with the Docker API in the future.

[bitwisekaizen]

Spoke too soon. Dind will only allow me to run privileged with the docker in docker image. Rethinking the approach for the workaround now as well.

[arseniybanayev]

FYI moby/moby#25885 (comment)

I needed this feature to be able to mount an NFS drive as a deployment step in one of my builds. However, my docker cloud agent template is already set up to bind-mount the swarm host's /var/run/docker.sock to the agent container for other deployment steps like docker stack deploy -c ..., so my workaround for my NFS-mount deployment step is to create a new container using docker run --privileged ... that mounts and deploys the files I need to deploy. This works because the docker run --privileged ... is executed against the swarm host, so it's the swarm host's capabilities that are extended to my innermost container (rather than the swarm service's capabilities, which are limited).