FeatureRequest: Use docker variables for managing services

[rdxmb]

At the moment, the existing of e.g. SSH is hard-coded in https://github.com/phusion/baseimage-docker/blob/master/image/buildconfig . If the service will run or not is defined by the existing of the file
/etc/services/sshd/down

This also means:

1. Changing build-vars with --build-arg https://docs.docker.com/engine/reference/commandline/build/#set-build-time-variables---build-arg has no effect.
2. There is no possibility to manage services with docker-env-vars like other images to that.

---

1. It would be more docker-like to manage the existing services with using --build-vars.
2. For managing services within containers this could be done with similar vars like
   RUN_SSH=0
   which could be read by the init-scripts (and move run-scripts from/to /etc/services.disabled) within the init-processes.

[hyperknot]

There are 2 different things here:

1. Enabling the installation of services at build time. This has no effect if you are using the official baseimage, as it is built with all services. It only makes a difference if you are building your own baseimage.

2. Running services at runtime. Since people build images based on docker base, it is preferred to have these things permanent on the filesystem, and not dependent on a complicated system of external variables.

[yebyen]

I just learned about build-args and I agree that it was very complicated and not terribly helpful.

The dockerfile must "opt-in" to accept build args, which is mentioned in the documentation but not easy to notice. This was not obvious for me and I wasted an hour trying to figure out why my build args were not having any effect.

There's little advantage that I can see from just putting "ENV FOO bar" directly in the dockerfile.

(My use case, I was trying to provide an SSH private key for building against private gems. Turns out that build args are preserved in docker history, which is great for reproducibility, but how exactly does one get secrets into a build and not leak them into the image?)

[Theaxiom]

There's no way to store secrets in the image without them being accessible.

[kingdonb]

You can't, that's pretty clear in retrospect

[yebyen]

In openshift, it's actually different! There is a build and buildconfig primitive