Re: process supervisor - considerations for docker

From: Dreamcat4 <dreamcat4_at_gmail.com>
Date: Sun, 1 Mar 2015 00:21:00 +0000

Right,
Glad that others (maybe Laurent and Gorka) want to do some guys who
all have more experience than me with 's6' process supervisor. I way
just offering to do it in case, to not impose extra work on anybody
who is already busy.

Gorka is now working on something changes today. I don't quite know
what those are. It seems like we should check again his repos after he
finishes whatever stuff he's currently doing ATM. Fabulous.


In respect of recent replies:

Laurent,
Of course I don't mind any suitable changes upstreamed (that can be
upstreamed). And things which are not-docker-specific should not be
presented that way (preferable all of them).

Providing that the functionality is added and it can be used with
docker too amongst other tools. Docker is not the only tool which uses
linux namespaces for containerization. And that is the underlying
kernel feature (available in all modern linux kernel). I missed saying
"try to upstream everything". Sorry - I agree it is a good idea to do
that.

Just the major requirement I am interested to see fulfilled (one way
or another) is a new single tarball build product / build target that
combines the 2 or more separate s6 packages into a single tar ball…
For the docker ADD mechanism to work.

That unified tarball does not need to be named 's6-docker' or anything
that is docker-specific. It does not need to be officially sanctioned
/ provided by upstream or not…

Upstream would be better of course but we don't wish to impose our
ways upon you!

We could also debate what exacty should or should-not be in that
single tarball. Or just not bother arguing specifics when there is
always the solution to make a 'light' and 'full' variant. With all the
optional tools included in the 'full' version. And just the minimum in
the 'light'. Where the 'light' appears to be 2 of your current
official tarballs.


John,
Sorry I don't see the point (anymore) of writing s6-specific base
images when there is no longer any pressing technical reason to do so.
The drawback of choosing that approach is that by publishing some s6
base images, we will always end up neglecting and leaving some out
other ones from being supported. Wheras with ADD (from a single
tarball source) - that supports all base images in one swoop without
any effort whatsoever on our part. And that is a big plus.

Of course, once the universal ADD mechanism is working, then it
becomes a completely trivial matter to roll new base images that
include s6, for whichever distros you wish. With just a single extra
line in the Dockerfile. But then it hardly seems worth it telling
people to use them rather than ADD, which other users can just do
directly themselves?

I just get the general impression that most Docker citizens strongly
prefer to use official base images whenever possible. Because it is
what they know and what they trust. Even if a user writes their own
base, they will almost always be FROM: ubuntu or FROM: debian (or
'alpine' now, whichever one they like the most).

Meaning that: it is harder to get the general docker population to
trust and switch over to some new 's6-*' base image coming from
somewhere which is effectively deemed as being a 3rd party repo.

If we instead tell them to use the ADD: <tarball_url> method… they
will trust it more because they all still get to keep their preferred
"FROM: ubuntu" line at the top as always…

At least that's my own thought process / reasoning behind such
opinion. Where I am coming at from, with this whole 'maybe we should
not don't do base images' anymore.




On Sat, Feb 28, 2015 at 5:57 PM, John Regan <john_at_jrjrtech.com> wrote:
> 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 skarnet.org 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 Sun Mar 01 2015 - 00:21:00 UTC