Here it comes Diamond base image #28
Conversation
Diamond is a proof of concept "Base Image", made with Buildroot: making Embedded Linux easy
As required by step 3 in "Contributing to the standard library - New repository".
Stackbrew ready, for contributing to the standard library
|
So I've got a couple thoughts here. The first is that this is a really cool idea. How did you manage to get smaller than busybox? The new busybox image is based on buildroot, and comes it at 2.489 MB, so I'm curious what you've got instead? Is it just a very minimal shell and that's about it? Did you use busybox but remove a bunch of the modules that get compiled in? What's the delta between this and the newer busybox image (if you've got the older image, you can get the new one easily by using One bit that worries me here is that your existing tarball isn't very audit-able. For example, your build script just calls Also very important (possibly even more important), we need to know that you'll be willing to maintain and support this long-term. If you just want an image you can share with others, the index is a much better place to do that. You might also be interested in "tianon/true" on the index (https://github.com/tianon/dockerfiles/tree/master/true), which comes in at 125 B total (yes, regular bytes). It's a proof-of-concept which is useful both for data-volume-only containers and for showing just what can be accomplished if you build your images |
Yes, my example was taken 2 months ago, on Dec 17th 2013 (first git push time). At that time busybox was 5MB and it was 6 month old (see the README snapshot). Moreover, I didn't realized that it is based on Buildroot at all (bear with me), at that time infact you built Busybox in another way I guess. Infact, that's not what it say your build script here: contrib/mkimage-busybox.sh, unless I miss something. If I run that script ( inside docker commit 3fda1819ee26857e4b30d0d033fd546eab77d6b6 - Date: Mon Feb 3 21:34:51 2014 -0800 ) it still builds up a busybox image aronud 5MB (to be precise 4.494 MB, this time), as you can see by my output here: lsoave@basenode:~/Github/docker$ sudo bash -x contrib/mkimage-busybox.sh ... ... + cp -a /dev/zero dev + tar --numeric-owner -cf- . + docker import - busybox 06f7fe0c81501332b6a93038adf98d3da3c56bccf39b53a3892cf1c35cc56496 + docker run -i -u root busybox /bin/echo Success. Success. lsoave@basenode:~/Github/docker$ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE busybox latest 06f7fe0c8150 8 seconds ago 4.494 MB diamond latest d7f6a6fe4763 17 hours ago 1.215 MB Anyway, I took the time to see how is it currently generated (via stackbrew) and it's quite different, I can confirm now is almost half a size: lsoave@basenode:~$ docker pull busybox Pulling repository busybox 769b9341d937: Download complete 511136ea3c5a: Download complete bf747efa0e2f: Download complete 48e5f45168b9: Download complete lsoave@basenode:~$ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE diamond latest d7f6a6fe4763 17 hours ago 1.215 MB busybox latest 769b9341d937 25 hours ago 2.489 MB
I just pulled a different source I guess, buildroot.net has several different git repositories and buildroot is different from busybox, even if it is based on that as well (not sure here, but this is what QUORA says about that). Anyway, the flow I used, is completly exposed in the README and into the diamond/diamond-build.sh and is reproducible by everyone to compare and see the diff ... I put it on gist: https://gist.github.com/lgs/8818150 TL;DR - DIFF:
Looking deeply yes,
Just follow Re-building instructions shown in the README, Select x86_64 when required by the GUI and exit as I said and youl have the same 1.215 MB Diamond image (rootfs.tar) to dig & diff into your local machine. So 'IT IS' audit-able.
Sorry for the misunderstanding but that's just a joke, an "hustle kind of kitsch marketing" let me say :-) and I'm ready to clean up all that, reducing the noise.
Yes, but for some reason index.docker.io doesn't trusted Diamond build, failing the build with an error that just gave me back an hash code ... not useful. All I can do is pushing my locally working diamond image as is currently: https://index.docker.io/u/lgsd/ ... no trusted index.
Yes I could and it won't take me more then a bunch of mins recompiling and keeping github in sync, ... anyway you know, "Men Plan, God Laughs" !
That's great man, I appreciate that and I couldn't imagine it was possible ( I should definitely take off that hustle README from Diamond repo ;-)
Jocks a part, it could be really useful to see some applicability examples and a little bit more of description on data-volume-only containers. That said, I think it should be better to keep Diamond off the official base images as you suggested. Just let me know, if it is possible, what's wrong with index.docker.io which fails the build ( I removed that failing build form index but you should have the logs from past few days ). This Docker project rocks |
|
Luca, if you can add the trusted build again, and send me the name, I'll take a look to see why it is failing. Sometimes they are minor issues that the tool has a problem reporting correctly Ken Sent from my iPhone On Feb 5, 2014, at 2:51 AM, "Luca G. Soave" notifications@github.com wrote:
|
|
@kencochrane sure, just scheduled another build: https://index.docker.io/u/lgsd/trusted-diamond/ still many thanks for your help |
|
... moreover, it should be great having a re-build process for "already existing" images. Then it could be possible re-build without changing the name or remove the previous ... or may be you can already, I don't know. |
|
@lgs Looked at the error, it is having a hard time cloning, Not 100% sure, but I think it is because of the size, when I clone the repo it is 524M |
@lgs not sure what you mean by this, could you give me more info for what you would like so that I can see if we do this or not already. |
|
@kencochrane you were right Ken, excessive size was due to buildroot tree and the issue disappeared as soon as I removed it from the repository. It was not necessary to keep it into the repo really and it was generated by running the tarmaker meta-builder each time I rebuilded rootfs.tar Now it's gonna be removed just before diamond/diamond-build.sh exit. The other thing was already in place: github-to-docker service hook, started the build queue on Docker Index, as soon as I pushed the repo on github, no need to redo or remove or rebuild manually the repo on DOCKER index. Everything ok, many thanks. |
|
@lgs thanks for taking the time to explain, and very glad @kencochrane got your trusted build woes taken care of! This build is definitely interesting, and so I'm happy to see that it's available as a trusted build for users to play with too. For your reading pleasure, the source for our current busybox image is https://github.com/jpetazzo/docker-busybox (as can be found in "library/busybox"), and it's pretty cool because jpetazzo used a separate "builder" Dockerfile to do the buildroot build inside a container as well. I'm sure he'd love any suggestions for how he can improve his builds. |
|
@tianon my pleasure, thanks to you too :) ... and about Jérôme yes, he is always a step ahead, scouting for new amazing solutions ... definitely a leading figure for the people outside your core staff. |
Written as a part of my editorial project: "Docker Essentials" e-book. Made with Buildroot: making Embedded Linux easy, Diamond is a proof of concept "Base Image" to use for embedding self contained small apps on top of lightweight Docker boxes.
Diamond is the smallest lightweight Docker container on the planet. With a footprint of 1.215 MB, it is even smaller than busybox.