On Sun, Mar 1, 2015 at 6:54 PM, John Regan <[email protected]> wrote:
> Quick FYI, busybox tar will extract a tar.gz, you just need to add the z
Ah right. It turns out that the default official busybox image
("latest") does not have z option yet. Because it is too old version
of busybox. I have kindly asked on their dockerhub page to update it.
> flag - tar xvzf /path/to/file.tar.gz
>
>
> On March 1, 2015 11:59:33 AM CST, Dreamcat4 <[email protected]> wrote:
>>
>> On Sun, Mar 1, 2015 at 5:27 PM, John Regan <[email protected]> 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 <[email protected]>:
>>>>
>>>>> 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
>>>>
>>>>
>>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
