On Sun, Mar 1, 2015 at 5:27 PM, John Regan <john_at_jrjrtech.com> wrote:
> Hi all -
>
> Dreamcat4,
> I think I got muddled up a few emails ago and didn't realize what you
> were getting at. An easy-to-use, "extract this and now you're cooking
> with gas" type tarball that works for any distro is an awesome idea!
> My apologies for misunderstanding your idea.
>
> The one "con" I foresee (if you can really call it that) you can't
> list just a tarball on the Docker Hub. Would it be worth coming up
> with a sort of "flagship image" that makes use of this? I guess we
Yeah I see the value in that. Good idea. In the documentation for such
example / showcase image, it can include the instruction for general
ways (any image).
===
I've started playing around with gorka's new tarball now. Seems that
that ADD isn't decompressing the tarball (when fetched from remote
URL). Which is pretty annoying. So ADD is currently 'broken' for want
it to do.
Official Docker people will eventually improve ADD directive to take
optional arguments --flagX --flagY etc to let people control the
precise behaviour of ADD. Here is an open issue on docker, can track
it here:
https://github.com/docker/docker/issues/3050
===
Until then, these commands will work for busybox image:
FROM busybox
ADD
https://github.com/glerchundi/container-s6-overlay-builder/releases/download/v0.1.0/s6-overlay-0.1.0-linux-amd64.tar.gz
/s6-overlay.tar.gz
RUN gunzip -c /s6-overlay.tar.gz | tar -xvf - -C / && rm /s6-overlay.tar.gz
COPY test.sh /test.sh
ENTRYPOINT ["/init"]
CMD ["/test.sh"]
^^ Where busybox has a very minimal 'tar' program included. Hence the
slightly awkward way of doing things.
> could just start using it in our own images? In the end, it's not a
> big deal - just thought it'd be worth figuring out how to maximize
> exposure.
>
> Laurent, Gorka, and Dreamcat4: this is awesome. :)
>
> -John
>
> On Sun, Mar 01, 2015 at 10:13:24AM +0100, 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 (
>> https://github.com/glerchundi/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:
>> https://github.com/glerchundi/container-base/blob/master/Dockerfile#L73-L75.
>> * 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...
>> -
>> https://github.com/glerchundi/container-s6-overlay-builder/tree/master/rootfs/etc/s6/.s6-init/init-stage1
>> -
>> https://github.com/glerchundi/container-s6-overlay-builder/tree/master/rootfs/etc/s6/.s6-init/init-stage2
>> -
>> https://github.com/glerchundi/container-s6-overlay-builder/tree/master/rootfs/etc/s6/.s6-init/init-stage3
>> * I've chosen /etc/s6/.s6-init as the destination folder for the init
>> scripts, would you like me to change?
>>
>> 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 <john_at_jrjrtech.com>:
>>
>> > 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 - 17:59:33 UTC