Hacker News Reader

Comment by lox | Hacker News Reader

Do we really need to brand using smaller containers as microcontainers? Why not submit these as pull requests to the official docker images rather than introducing more fragmentation?

Also worth noting that the official docker images are moving towards alpine. Of course if you have ruby or node apps your biggest space hog is still going to be your packages.

View on HN

There's also a very good reason to not move some things to alpine, including ruby and node applications. A significant number of ruby and nodejs apps depend on some c/c++ code hidden away in this module or that gem. Any time you're compiling c/c++ code, you run into a chance of musl vs libc causing differences.

These differences can range from building requiring different options to the application having strange performance characteristics to random crashes (rare!).

In addition, people who write these modules typically test against an ubuntu or debian system, so those are much safer bets. Alpine makes no serious attempt to match packages with those, either in breadth nor version.

It really isn't feasible to unilaterally move people, and for compatibility reasons Docker does not often change tags in such a drastic way.

The official docker images are often offering alpine alternatives in different tags, which is not the same as "moving towards" as you remarked.

We are in fact moving towards alpine, but can't just switch the default tags overnight in case some users depend on the properties of certain distros.

excited to see recently added support[1] of dns search domains in musl (and therefore Alpine).

[1] http://git.musl-libc.org/cgit/musl/commit/?id=3d6e2e477ced37...

Alpine is an option in some cases, but, like you said, it's not always straight forward. Native application modules, 3rd party OS packages and the overall package echosystem differences are important factors that need to be considered. This is why DockerSlim [1] was created. You use a regular distro like Ubuntu and you still get micro containers! Note that the sample node microcontainer with DockerSlim is 14MB and in this post it's 29MB :-) It uses hapi.js instead of express.js though, but it's probably not the main reason for the size difference.

[1] http://dockersl.im

Sure, but you have it the wrong way around. The default should be slim and Ubuntu/Debian/etc should be an alternative.

https://news.ycombinator.com/item?id=11000827

One solution would be to have a "build" image that produces your binary or set of packages you need and then a "service" image that actually runs it.

In general, I agree with this, but it specifically doesn't help with issues where glibc vs musl matters.

Either your build image's libc (musl in this case) is statically linked in and you have the aforementioned issues, or it's not statically linked and your binary won't run. Most things compiled within an ubuntu container won't run in an alpine one; you specifically have to go out of your way to make that so.

Agreed. Docker was suppose to inherently be about small containers. Vendors just choose to use the largest Linux base image out there.

I agree, they are still docker images, they have less stuff inside. I didn't know about Alpine, so I'm going to start down that path. Working on Lua based applications, hoping to see if Alpine will work.

Reply on news.ycombinator.com