Quick FYI, busybox tar will extract a tar.gz, you just need to add the z flag - tar xvzf /path/to/file.tar.gz
On March 1, 2015 11:59:33 AM CST, Dreamcat4 <dreamcat4_at_gmail.com> wrote:
>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
>>> >
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Received on Sun Mar 01 2015 - 18:54:39 UTC