Thanks for writing such stuff. Too many images available today are just a pain in the ass to use!
Building Good Docker Images
51–60 of 70 posts
Re: Building Good Docker Images
#52Is minimizing the size of a docker image really the top priority? I would hold that making docker images easy to use, transparent as possible, reliable, versatile and easy to use (did I mention that already? oops) are far more important priorities. Admittedly, I use docker primarily for development/testing purposes and my use-cases are a bit different than the average production use-case, however, having a large tool…
yes, exactly how i feel too.
Re: Building Good Docker Images
#53Is minimizing the size of a docker image really the top priority? I would hold that making docker images easy to use, transparent as possible, reliable, versatile and easy to use (did I mention that already? oops) are far more important priorities. Admittedly, I use docker primarily for development/testing purposes and my use-cases are a bit different than the average production use-case, however, having a large tool…
+1
If it doesn't hinder runtime performace +/- 100MB of disk space is fairly benign. I understand how smaller images would be useful, but for my use case it doesn't help much.
Re: Building Good Docker Images
#54Is minimizing the size of a docker image really the top priority? I would hold that making docker images easy to use, transparent as possible, reliable, versatile and easy to use (did I mention that already? oops) are far more important priorities. Admittedly, I use docker primarily for development/testing purposes and my use-cases are a bit different than the average production use-case, however, having a large tool…
If we were talking about shaving a couple of bytes off a layer, I'd agree that attention might be better focused elsewhere.
However, I've seen (and am guilty of) a few of the pitfalls in the parent post. When you suddenly start adding 100mb+ unnecessarily to a Docker image, it can have some nasty ramifications in devspeed, and also deployments. A classic way to accidentally dramatically increase the weight of a Docker image is to apt-get install build-essential.
What kinds of ramifications you might ask? Well, I live in Australia. I don't know if Docker Registry has a CDN POP here, but that extra 100mb tends to take a solid minute or two longer for me to pull down.
Re: Building Good Docker Images
#55Is minimizing the size of a docker image really the top priority? I would hold that making docker images easy to use, transparent as possible, reliable, versatile and easy to use (did I mention that already? oops) are far more important priorities. Admittedly, I use docker primarily for development/testing purposes and my use-cases are a bit different than the average production use-case, however, having a large tool…
If you are making services small and having lots of them and redeploying often it matters more. If you just have one at a time maybe you dont care.
Re: Building Good Docker Images
#56Earlier quoted context omitted.
There's another gotcha in super-small images - things like "docker exec" will not work because there's nothing to exec. SSH-to-container becomes impossible. I think there's got to be a middle-ground - small (maybe O(tens of MB) max) but full-featured enough to have a simple shell and the ability to get debug tools. How small of a debian or fedora image could we get if we REALLY tried? 50 MB? 30 MB?
I thought there was a way to enter a namespace (googled this as I write the comment). Basically you have your shell and debug bits outside the container and make it appear as if it was inside it via nsenter [1]. I have not tested this, but will do that in a second. This might correct the situation you are thinking of. +--------------------+ | docker container | | w/ static bin | | [1] http://www.kevssite.com/2014/08/…
As of Docker 1.3 you can simply 'docker exec' :)
Re: Building Good Docker Images
#57Google takes this a step further and creates single binary containers with the minimal OS bits needed [1, 2]. Personally, I think this is where we need to be headed vs running a full blown ubuntu/debian/centos OS inside the container. Three benefits, 1) no OS to manage eg. no apt-get update or configuration management, 2) container has less of an attack surface (think shellshock -- the container does not have bash, w…
If you are willing to do abit of hacking you can do it.
For instance here is a gist I whacked together in a few mins that will build you a runnable Ruby intepreter with NOTHING else installed but it's required shared libraries. (Note this would not be fun to get say Nokogiri working in without knowing what you are doing)
https://gist.github.com/josephglanville/5a251002de7a4451210d
Re: Building Good Docker Images
#58Is minimizing the size of a docker image really the top priority? I would hold that making docker images easy to use, transparent as possible, reliable, versatile and easy to use (did I mention that already? oops) are far more important priorities. Admittedly, I use docker primarily for development/testing purposes and my use-cases are a bit different than the average production use-case, however, having a large tool…
It's not a question of size but a question of semantics.
If you dump an OS in a container you are treating it like a lightweight VM (and that might be fine in some/many cases).
If however you restrict it to exactly what you need and it's runtime dependencies + absolutely nothing more then suddenly it's something else entirely - it's process isolation, better yet it's -portable- process isolation.
Re: Building Good Docker Images
#59[deleted]
Re: Building Good Docker Images
#60The Docker hub is - after such a short time - an even darker place than the wordpress plugin registry and is already a source of security problems and a useless waste of bandwith, time and effort. Besides too many amateurs publishing BS, the real problem is that the company behind this is not taking responsibility to assure the quality of their containerized-app-store. This does not have to end in censorship, like our beloved Big Brother Apple does - some automated checks on each uploaded image could be a way to go plus a team of reviewers, that approves everything uploaded. Of course, the amount of information attached to any image currently is a joke, the whole hub is a one-day-of-work prototype that never should have been published in the first place in this premature state, but now it´s too late, so there is no other way than burning it down and restarting it with some more thinking before.
Much better concept would be: share layers, not images, based on verified base images with preinstalled saltstack. This effectively boils down to sharing good and up2date provisioning scripts.
There are some more conceptual problems with the whole docker idea that are rooted in a "need-to-productize-quick" infected thinking and do make everything seem immature and not really thought out - very basic problems that pop up with orchestration and networking should have been solved before releasing the product, now millions of half-assed "products" step into that gap and the result is a bizarr level of overcomplication of any infrastructure that was not possible before with virtualization alone, and still there are important things that "will be contributed in the future by somebody, hopefully".
Docker should not be a product itself with it´s own "market", but the basic docker ideas should be added to already existing concepts and inherit already existing infrastructure. The docker execution model should be a standard feature of any linux distribution with a standardized container modell (with some security added!) and the existing packaging infrastructure should be extended to handle what is needed to support it, including userspace updates and provisioning or on-the-fly rebuilds, so people can concentrate on writing provisioning scripts and not fighting another layer of system config BS. Getting rid of the VM is great, but building even more complicated overhead is totally absurd. Meanwhile something like Vagrant is a great thing to learn from.