Thank you for moving my message Laurent. Sorry for the mixup r.e. the mailing lists. I have subscribed to the correct list now (for s6 specific).
On Wed, Feb 25, 2015 at 11:30 AM, Laurent Bercot <[email protected]> wrote: > > (Moving the discussion to the [email protected] list. > The original message is quoted below.) > > Hi Dreamcat4, > > Thanks for your detailed message. I'm very happy that s6 found an > application in docker, and that there's such an interest for it! > [email protected] is indeed the right place to reach me and > discuss the software I write, but for s6 in particular and process > supervisors in general, [email protected] is the better > place - it's full of people with process supervision experience. > > Your message gives a lot of food for thought, and I don't have time > right now to give it all the attention it deserves. Tonight or > tomorrow, though, I will; and other people on the supervisionlist > will certainly have good insights. > > Cheers! > > -- Laurent > > > > On 25/02/2015 11:55, Dreamcat4 wrote: >> >> 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 > >
