Hello,
Now there is someone (John Regan) who has made s6 images for docker.
And written a blog post about it. Which is a great effort - and the
reason I've come here. But it gives me a taste of wanting more.
Something a bit more foolproof, and simpler, to work specifically
inside of docker.
>From that blog post I get a general impression that s6 has many
advantages. And it may be a good candidate for docker. But I would be
remiss not to ask the developers of s6 themselves not to try to take
some kind of a personal an interest in considering how s6 might best
work inside of docker specifically. I hope that this is the right
mailing list to reach s6 developers / discuss such matters. Is this
the correct mailing list for s6 dev discussions?
I've read and read around the subject of process supervision inside
docker. Various people explain how or why they use various different
process supervisors in docker (not just s6). None of them really quite
seem ideal. I would like to be wrong about that but nothing has fully
convinced me so far. Perhaps it is a fair criticism to say that I
still have a lot more to learn in regards to process supervisors. But
I have no interest in getting bogged down by that. To me, I already
know more-or-less enough about how docker manages (or rather
mis-manages!) it's container processes to have an opinion about what
is needed, from a docker-sided perspective. And know enough that
docker project itself won't fix these issues. For one thing because of
not owning what's running on the inside of containers. And also
because of their single-process viewpoint take on things. Andy way.
That kind of political nonsense doesn't matter for our discussion. I
just want to have a technical discussion about what is needed, and how
might be the best way to solve the problem!
MY CONCERNS ABOUT USING S6 INSIDE OF DOCKER
In regards of s6 only, currently these are my currently perceived
shortcomings when using it in docker:
* it's not clear how to pass in programs arguments via CMD and
ENTRYPOINT in docker
- in fact i have not seen ANY docker process supervisor solutions
show how to do this (except perhaps phusion base image)
* it is not clear if ENV vars are preserved. That is also something
essential for docker.
* s6 has many utilities s6-*
- not clear which ones are actually required for making a docker
process supervisor
* s6 not available yet as .deb or .rpm package
- official packages are helpful because on different distros:
+ standard locations where to put config files and so on may differ.
+ to install man pages too, in the right place
* s6 is not available as official single pre-compiled binary file for
download via wget or curl
- which would be the most ideal way to install it into a docker container
^^ Some of these perceived shortcomings are more important /
significant than others! Some are not in the remit of s6 development
to be concerned about. Some are mild nit-picking, or the ignorance of
not-knowning, having not actually tried out s6 before.
But my general point is that it is not clear-enough to me (from my
perspective) whether s6 can actually satisfy all of the significant
docker-specific considerations. Which I have not properly stated yet.
So here they are listed below…
DOCKER-SPECIFIC CONSIDERATIONS FOR A PROCESS SUPERVISOR
A good process supervisor for docker should ideally:
* be a single pre-compiled binary program file. That can be downloaded
by curl/wget (or can be installed from .deb or .rpm).
* can take directly command and arguments. With argv[] like this:
"process_supervisor" "my_program_or_script" "my program or script
arguments…"
* will pass on all ENV vars to "my_program_or_script" faithfully
* will run as PID 1 inside the linux namespace
* where my_program_or_script may spawn BOTH child AND non-child
(orphaned) processes
* when "process_supervisor" (e.g. s6 or whatever) receives a TERM signal
* it faithfully passes that signal to "my_program_or_script"
* it also passes that signal to any orphaned non-child processes too
* when my_program_or_script dies, or exits
* clean up ALL remaining non-children orphaned processes afterwards
* which share the same linux namespace
- this is VERY important for docker, as docker does not do this
So to ENSURE these things:
* to pass full command line arguments and ENV vars to "my_program_or_script"
* ensure that when "my_program_or_script" exits, (crashes or normal exit)
* no processes are left running in that linux namespace
* ensure that when the service reveives a TERM, (docker stop)
* no processes are left running in that linux namespace
* ensure that when the service reveives a KILL, (docker stop)
* no processes are left running in that linux namespace
BUT in addition, any extra configurability should be entirely optional:
* to add supplemental run scripts (for support programs like cron and
rsyslog etc)
* which is what most general process supervisors consider as their
main mechanism for starting services
SO
* if "my_program_or_script" is supplied as an argument, THAT is the
main process running inside the docker container.
* if no "my_program_or_script" argument is supplied, then use
whatever other conventional ways to determine the main process from
the directories of run scripts.
SUMMARY
Current solutions for docker seem to be "too complex" for various
reasons. Such as:
* no mandatory ssh server (phusion baseimage fails)
* no python dependancy (supervisor fails, and phusion baseimage fails)
* no mandatory cron or rsyslog (current s6 base image fails, and
phusion base image fails)
* no "hundreds of cli tools" - most of which may never be used
(current s6 base image fails)
* no awkward intermediate bootstrap script required to write ENV vars
and cmdline args to a file (runit fails)
So for whichever of those reasons, it feels the problem of docker
remains un-satisfied. And not fully addressed by any individual
solution. What's the best course of action? How can these problems be
solved into one single tool?
I am hoping that the person who wrote this page:
http://skarnet.org/software/s6/why.html
Might be able to comment on some these above ^^ docker-specific
considerations? If so please, it would really be appreciated.
Also cc'ing the author of the docker s6 base images. Who perhaps can
comment about some of the problems he has encountered. Many thanks for
any comments again (but please reply on the mailing list).
Kind Regards
dreamcat4
Received on Wed Feb 25 2015 - 10:55:18 UTC