Hacker News Reader

Comment by cm2187 | Hacker News Reader

In what context would the 100MB-ish saved help a lot? It feels like such a tiny amount compared to modern storage capacity (the cheapest SSDs are like 100GB). And I wouldn't think of tiny devices (raspberry pi, etc) as good candidates for hosting lots of docker containers.

View on HN

It's a good practice nonetheless

It's not about only size (though getting something that's 10x-20x smaller is helpful)

It's about getting only what you need, reducing security issues, disk usage, memory usage, etc

Makes sense.

Impressive, I can't think of another time I've seen someone just acknowledge a response like that on the interwebs. Most Impressive.

in this case, it has little to do with storage cost and more to do with network transfer. when you're deploying an Ubuntu container to several nodes, your startup time is probably < 1sec for the app, and a lot more pulling down the image (most of which is totally wasted time)

the thing is, what do you gain out of using Ubuntu over alpine? chances are that its very little. the gains of using alpine are a more efficient, faster deployment system

But in a datacenter, the connection is most likely 1Gbit. Isn't the download time of the image insignificant compared to the boot time of linux?

well, if you have, say 10 nodes on AWS connecting to the docker hub the speed is definitely an issue, because let's be honest here neither are very fast at all

*edit: also, downloads don't just happen in a data centre. chances are your (or many) office connections just really... well, are not very good. also, think of Australia. please think of Australia (our internet is something of a dire situation)

I'm using slugrunner from flynn [0] for deploying my apps. This way I can share a base image, and each compiled slug is about 40mb for ruby apps and 10mb for golang apps. This is similar to how heroku works.

When I deploy, I generate the slug using slugbuilder, push it to a local storage on the same network, and each docker task is instructed to pull the "latest" slug from the slug storage. Containers start after a code update in a couple of seconds.

Continuous deployment can be easy achieved by copying slug from staging to production, similar to how pull docker image each time is currently done.

[0] https://github.com/flynn/flynn/tree/master/slugrunner [1] https://github.com/flynn/flynn/tree/master/slugbuilder

For me it shaves several minutes (about 80% of the total time) off a build/deploy cycle, which is huge.

build time and upload time (huge savings sometimes)

Once you have the base image though, there should be no real difference between alpine / debian / pick your poison. Docker isn't uploading the base image for every single push, and if you've pulled any other container that uses that base image, it's similarly not re-downloading it.

Reply on news.ycombinator.com