Re: process supervisor - considerations for docker

From: Dreamcat4 <dreamcat4_at_gmail.com>
Date: Fri, 27 Feb 2015 19:18:20 +0000

On Fri, Feb 27, 2015 at 5:29 PM, John Regan <john_at_jrjrtech.com> wrote:
> 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, I agree with all of your points (and reservations) here in last message.

And in retrospect, sorry for being a bit argumentative over that
entrypoint aspect of our discussion. You know, more people tend to
agree with your way of doing things than mine. But both approaches
have their own sets of pros + cons. I hope you can see that choosing
either one is actually a trade, and it just depends on which specific
aspects someone deems to be more important than there other ones.

Another thing I didn't say during that discussion, but was irking me
was that the point you were making was not actually a consideration
that was specific to s6 in Docker... Because you can effectively make
exactly that same argument in general and replace Gorka's '/init' with
just any interpreter such as 'python' 'ruby' or whatever… Meaning it
may be important to you and a valid point. But isn't so much of a
consideration that is specific to s6 alone. So I didn't see why it
should really matter as much in our discussion as these other things.
However I can totally understand the point you were making there (it
is a valid one), and where you were coming from. Again, apologies
about that.


>
> -John
Received on Fri Feb 27 2015 - 19:18:20 UTC