I think you guys are kindda on the right track. But you are trying to
impose some un-needed restrictions in regards to CMD vs ENTRYPOINT
usage.
To docker, the final combination of ENTRYPOINT + CMD is all that
matters. So long as the first arg is /init. Then any remaining args
should be shifted and used to determine what program is being run on
supervision.
So basically all the user has to care about (to get process
supervision) is to pre-pend "/init" as the first argument, before
argv[0] (the command to run) and any optional subsequent args.
If there is no arguments after "/init". Then it's multi-manages
process. And just conventional ways (inspect config directories for
each services).
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.
It's best to understand CMD as being the docker image's user
presentation of its exposed "command interface". So for example if you
ran docker inside of docker, it's overridable CMD part would be the
docker subcommands such as 'run' 'stop' etc. And then users can
understand that "docker run docker <cmd> <args>" Is all they need to
care about from a user perpective. --help usage of the docker image
and so on.
But technically, /init should only ever receive and argv[] array which
is the combined ENTRYPOINT + CMD appended after it (whether the user
has overridden entry point or has no entry point set is entirely their
business. And inside of /init it cannot know such things anyway.
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.
Sorry for coming at it from a completely different angle!
:)
On Thu, Feb 26, 2015 at 5:03 PM, John Regan <john_at_jrjrtech.com> wrote:
>
>
>> I think you're better off with:
>>
>> * Case 1 : docker run --entrypoint="" image commandline
>>(with or without -ti depending on whether you need an interactive
>>terminal)
>> * Case 2 : docker run image
>> * Case 3: docker run image commandline
>>(with or without -ti depending on whether you need an interactive
>>terminal)
>>
>> docker run --entrypoint="" -ti image /bin/sh
>>would start a shell without the supervision tree running
>>
>> docker run -ti image /bin/sh
>>would start a shell with the supervision tree up.
>>
>
> After reading your reasoning, I agree 100% - let -ti drive whether it's interactive, and --entrypoint drive whether there's a supervision tree.
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
Received on Thu Feb 26 2015 - 20:23:47 UTC