Re: process supervisor - considerations for docker

From: John Regan <john_at_jrjrtech.com>
Date: Thu, 26 Feb 2015 14:53:28 -0600

On Thu, Feb 26, 2015 at 08:23:47PM +0000, Dreamcat4 wrote:
> You CANNOT enforce specific ENTRYPOINT + CMD usages amongst docker
> users. It will never work because too many people use docker in too
> many different ways. And it does not matter from a technical
> perspective for the solution I have been quietly thinking of (but not
> had an opportunity to share yet).
>
> It's best to think of ENTRYPOINT (in conventional docker learning
> before throwing in any /init system) and being "the interpreter" such
> as the "/bin/sh -c" bit that sets up the environment. Like the shebang
> line. Or could be the python interpreter instead etc.

I disagree, and I think your second paragraph actually supports my
argument: if you think of ENTRYPOINT as the command for setting up the
environment, then it makes sense to use ENTRYPOINT as the method for
setting up a supervision tree vs not setting up a supervision tree,
because those are two pretty different environments.

People use Docker in tons of different ways, sure. But I'm completely
able to say "this is the entrypoint my image uses, and this is what it
does."

Besides, the whole idea here is to make an image that follows best
practices, and best practices state we should be using a process
supervisor that cleans up orphaned processes and stuff. You should be
encouraging people to run their programs, interactively or not, under
a supervision tree like s6.

Heck, most people don't *care* about this kind of thing because they
don't even know. So if you just make /init the ENTRYPOINT, 99% of
people will probably never even realize what's happening. If they can
run `docker run -ti imagename /bin/sh` and get a working, interactive
shell, and the container exits when they type "exit", then they're
good to go! Most won't even question what the image is up to, they'll
just continue on getting the benefits of s6 without even realizing it.

>
> My suggestion:
>
> * /init is launched by docker as the first argument.
> * init checks for "$_at_". If there are any arguments:
>
> * create (from a simple template) a s6 run script
> * run script launches $1 (first arg) as the command to run
> * run script template is written with remaining args to $1
>
> * proceed normally (inspect the s6 config directory as usual!)
> * as there should be no breakage of all existing functionality
>
> * Providing there is no VOLUME sat ontop of the /etc/s6 config directory
> * Then the run script is temporary - it will only last while the
> container is running.
> * So won't be there anymore to cleanup on and future 'docker run'
> invokations with different arguments.
>
> The main thing I'm concerned about is about preserving proper shell
> quoting, because sometimes args can be like --flag='some thing'.
>
> It may be one simple way to get proper quoting (in conventional shells
> like bash) is to use 'set -x' to echo out the line, as the output is
> ensured by the interpreter to be re-executable. Although even if that
> takes care of the quotes, it would still not be good to have
> accidental variable expansion, interpretation of $ ! etc. Maybe I'm
> thinking a bit too far ahead. But we already know that Gorka's '/init'
> script is written in bash.

I think here, you're getting way more caught up in the details of your
idea than you need to be. Shells, arguments, quoting, etc, you're
overcomplicating some of this stuff.
Received on Thu Feb 26 2015 - 20:53:28 UTC