Re: process supervisor - considerations for docker

From: Dreamcat4 <>
Date: Mon, 2 Mar 2015 13:24:36 +0000

On Sun, Mar 1, 2015 at 9:13 AM, Gorka Lertxundi <> wrote:
> Hi guys,
> I haven't had much time this week due to work and now I am overwhelmed!
> Yesterday, as Dreamcat4 has noticed, I've been working in a version that
> gathers all the ideas covered here.
> All,
> * I already converted bash init scripts into execline and make use of
> s6-utils instead of 'linux' ones to facilitate usage in another base images.
> * It's important to have just _one_ codebase, this would help focusing
> improvements and problems in one place. I extracted all the elements I
> thought would be useful in a container environment. So, if you all feel
> comfortable we could start discussing bugs, improvements or whatever there.
> I called this project/repo container-s6-overlay-builder (
> * Now, and after abstracting 's6-overlay', using ubuntu with s6 is a matter
> of extracting a tarball. container-base is using it already:
> * To sum up, we all agree with this. It is already implemented in the
> overlay:
> - Case #1: Common case, start supervision tree up.
> docker run image
> - Case #2: Would start a shell without the supervision tree running
> docker run -ti --entrypoint="" base /bin/sh
> - Case #3: Would start a shell with the supervision tree up.
> docker run -ti image /bin/sh
> Dreamcat4,
> * Having a tarball with all the needed base elements to get s6 working is
> the way to go!
> Laurent,
> * Having a github mirror repo is gonna help spreading the word!
> * Although three init phases are working now I need your help with those
> scripts, probably a lot of mistakes were done...

Thank you for doing so much of this. Have been testing it yesterday.
It is pretty good. Especialy for:

* The passing of CMD arguments - works well.
* Receiving a TERM - orphan reaping (docker stop) - works well.

For the rough edges: Each item raised as seperate Github issue on your
repo Gorka. Laurent please check them also if you can. They are here

Open issues on Gorka's s6-overlay repo:

Subscibe to issue to track it.
Many thanks.

> -
> -
> -
> * I've chosen /etc/s6/.s6-init as the destination folder for the init
> scripts, would you like me to change?

^^ Laurent

> John,
> About github organization, I think this is not the place to discuss about
> it. I really like the idea and I'm open to discuss it but first things
> first, lets focus on finishing this first approach! Still, simple-d and
> micro-d are good names but are tightly coupled to docker *-d, and rocket
> being the relatively the new buzzword (kubernetes is going to support it)
> maybe we need to reconsider them.
> rgds,
> 2015-02-28 18:57 GMT+01:00 John Regan <>:
>> Sweet. And yeah, as Laurent mentioned in the other email, it's the
>> weekend. Setting dates for this kind of stuff is hard to do, I just
>> work on this in my free time. It's done when it's done.
>> I also agree that s6 is *not* a docker-specific tool, nor should it
>> be. I'm thankful that Laurent's willing to listen to any ideas we
>> might have re: s6 development, but like I said, the goal is *not*
>> "make s6 a docker-specific tool"
>> There's still a few high-level decisions to be made, too, before we
>> really start any work:
>> 1. Goals:
>> * Are we going to make a series of s6 baseimages (like one
>> based on Ubuntu, another on CentOS, Alpine, and so on)?
>> * Should we pick a base distro and focus on creating a series of
>> platform-oriented images, aimed more at developers (ie, a PHP image, a
>> NodeJS image, etc)?
>> * Or should be focus on creating a series of service-oriented
>> images, ie, an image for running GitLab, an image for running an
>> XMPP server, etc?
>> Figuring out the overall, high-level focus early will be really
>> helpful in the long run.
>> Options 2 and 3 are somewhat related - you can't really get to 3
>> (create service-oriented images) without getting through 2 (make
>> platform-oriented images) anyway.
>> It's not like a goal would be set in stone, either. If more guys want
>> to get on board and help, we could alway sit down and re-evaluate.
>> With more manpower, you could get into doing a whole series of
>> distro-based, service-oriented images (ie, a Ubuntu XMPP server as
>> well as an Alpine XMPP server).
>> But given we're just a few guys, setting a straightforward small focus
>> is probably the way to go. I would vote for either creating a series
>> of baseimages, oriented towards other image-makers, or pick Alpine as
>> a base, and focus on making small and efficient service-oriented
>> images (ie, a 10MB XMPP service, something like that) aimed at
>> sysadmins/users.
>> But I'm open to any of those options, or others, so long as it's
>> within the realm of possibility for just a few people working in their
>> free time.
>> 1. Should be form a GitHub org, and what should it be called?
>> I vote yes, I'll go ahead and make it if you want.
>> For the org name, I was thinking about starting a series of Alpine
>> images aimed at users (like I said, 10MB chat service) under the org
>> name "micro-d" (as in, Micro Docker containers), already. If that's the
>> focus we go with, then that's probably a pretty OK name.
>> If we go with doing a series of simple, easy-to-use baseimages aimed
>> at other imagemakers, then probably something like "simple-d" (Simple
>> Docker containers).
>> Again, open to suggestions, those are just my initial ideas. The one
>> thing I would advise against is using s6 in the name, since that
>> would imply it's a project under the umbrella, which I
>> don't think this is. It's outside that scope. We can promote how much
>> we love s6 all we want in the docs, and blog posts, and so on, but
>> we *shouldn't* do things like call our init "s6-init", name the image
>> "s6-alpine", stuff like that.
>> Once we figure out the high-level goals, we can set out a few more
>> structural-type things.
>> -John
Received on Mon Mar 02 2015 - 13:24:36 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC