Support prefixing Docker build and push commands with 'sudo'.

[rbellamy]

When building docker images on CentOS, Fedora or RHEL, the permissions on /var/run/docker.socket have restricted access, preventing Docker build and push commands from executing without severely compromising the system.

See http://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-run-docker-in-centos-fedora-or-rhel/

Therefore, I've added a new setting which supports prefixing both the Docker build and push commands with 'sudo', which is the recommended method for executing Docker on CentOS, Fedora and RHEL.

[rbellamy]

I realized I should have added some further thoughts.

What I don't want to do is run SBT as root - this will cause the working directory, and the ivy cache to become polluted with artifacts that are owned by root. It's best to limit the use of escalated privileges to just those commands that require them to avoid this pollution.

So, to avoid:

sudo sbt docker:publishLocal
sbt clean <=== will fail because "target" is now owned by root

[rbellamy]

This was just a bug in the scripted test

[rbellamy]

Not sure why the two JDK tests failed in Travis... looks like a problem with the simple-app test (which I didn't touch)?

[muuki88]

Not sure why the two JDK tests failed in Travis... looks like a problem with the simple-app test (which I didn't touch)?

This is rather strange. I restarted the jobs. Sometimes travis throws random errors. However tihs looks strange as the same test fails on both JDK8 and 7.

[muuki88]

I'm not sure if introducing a new setting is necessary to achieve this. Mainly because you should be able to do this with

dockerBuildCommand := "sudo" +: dockerBuildCommand.value

IMHO an example in the DockerPlugin documentation would be sufficient. WDYT?

[rbellamy]

I'm embarrassed to say ii didn't even think of that. Yeah, that's much better. I'll put together another quick PR.

[rbellamy]

Actually, after further thought, I'm not sure it's so clear cut.

Specifically, ALL docker commands need to prefixed with sudo, which is problematic for the current implementation of the dockerBuildCommands and the fact that it is completely disconnected from the docker push task:

val cmd = Seq("docker", "push", tag)

An alternative approach would alter the build command process by adding a new SettingKey (maybe dockerCommand) which could be used as a prefix for all docker commands.

@muuki88 given the above, and that I've already done this work, I'm reopening this PR - if you have an alternative you'd like from me, just say the word.

[muuki88]

AFAIK you need to run docker as sudo in all distros to make things work.

I have not that much experience building docker images for production. There are a couple of options to workaround this, for example as described in the mentioned blog post

alias docker="sudo /usr/bin/docker"

Introducing new settings always means maintaining them, even when they get obsolete. That's the reason I'm so sceptical if this is really necessary.

CC @fiadliel

[rbellamy]

Hammer, meet screw. I've been so focused on my build scripts and pipeline that I missed that I was solving the problem the wrong way - sorry for the noise.

The solution is to make my pipeline always alias the docker command.

[muuki88]

No problem 😉 Happy to help.

[rbellamy]

Here's the major challenge - when working on a CI server, jobs are frequently run using a non-interactive shell. This means setting an alias is VERY problematic. I've just spent several hours (most of today) trying to push Jenkins around to make my build scripts work WITHOUT issuing the sudo command directly, and I'm about where I was when I started...

[rbellamy]

And after further analysis (and a significant rework of my build pipeline to support aliases, including a custom Jenkins pipeline function) even if the shell which calls SBT contains an alias to sudo docker, ProcessBuilder doesn't support it, because aliases are not inherited by child processes, nor are functions.

[rbellamy]

As a matter fact, given what I've found, there are four options here:

1. run SBT as root (a bad idea as I mentioned in my first comment)
2. open docker to non-root users (again, a bad idea)
3. or accept that code calling into docker needs to support prefixing that call with a sudo command
4. The final alternative would be to provide a dockerExecCommand setting which would be used by both docker build and docker push that would allow any arbitrary prefix.

I'm not going to just re-open this PR, pending feedback from either @muuki88 or @fiadliel - if the dockerExecCommand is preferable, then I'll get that turned around and sent to you guys post-haste.

[muuki88]

Oh man :( java's processbuilder doesn't support aliases.

I can understand that 2. is not a good option ( even a lot of people may do it this way ).

The dockerExecCommand settings would be the best solution as it's generic enough to support future quirks of docker, while the dockerUseSudo is only a workaround.