Remove Docker-in-Docker from builds

[ironcladlou]

Remove all traces of Docker-in-Docker from builds. The rationale is explained
generally in the docs/builds.md file. In short, Docker-in-Docker isn't secure
or stable for production, and there's no indication it will be in the forseeable
future. The codebase can be simplified by eliminating it, and our focus and
efforts can shift to solving the remaining issues with host Docker access.

[ironcladlou]

@smarterclayton @pmorie @ncdc @bparees

More details on the rationale here: https://github.com/ironcladlou/origin/blob/host_docker_builds/docs/builds.md#docker-build-implementation

[ironcladlou]

Should builds.md be re-framed as a current OpenShift design document rather than a k8s proposal?

[bparees]

@ironcladlou thanks, I like the rational, I am wondering though, why are privileged containers needed for DIND? I would think there are more risks w/ exposing the host docker daemon than having a contained docker daemon.

[bparees]

@ironcladlou and yeah, reframing as OS design makes sense, i believe.

[smarterclayton]

Unfortunately to run DIND you need to be able to mount things... to mount you need CAP_SYS_ADMIN which is ~ root (because if you can mount you can mount things that the kernel calls directly).

So basically, we can make host docker more secure than we can make DIND.

On Sep 18, 2014, at 5:37 PM, Ben Parees notifications@github.com wrote:

@ironcladlou thanks, I like the rational, I am wondering though, why are privileged containers needed for DIND? I would think there are more risks w/ exposing the host docker daemon than having a contained docker daemon.

—
Reply to this email directly or view it on GitHub.

[smarterclayton]

Agree with Ben

On Sep 18, 2014, at 5:50 PM, Ben Parees notifications@github.com wrote:

@ironcladlou and yeah, reframing as OS design makes sense, i believe.

—
Reply to this email directly or view it on GitHub.

[pmorie]

+1 to reframe

On Thursday, September 18, 2014, Clayton Coleman notifications@github.com
wrote:

Agree with Ben

On Sep 18, 2014, at 5:50 PM, Ben Parees <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

@ironcladlou and yeah, reframing as OS design makes sense, i believe.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#111 (comment).

[ironcladlou]

Will revamp the docs later on tonight. It's really unfortunate about DinD since it's so conceptually clean, and I'd love to be proven wrong.

[ironcladlou]

I made major changes to build.md and moved the code-level implementation details to package docs. Please review.

[soltysh]

Maybe it'd make sense to provide also a link to https://docs.docker.com/reference/commandline/cli/#build.

[ironcladlou]

Done, thanks.

[soltysh]

LGTM

[smarterclayton]

@csrwng review please

[mfojtik]

Shouldn't this be configurable?

[pmorie]

This seems to me to fall into the category of things which should be
parameters to the build controller. @smarterclayton does this pass the
threshold for adding a new cli flag?

On Friday, September 19, 2014, Michal Fojtik notifications@github.com
wrote:

In pkg/build/strategy/util.go:

•   podSpec.DesiredState.Manifest.Volumes = append(podSpec.DesiredState.Manifest.Volumes,
  

•       dockerSocketVolume)
  

•   podSpec.DesiredState.Manifest.Containers[0].VolumeMounts =
  

•       append(podSpec.DesiredState.Manifest.Containers[0].VolumeMounts,
  

•           dockerSocketVolumeMount)
  

• } else {

•   podSpec.DesiredState.Manifest.Containers[0].Privileged = true
  

• dockerSocketVolumeMount := api.VolumeMount{

•   Name:      "docker-socket",
  

•   MountPath: "/var/run/docker.sock",
  

Shouldn't this be configurable?

—
Reply to this email directly or view it on GitHub
https://github.com/openshift/origin/pull/111/files#r17789238.

[csrwng]

It assumes that the minion is running the docker daemon locally which I guess is the point of the minion. But if we need to support minions with different configs I think we should handle it in a separate item.

[smarterclayton]

I have yet to see a docker system running with that on a different port

[ironcladlou]

In the future we may also want to somehow expose it over TCP rather than a socket... I'd rather deal with those cases as they arise for now.

[csrwng]

LGTM

[smarterclayton]

LGTM [merge]

[openshift-bot]

Origin Merge Results: SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/111/) (Image: devenv-fedora_178)

[openshift-bot]

Evaluated for origin up to 60b9d7b

[bparees]

@ironcladlou did you kick off rebuilds of the docker builder images? we do not have automatic builds setup right now.

[smarterclayton]

I turned them back on to automatic

On Sep 19, 2014, at 4:23 PM, Ben Parees notifications@github.com wrote:

@ironcladlou did you kick off rebuilds of the docker builder images? we do not have automatic builds setup right now.

—
Reply to this email directly or view it on GitHub.