Re: process supervisor - considerations for docker

From: John Regan <john_at_jrjrtech.com>
Date: Fri, 27 Feb 2015 11:29:59 -0600

Quick preface:

I know I keep crapping on some parts of your ideas here, but I would
to reiterate the core idea is absolutely great - easy-to-use images
based around s6. Letting the user quickly prototype a service by just
running `docker run imagename command some arguments` is actually a
*great* idea, since that lets people start making images without
needing to know a lot of details about the underlying process
supervisor. It's flexible, I know a lot of people like to initially
try things "on-the-fly" before sitting down to write a Dockerfile, and
this allows for that.

You're just getting caught up in some of the finer
implementation details, like the usage of ENTRYPOINT vs CMD vs
environment variables and so on, how to handle dealing with shell
arguments, these parts are solved problems.

So, onwards:

> * Convert Gorak's current "/init" script from bash --> execline
> * Testing on Gorak's ubuntu base image
>
> * Add support for spawning the argv[], for cmd and entry point.
> * Testing on Gorak's ubuntu base image
>
> * Create new base image for Alpine (thanks for mentioning it earlier John)
> * Possibly create other base image(s). e.g. debian, arch, busy box and so on.
> * Test them, refine them.

Everything up to here sounds fine and dandy - make some images and get
them out there, I'm all about that.

>
> * Document the new set of s6 base images
> * Blog about them

Also awesome.

> * Inform the fusion people we have created a successor

Hmm, I don't think that'll go over well, nor do I think it's really an
appropriate thing to do. Some people like the phusion images, for one.
The whole reason they exist is because a lot of guys keep trying to
use Docker as VM, and get upset when they can't SSH into the
container.

I don't see these as a "successor", rather an "alternative."

Besides, none of us would even be concerned about this if Phusion
hadn't made something in the first place!

> * Inform 1(+) member(s) of Docker Inc to make them aware of new s6-images.

Docker Inc isn't *that* concerned about what types of images are being
made. They'd probably get that email and say "..alright cool?"

The right approach (in my opinion) is to just build a really cool
product, then let the product speak for itself.

> Of course the proper channel ATM is to open issues and PR's on Gorak's
> current s6-ubuntu base image. So we can open those fairly soon and
> move discussion to there.

It might be worth starting up a github organization or something and
creating new images under that namespace. I can't speak for Gorak, but
the proposed image is sufficiently different enough from my existing
one that I'd have to make a new image anyways. My existing ones don't
allow for that `docker run imagename command arguments` use-case, for
me this constitutes a breaking change. I'd rather just deprecate my
existing ones, and either join in on Gorak's project, or start a new
one, either way.

>
>
> Another thing we don't need to worry about right now (but may become a
> consideration later on):
>
> * Once there are 2+ similar s6 images.
> * May be worth to consult Docker Inc employees about official / base
> image builds on the hub.
> * May be worth to consult base image writers (of the base images we
> are using) e.g. 'ubuntu' etc.

I wouldn't ever really worry about that. The base images don't have
any kind of process supervisor, and they shouldn't. They're meant to
be minimal installs for building stuff off of.

>
> * Is a possibile to convert to github organisation to house multiple images
> * Can be helpful for others to grow support and other to come on
> board later on who add new distros.
> * May be worth to ensure uniform behaviour of common s6 components
> across different disto's s6 base images.
> * e.g. Central place of structured and consistent documentation
> that covers all similar s6 base images together.

Yep, see my comments above. I'm all about that.

>
> Again I'm not mandating that we need to do any of those things at all.
> As it should not be anything of my decision whatsoever. But good idea
> to keep those possibilities in mind when doing near-term work. "Try to
> keep it general" basically.
>
> For example:
>
> I see a lot of good ideas in Gorak's base image about fixing APT. It
> maybe that some of those great ideas can be fed back upstream to the
> official ubuntu base image itself. Then (if they are receptive
> upstream) it can later be removed from Gorak's s6-specific ubuntu base
> image (being a child of that). Which generally improves the level
> standardization, granularity (when people choose decide s6 or not),
> etc.

They probably won't be that receptive - Gorak isn't changing the base
Ubuntu image *drastically*, but it still deviates from how a normal,
plain-jane Ubuntu install works. The base images should be as close to
stock as possible, since that's what most people will be coming from.
If the base Ubuntu image does something differently from an actual
base Ubuntu install, it's a broken image.

-John
Received on Fri Feb 27 2015 - 17:29:59 UTC