On 26/02/2015 13:00, Dreamcat4 wrote:
^^ Okay so this is what I have been trying to say but Gorka has put
more elegantly here. So you kindda have to try to support both.

* start your supervisor by default: docker run your-image
* get access to the container directly without any s6 process started:
docker run your-image /bin/bash
* run a custom script and supervise it: docker run your-image /init

 I'm still catching up on Docker and this thread, and working on other
small things, and I will prepare a general reply from s6's point of
view, but I have a suggestion for this part: I believe it can be
implemented in a simple fashion.

 - When the image starts, /init sets up and starts the supervision tree,
but not before forking a "stage 2" process that blocks until the
supervision tree is operational; the "init-stage1" script in the
examples/ subdirectory of the s6 package shows how it can be done.
 - If any arguments have been given to /init, the stage 2 process
takes them. ("background { init-stage2 $@ }")
 - The stage 2 process can perform any one-time initialization that
is needed for the image to be fully operational.
 - If stage 2's command line is empty, the stage 2 process simply exits;
the whole container keeps running, with a supervision tree inside.
 - If stage 2's command line is not empty, the stage 2 process execs
into "foreground { $@ } s6-svscanctl -t /service".
This will run the given command line, then shut down the container.

 This gives the client the following options:

 * docker run image commandline
   Runs commandline in the image without starting the supervision environment.
 * docker run image /init
   Starts the supervision environment and lets it run forever. It can be
stopped from the outside via "docker run image s6-svscanctl -t /service".
 * docker run image /init commandline
   Runs commandline in the fully operational supervision environment. When
commandline exits, the supervision environment is stopped and cleaned up.
 * In all cases, everything will be run with the right environment
transmitted from the docker invocation.

 If that is the flexibility you want, it can definitely be achieved, and
it's really easy to do - it's just a question of scripting around the
s6 primitives. (More on that later.)

 While I'm at it: I definitely recommend checking out Alpine Linux if
you're looking for a lightweight, practical distribution that makes
static linking easy. The maintainers are regular contributors to the
musl libc mailing list and seem intent on keeping things working.


Reply via email to