> Well you are then neglecting to see 2 other benefits which i neglected
> to mention anywhere previously:
>
> 1) Is that anyone can just look in my Dockerfile and see the default
> tvheadend arguments as-is. Without needing to go around chasing them
> being embedded in some script (when only Dockerfile is published to
> DockerHub, not such start scripts).
That's true, that they can just look in the Dockerfile. But I'll argue
the easy way to fix that is by writing a good README file.
When you get a chance take a look at the sameersbn/gitlab readme file:
https://registry.hub.docker.com/u/sameersbn/gitlab/
The guy documents every single environment variable, what they do, a
"quick start" guide, and so on. This is what I strive to do now when I
write a README.
When an image has a solid README and great docs, I don't even feel the
need to look at the Dockerfile. If a regular user feels like they need
to go through my Dockerfile to figure out how to use my image, then my
image sucks.
> 2) Is that when they run my image, they can do a 'docker ps' and see
> the FULL tvheadend arguments, including the default ones in the entry
> point component. Which is then behaving much more like regular 'ps'
> command.
>
This is true for my method, also. When you run a 'docker ps',
'docker top', or 'docker inspect' you'll see the fully-resolved
command line.
> I actually like those benefits, and as the image writer have the
> responsibility to ensure such things work properly, and to my own
> liking.
>
> > arguments in the first place. Your ENTRYPOINT just remains "/init",
> > which will launch s6-svscan, which will launch TVHeadEnd. Your CMD
> > array remains null.
> >
> > Now, conceptually, you can think of TVHeadEnd as requiring "system
> > arguments" and "user arguments" -- "system arguments" being those
> > defaults you mentioned.
>
> Yeah - expect I don't actually want to do that, and Docker INC are
> officially giving me the freedom to use both entrypoint + cmd in any
> ways as I personally see fit.
>
> >
> > Now just make the TVHeadEnd `run` script something like:
>
> vv that start script won't be published in 'Dockerfile' tab on
> Dockerhub. Therefore, the more functionality I am pushing from the
> Dockerfile into that script, then the harder my Dockerfile will be for
> other people to understand.
>
> It's a comletely valid way of doing things. I just don't think you
> should try to enforce it as a hard rule in other people's images.
>
None of this is really a "hard rule" I guess.
But I *have* been using Docker since version 0.5, and use it in
production systems with a team of people. Everything I've learned
about Docker, I've learned "the hard way."
I've made images in the past where the users needed to change the
ENTRYPOINT for different tasks, and it's really, really confusing. You
really save yourself (and everybody) a lot of headache and grief by
not encouraging the user to mess around with the ENTRYPOINT.
-John
Received on Fri Feb 27 2015 - 19:32:40 UTC