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 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 <j...@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 > >