4 ms·

Is 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, versat

Is 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 toolbox easily accessible for me to use (yes, including the ability to ssh into the docker container) is invaluable to me. I may be missing something here, but racing to make docker images "as small as possible" feels like a bit of premature optimisation.

jaequery 12y ago
yes, exactly how i feel too.
simi_ 12y ago
+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.
samcday 12y ago
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.
justincormack 12y ago
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.
jpgvm 12y ago
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.

jaequery 12y ago

yes, exactly how i feel too.

simi_ 12y ago

+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.

samcday 12y ago

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.

justincormack 12y ago

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.

jpgvm 12y ago

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.