[erlang-questions] erlang in docker from scratch

Peter Morgan peter.james.morgan@REDACTED
Tue Mar 29 08:46:34 CEST 2016


> On 27 Mar 2016, at 17:44, Nathaniel Waisbrot <nathaniel@REDACTED> wrote:
> 
>> When packaging an application as a Docker container it is too easy to just be lazy and put "FROM debian" (other distributions are available, replace “debian" with your distribution of choice). For sure it is going to work, but you have just included dozens of libraries and binaries that your application just does not need. An image that could be tens of megabytes is now at least several hundred – we are building containers not virtual machines here!
> 
> 
> There was a news story last month about Docker moving to Alpine Linux as its default base for this reason. 
> 
> I just don't see it, though. I'm using Docker _because_ I'm lazy. If I wanted to not be lazy, I'd build a proper RPM or Debian package. Just for example: you've got libc on the host machine to run Docker, but you're also going to have libc on your image. So if saving a few MB is a big deal, then Docker was a bad decision.
> 
> My thinking with Docker is, "I want to take a bunch of short-cuts, and I am willing to pay for them in disk space and a little CPU performance." So why should I care if my Erlang release has to drag along 500 MB of extra junk? Particularly when Docker's got this whole layers thing that works pretty nicely. I've got containers from 5 different images (Erlang, Erlang, Python 3, Node.js, Nginx) on one host and they're all lazily based on some 500 MB base image, which means that each image only has an amortized cost of 100 MB garbage.

In development I completely agree - do the simplest thing that works, and it doesn’t matter if it is 50MB or 500MB - it is more important to demonstrate that it can be done and quickly.

However, I think for the reasons that you outlined in the Alpine Linux story (https://news.ycombinator.com/item?id=10998667) - it quickly matters when people start picking a web tier from (say) Nginx that also includes a whole lump of ubuntu/debian/…, which is also then combined with a local middle tier that is also includes a whole lump of rhel/centos/sles/oracle linux . Containers quickly become like virtual machines, with a whole bunch of issues around patching and security that any Corporate is going to care deeply about.

In my original post I said that I was influenced by the way that Go applications are packaged. A move to Alpine will help make images smaller, but I wasn’t sure about support for musl versus glibc (http://erlang.org/pipermail/erlang-questions/2015-July/085344.html) with erlang? The official erlang docker image (https://hub.docker.com/_/erlang/) is based on debian:jessie at 747MB (the same size as Go’s) . Go statically links, so you can usually just copy a single binary into a “FROM scratch” image. I’ve not tried - but static linking erlang doesn't seem to be an option (http://erlang.org/pipermail/erlang-questions/2011-June/059231.html) and probably doesn’t make sense because there is more than one binary anyway (erlexec, beam, beam.smp, etc). So, in Erlang you either need to “FROM debian:jessie” to ensure you get the same runtime libraries you built with - which means an image size of at least 278MB (until Alpine comes along) or “FROM scratch” and copy with the runtime libraries with the release…

Or not use Docker...


> Are you doing embedded work? I saw a presentation about https://resin.io <https://resin.io/> that uses Docker on IoT devices and I could see where you'd worry about space when you're running a single Docker container on a Raspberry Pi. But, again, Docker seems like a strange choice there.

I thinking of the opposite scale - pushing a 50MB versus 500MB image to tens/hundreds of ephemeral nodes in a Swarm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160329/c869d76b/attachment.htm>


More information about the erlang-questions mailing list