Super small Docker image based on Alpine Linux

https://github.com/gliderlabs/docker-alpine/tree/d751bb2bcacd2a6536280cdc7d313bc6584aa40e

by antouank • 11 years ago

261 159 11 years ago

Although not clear from the GitHub link, this is actually the official Docker image of Alpine: https://hub.docker.com/_/alpine/ - see the Dockerfile links.

okasaki• 11 years ago

Interestingly, alpine doesn't use systemd.

bespoke_engnr3• 11 years ago

Why is this downvoted? It is interesting (and worth pointing out), since not using systemd is different from every "enterprise" Linux distro out there.

mrmondo• 11 years ago

Sorry that was me, when I read it I thought it was a snarky 'systemd vs bla' comment, upon re-reading I see that you could well be correct so I appologise for that, I will be less hasty next time.

jlappi• 11 years ago

Alpine really wouldn't fall into the Enterprise category due to it's small size and developer pool. It's a great community project that I wouldn't doubt has some form of corporate support financially.

rakk• 11 years ago

Personally I don't miss it. IMHO the alpine image is perfect to run single services that don't have too much dependencies. On your host system you can use systemd to spin up these services as docker instances (if you don't need scheduling).

dbalan2• 11 years ago

I'd like to point out that a docker container, usually doesn't run an init system. [I get that OP was talking about standalone alpine]

forgotpwtomain• 11 years ago

I remember reading centos tried to make systemd available in docker containers briefly but went back on it due to bugs (not sure if they were ever resolved). I've seen containers that need init management using supervisord.

kgilpin2• 11 years ago

We use phusion baseimage, which does have an init system (runit). We have been happy with that. Our customers are not ready for us to provide our product as 6 distinct linked docker containers. The image we build is more like a VM in that it contains multiple processes (pg, nginx, and some apps/services).

mkobit• 11 years ago

I am not sure if I saw it HN recently, but there is an article by Phusion [1] talking about the init process and how to handle it with Docker. They have a base image, baseimage-docker [2], that is supposed to solve that problem.

[1] https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb... [2]: https://phusion.github.io/baseimage-docker/

vezzy-fnord• 11 years ago

Does upstream systemd build on musl now?

CSDude• 11 years ago

Alpine's size combined with its simple package manager is great, I use it for easy image pull, but of course it lacks some packages.

mickael-kerjean• 11 years ago

Sounds great. Will definitely give a try !

simula67• 11 years ago

Interesting to see Alpine, which began life as an embedded linux project is now being used for server deployments. This has to be a win for open source style of projects. Also reminds me of the time when Kroah-Hartman mentioned that people working on embedded linux ended up improving power efficiency of Linux saving the data center guys tons of money.

npsimons2• 11 years ago

Also reminds me of the time when Kroah-Hartman mentioned that people working on embedded linux ended up improving power efficiency of Linux saving the data center guys tons of money.

This right here. There's so many here decrying Alpine who can't see the bigger picture: having options for different Docker deployments will create possibilities currently undreamt of. Maybe you can't use it on your project; fine, keep on keepin' on with what suits you best, but don't knock another project just for a different approach, especially when it might have huge benefits to the overall environment in the future.

blorgle• 11 years ago

Alpine is so cool. grsec, musl libc, openRC. If you are sad about the direction most distros are headed, Alpine represents a good stab at "the way things should be".

smcleod• 11 years ago

Alpine is a great example of a lightweight, container first approach.

Please stop using Ubuntu as your base images people!

There's no excuse for using a full Linux distribution (especially one that's really aimed at the desktop) for a container unless you're doing a staged migration or something along those lines.

* Edit: Formatting.

mbrock• 11 years ago

No excuse? How about it works well enough? It's a semi-consensus, if you've used any other Docker image you already have the base downloaded, the distribution is familiar and everything offers Ubuntu debs. If you like Alpine that's cool, but why do people always have to make strong prescriptive claims out of their opinions?

nickpsecurity• 11 years ago

"and everything offers Ubuntu debs"

This, great hardware support, and decent stability are the main reason I use Debian-based distros. Almost anything is a deb away.

wtbob3• 11 years ago

Please stop using Ubuntu as your base images people!

I think Ubuntu images are a symptom of a much more serious disease: Ubuntu usage in general. Ubuntu is not really concerned with software freedom (its origin was Debian-plus-proprietary-blobs), nor does it strongly care about privacy (although it can be shamed into doing the right thing), nor does it care terribly much about getting along with everyone else (c.f. Mir vs. Wayland).

As a distro for my family, it's fine. But I expect my fellow developers to run something which indicates more technological prowess than does Ubuntu: Debian or Arch or Gentoo or Slackware are all good choices for different reasons.

_Codemonkeyism3• 11 years ago

I've run Ubuntu for some years, mostly because software was newer in Ubuntu than Debian (which I've used before).

With One-Service-Per-Docker I think about migrating back to Debian, as I can chose the version of my service myself (with curl if needed) and don't need the newest versions in my base image.

I have the feeling with Docker over time Debian might have a comeback.

rdtsc2• 11 years ago

Except that Ubuntu provided a decent Linux on my desktop that is relatively polished to be used by a normal human being.

I did more than Debian, Redhat, Mandriva, Gentoo and other could do even though they had a longer head start.

Once I run that on my desktop, I don't really want to learn another distro, I'll just use that the server as well.

run something which indicates more technological prowess than does Ubuntu:

There one difference between how I develop -- I don't develop to show my technological prowess, in fact when I do that, I start making mistakes and generate complicated and hard to maintain systems.

falsedan• 11 years ago

WARNING TERRIBLE NERD JOKE APPROACHING

    Hey, what does 'Ubuntu' mean anyway?
    It's a South African word meaning, "doesn't know how to install Debian"

bespoke_engnr3• 11 years ago

I like this. It makes a lot of sense to use something like Alpine Linux for Docker images. If you're going to build a 'process container' like Docker -- something that does not encourage the same mindset as a traditional container or VM -- it makes sense to start with a stripped-down operating system and then build it up to be exactly what you need.

Perhaps loud suggestions like these are necessary due to a bias in the group that uses Docker. 20% people that really know what they're doing and have chosen Docker for a specific reason, and the hangers-on who try to emulate them by using the same tools.

Docker is an interesting, useful, and extremely overhyped tool. I may be wrong, but I feel like its popularity has caused a bunch of people who don't really need Docker to use it. Besides popularity, they can't really explain why they are using it over something like LXC or FreeBSD jails.

I imagine (again, no data to back this up) that this same large percentage of people are also the ones that just keep using the default Ubuntu image once they finish the "Get Started" tutorial.

I'm glad to see suggestions like this gaining popularity. If you're going to make the most of Docker, I think there's value to be found in really committing to the mindset of a 'purpose-built, no-frills environment for running a single process.'

From what I can tell right now, a huge number of people are using Docker "sort of like a VM but you need more of them, and Git is integrated and you have to tell it to do something or it stops running".

rockyj• 11 years ago

Alpine linux is great, however lack of JDK (needed for Java/Scala/Clojure/JRuby/Groovy projects) keeps me from using it. Hopefully this can be fixed soon :)

Huggernaut• 11 years ago

Why can't you build an image with the JDK based on Alpine and use that as your base image for everything else?

rickycook5• 11 years ago

glibc. alpine uses musl, and from what I understand this is actually not a thing you can do very easily. not that I use jvm in an way (thankfully)

at the very least, it's probably not worth spending too much time on, because you'd get better optimisations from doing other things

creshal• 11 years ago

I haven't yet used Alpine, but from its wiki it seems you can easily create the packages yourself?

woadwarrior01• 11 years ago

I remember seeing a blog post[1] about getting JRE running on Alpine containers.

[1] https://developer.atlassian.com/blog/2015/08/minimal-java-do...

ddispaltro• 11 years ago

This is pretty helpful and what I've used.

https://github.com/anapsix/docker-alpine-java

kenOfYugen2• 11 years ago

Anybody using Alpine for a minimal Desktop OS? How does it compare to something like Arch?

nextos• 11 years ago

I gave it a try, but it's a bit less well documented and has less packages than Arch.

If heading this route, perhaps Guix or Nix are a nice option too. As you can get something declarative and with traceable builds.

I'm hoping a minimal distro that has a nix-like package manager gets mainstream soon.

kenOfYugen2• 11 years ago

Thanks! I'll give it a try then and maybe Nix too!

iheartmemcache2• 11 years ago

You can use the Guix package manager on top of any distribution and get declarative builds. https://www.gnu.org/software/guix/manual/html_node/Invoking-... Like the main GNU page says, it's not distribution ready, but it's close. In fact if you run it on top of Arch (just install the minimal requirements via pacman, then defer to guix) or Alpine you've pretty much got your minimal distribution with declarative package management.

neopallium• 11 years ago

It would be nice if most of the package manager and basic shell commands could be kept out of the docker image too. I think this would require a utilities image that could be mounted during the build of the docker image. Some images would still require a shell for startup scripts or other tasks, but they can include them when needed.

cm21873• 11 years ago

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.

rickycook5• 11 years ago

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

cm21873• 11 years ago

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?

redka• 11 years ago

build time and upload time (huge savings sometimes)

awinder• 11 years ago

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.

raverbashing• 11 years ago

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

cm21873• 11 years ago

Makes sense.

andor436• 11 years ago

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

nickjj3• 11 years ago

I think one of the main problems with Alpine adaption is due to how the official run-times are set up on the Docker hub.

- Python-slim uses debian:jessie

- Ruby-slim uses debian:jessie

- Node-slim uses debian:jessie

Your web application is probably going to pull in from one of those run-times which automatically sets you up to use jessie.

I'd also like to see someone take a random large project and see if their native extensions compile under Alpine without any other dependencies and to compare the final image size of a real world web app with alpine vs jessie.

It's sort of a micro benchmark to compare it like this because a project with 75 gems/packages and a couple of native extensions that need to be compiled will drastically increase the size of your image, with or without Alpine.

I absolutely do think it's worth optimizing your images, but this seems like something that may end up being quite personal to your app because it will require a bit of tinkering to get everything your app needs to work. I also wouldn't bother doing it until I was constantly pulling them down in production to auto-scale.

rickycook5• 11 years ago

actually, in this case it totally makes sense. the issue is that alpine uses musl, and many things only compile for glibc. if you're writing in any of those languages, chances are you're going to install a library that requires some c compilation (yaml parsing, database libraries, numeric processing, etc) and this becomes an issue

*edit: which is what you were saying all along, and this didn't sound enough like "yes I agree"

nickjj3• 11 years ago

Yep, that is true. I can't remember the last time I worked on an app that didn't require compiling 1 or more dependencies.

As for the edit, sorry about that. I edited my comment about a minute after posting it.

justincormack2• 11 years ago

Go has official images based both on alpine and wheezy, so you can choose https://hub.docker.com/_/golang/ in case you have issues with C extensions. Most upstream projects are happy to take patches to work with Musl, and with docker it is much easier to replicate issues than it used to be when you had to install the distro.

niccaluim• 11 years ago

Have you had trouble with any specific libraries? We're using alpine-based images with statically-linked binaries and haven't had any issues compiling third-party libs. One area you're likely to run into trouble is RPC, but I only discovered that in messing about with something experimental.

The real problem with musl in these environments is its DNS behavior, particularly if you're running on a platform like Kubernetes that uses DNS search domains for service discovery. Not hard to work around, but the workarounds are a bit, er, inelegant. See http://www.openwall.com/lists/musl/2015/09/04/4 and https://github.com/gliderlabs/docker-alpine/issues/8

mfenniak• 11 years ago

I'm pretty new to Docker, so I'm curious about "a project with 75 gems/packages and a couple of native extensions that need to be compiled"...

Is the common procedure in the Docker world to build an application image that includes all the build tools that were used to build native dependencies? That seems like it does generate a pretty large image.

I figured I'd take a three-step approach to my first node.js app in Docker:

1. Build an image to build my dependencies. This uses the same base image as step #2 will, but installs all the development tools and libraries (eg. build-essentials, libpq5-dev), and then outputs a .tar.gz to a shared volume containing my node_modules folder.

2. Build an image with my dependencies; imports the runtime versions of any libraries (eg. libpq5), imports & expands the .tar.gz generated by #1.

3. Build an image with my application, FROM the image in #2.

The process is optimized by having the automation check for the existence of #2 by hashing the contents of the relevant Dockerfiles, and the package.json list of dependencies, and doing a `docker pull` with that hash to see if I've already built #2. If so, my build just needs to build #3.

It's a bit more complex (Hello, everything in Docker-land), but ends up being pretty powerful. But your post makes me think I've over-complexified it a bit.

kgilpin2• 11 years ago

My suggestion is to build a package installer for your app and use that to build the final image. For example, we use fpm (running in a container) to build .deb packages, then we push those to an apt repository (artifactory) and then build images downstream using apt-get.

Initially we did a lot of cloning from source and compiling/installing dependencies, but it's very slow, there's a lot of wasted time in rebuilding identical code, and it's hard to provide patches and upgrades to customers.

rcarmo• 11 years ago

I simply build all required packages externally to the container and then bake the resulting binaries into the image by adding the requisite file trees. Fairly easy to script after the first two or three attempts, really.

nickjj3• 11 years ago

Yours isn't overly complex, it's one way to trim down an image. However, it is a lot more complicated than just defining 1 Dockerfile that at least copies in your package.json file separately to speed up future deploys that don't touch your packages.

I guess I just don't see the time vs. effort value in optimizing most smaller projects.

For example, that 75 gem project may take 5 minutes to build once but after that it takes 10 seconds to build and push a version that updates the app code.

I'm ok with this pattern for most of my projects because you can easily get by with 1 host to serve tens of thousands of requests a month on most typical projects. It's not like I'm spinning up and destroying dozens of instances a day where the network overhead is a legit concern (if I were, then I would optimize).

fidget2• 11 years ago

Except, well, I don't care. All my images derive from ubuntu, so I pay the download cost once, due to docker having this whole delta thing going on, and storage cost really isn't a problem. Developers know how to apt-get usually, so that's less support cost on me. In fact, most of them run ubuntu themselves, which is a massive help with dev to prod parity. Oh and of course, there are more packages and a whole lot more forums/community etc etc.

exo762• 11 years ago

This thread needs to get nuked by admins. Amount of "downvote because I disagree", "upvote whatever because hype" is astounding. Your response is an example. It's better articulated then many others [0], [1] and yet it was downvoted to hell. Groupthink is strong.

[0] https://news.ycombinator.com/item?id=10783021 [1]: https://news.ycombinator.com/item?id=10782946

Gigablah3• 11 years ago

You're seriously suggesting censorship as a counter to "groupthink"?

Gigablah3• 11 years ago

so I pay the download cost once

Not if you're spinning up new hosts via autoscaling.

fidget2• 11 years ago

Sure. I'm still paying it once per box lifetime, which really isn't too bad. And given I'm orchestrating stuff etc etc, I can use fairly large boxes and get quite a lot of work out of one lifetime.

dbalan2• 11 years ago

But there are cases in which you'll have to decide not to use alpine. If your application and library needs glibc support, you are pretty much your own - and you have to patch the build scripts to use the busybox tools rather than the gnu ones [eg, sed and other tools].

justincormack2• 11 years ago

You can install the Gnu tools in alpine, at which point they replace the busybox versions. They are all packaged up, just not installed by default.

cdnsteve• 11 years ago

Alpine looks great and has grsecurity baked in.

I've been struggling to find a lightweight PHP image, they're all huge. I'm starting to see a big advantage for Go in the container world where I've seen containers 10MB in size instead of the 200-600MB I'm getting in Python, PHP or Ruby. The nature of these dynamic languages and their libraries I guess.

mverwijs5• 11 years ago

Grsecurity is a patch on Linux. The kernel. As far as I know this does nothing for a container unless your container host runs Alpine.

coleca• 11 years ago

Alpine Linux looks great. Unfortunately there is an outstanding issue (https://github.com/gliderlabs/docker-alpine/issues/8) with its DNS implementation that makes it tough to use in Kubernetes or similar environment that uses DNS for service discovery.

It does look like a fix is on the way though.

mhd• 11 years ago

Alpine Linux has a much more complete and update to date package index
...
(5/5) Installing nodejs (0.10.33-r0)

They should really update their examples, as that makes it look worse than it actually is (the current repository contains 4.2.3).

And while I'm at it: "use % as a wildcard" on the package page? Really?

purpled_haze• 11 years ago

Would Alpine be the best idea in-general to use as a replacement for Ubuntu even when not using Docker? What are you giving up by going with Alpine?

Since I've never even heard of Alpine before today, I'd say you are at the very least giving up on a community of users and support, but maybe Alpine will gain a large community and this is the start?

techietim• 11 years ago

For anyone who is using Digital Ocean, I have written up a little guide on how to install Alpine directly onto a droplet:

https://github.com/bontibon/digitalocean-alpine

hathym• 11 years ago

I'm currently using rancherOS, it's awesome!!

hharnisch• 11 years ago

Alpine Linux has been a fantastic choice for docker images. Small, light and has a package manager that keeps getting better. I had one big snag using it with kubernetes, DNS based service discovery didn't work (https://bugs.alpinelinux.org/issues/4371). The work around was fairly simple and used env vars, but if you dig on this bug I'm not sure when (if ever) that will get fixed.

hendry• 11 years ago

What's the difference between FROM gliderlabs/alpine & FROM alpine:latest ?

Love Alpine though I did run into an annoying nginx permission issue: http://lists.alpinelinux.org/alpine-user/0002.html

Gigablah3• 11 years ago

They're more or less the same, just that gliderlabs/alpine includes the apk-install convenience script that removes the apk cache for you.

Although with 3.3 that isn't necessary anymore if you use the --no-cache flag.

kstenerud4• 11 years ago

Size is such a tiny concern. I'm surprised people make such a big deal about it. When all of your images use the same base, it's only a one-time cost anyway.

And there are FAR more important concerns:

- Are the packages in your base system well maintained and updated with security fixes?

- Does your base system have longevity? Will it still be maintained a few years from now?

- Does it handle all of the special corner cases that Docker causes?

That's why I use https://github.com/phusion/baseimage-docker

_Codemonkeyism3• 11 years ago

"Will it still be maintained a few years from now?"

What would you suggest? Debian? Ubuntu LTS?

kstenerud4• 11 years ago

Both. Debian is the gold standard of long term support, and Ubuntu is a stable company that builds upon this. And that's why I approve of phusion/baseimage being based off it.

e40• 11 years ago

Or CentOS 7 (Docker is not supported any more on 6.x).

_yy5• 11 years ago

As a sysadmin, I fully agree. I shudder at the thought of using Alpine Linux (or Arch Linux, or...) in production.

The value that stable, long term support distros provide shouldn't be underestimated.

krisdol2• 11 years ago

We use Alpine Linux for our applications and I like it, and I too shudder at it being used for the entire production system. As a sysadmin, you can still administer the LTS distro that hosts the docker containers and whatever other pieces of the stack you interact with. Alpine Linux containers, like any other container, should host an instance of an application (maybe not even that, depending on how complex the application is) -- not the entire production server, not SSH keys, not iptables, firewall rules, etc.

anonbanker2• 11 years ago

Using Gentoo stable in production right now. I'm in charge of how long a package is supported now. All execs get a brand new gentoo machine built with binaries compiled by myself.

You wouldn't believe how fast you can get a gentoo machine up and running compared to other distros. Build for a minimum common architechture (all intel binaries are based on Sandy Bridge, all ARM based on Rockchip RK3088), and installing for new computer is little more than untarring a bunch of binaries to /. My record is 5 minutes for a full KDE Plasma 5.5 software stack.

koffiezet5• 11 years ago

Sorry - but the phusion images are unnecessarily bloated. The existence of the them has been defended by 'fixing' many so-called problems that are actually no problem at all - or at least shouldn't be a problem if you know what the hell you're doing. No well, written software won't spawn zombie-processes - sorry. Reaping dead child processes is something pretty basic if you're using "fork".

And then - a logger daemon. Guess mounting /dev/log into a container is too complex if you care about this?

Logrotate - sure, useful - but if you care about logs and aren't sending them to your logger daemon or /dev/null, you probably want to store them externally - in a volume or mounted host directory - and have a separate container taking care of that.

The ssh server... Containers are no vm's, if you have to log in on a container running in production - you're doing something wrong - unless that container's only job is running SSH (which can be useful for example for Jenkins build slaves).

Cron - again - same thing: run in a separate container and give access to the exact things your cronjob needs.

That is for me the essential thing about containers: separate everything. But sure, you could treat containers as a special VM only for one service - nobody is going to stop you. I however prefer isolating every single process and explicitly telling it how to communicate with other processes. It's sane from many perspectives: security, maintainability, flexibility and speed.

detaro2• 11 years ago

Agree in general, but you can overdo it with splitting services up. E.g. would you really run a extra container just for a cronjob that runs once a night to e-mail some data from a database? Esp. if you run on a platform where you essentially pay per container that seems like a waste.

kstenerud4• 11 years ago

Yeah that's cool, but my main point is that images which make use of the stable debian package system and are actively maintained are a better approach than an image that makes use of more obscure technology that could be abandoned, or worse, maintaining your own container infrastructure.

No well, written software won't spawn zombie-processes - sorry.

And yet it happens.

The ssh server... Containers are no vm's, if you have to log in on a container running in production - you're doing something wrong

The SSH server is incredibly useful for diagnosing problems in production, so I for one applaud it (although it's not really necessary anymore with docker exec).

Cron - again - same thing: run in a separate container and give access to the exact things your cronjob needs.

Or just run it in-container to keep your service clusters together.

That is for me the essential thing about containers: separate everything.

It's a question of degree. Where you draw the line is almost always a personal, aesthetic choice.

waffle_ss2• 11 years ago

Some things you really can't split into one-process-per-container. Like how WAL-E needs to run alongside the Postgres daemon (or at least, I was unable to get it to run otherwise). You might argue you shouldn't run Postgres in a Docker container, but that's just one example of IPC you can't delegate to shared files / TCP ports.

The real problem with splitting things into a bunch of containers is that the story around container orchestration is still poor. Kubernetes is the leader here, but running a production-ready cluster takes some work (besides Google Container Engine, there are some nice turn-key solutions for spinning up a cluster on AWS but they come with short-lived certificates and rigid CloudFormation scripts which create separate VPCs; so you have to setup your own PKI and tweak CloudFormation scripts).

SrslyJosh• 11 years ago

Containers are no vm's

A container is whatever you want it to be. Single process? Sure. Full OS? Sure. Somewhere in between? Sure.

Containers are not new technology, and they were not invented by Docker or Linux. An artificially-constrained view of what a container is (or should be) that's driven by one tool's marketing (Docker) isn't helpful.

logician762• 11 years ago

Container size influences memory usage, which is an important concern:

http://www.stackengine.com/container-memory-usage-or-size-ma...

kstenerud4• 11 years ago

I'd be careful about drawing conclusions from those tests. We know that the number of bits in a container does not directly influence how much RAM it consumes. Therefore, there must be something the images are doing that consumes memory which is not happening in the "smaller" images. The key would be to find the culpable process or daemon(s).

indexerror• 11 years ago

Are you sure that is the general case? I have no reason to believe that this is true in general.

ploxiln4• 11 years ago

Size of programs, in terms of disk, memory, cpu time, and network usage, is bloated by multiple orders of magnitude by all the confused people who think the only thing that matters is "developer productivity". Maybe 20% is worth sacrificing, maybe 50%, but 100x? 1000x? It all adds up.

One really easy and relevant example, sizes of docker images for running memcached:

  vagrant@dockerdev:~$ sudo docker images | grep memcached
  memcached                     latest              0868b36194d3        2 weeks ago         132.2 MB
  sylvainlasnier/memcached      latest              97a88c3744ef        13 months ago       297.4 MB
  ploxiln/memcached             2015-07-08          aa4a87ee2c05        5 months ago        7.453 MB

(that last one is my own, the other two are the two most popular on docker hub).

As another example, a co-worker recently was working with some (out-of-tree) gstreamer plugins, and the most convenient way to do so was with a docker image in which all the major gstreamer dependencies, the latest version of gstreamer, and the out-of-tree plugins were built from source. The offered image was over 10GB and 30 layers, took quite a while to download, and a surprising number of seconds to run. With just a few tweaks it was reduced to 1.1GB and a handful of layers which runs in less than a second. It was just a total lack of care for efficiency that made it 10x less efficient in every way, enough to actually reduce developer productivity.

Size matters.

voltagex_• 11 years ago

Are you able to share any of the tweaks that were used?

npsimons2• 11 years ago

the confused people who think the only thing that matters is "developer productivity".

Developers, especially good developers (or hell, even just competent) are more than worth the effort put into improving their productivity, and the good ones will usually intuitively have a grasp of the XKCD time trade-off graph and reduce or eliminate delays themselves given the chance.

That being said, even in this day and age of extremely cheap cycles, non-volatile and volatile storage, and insane throughput, making something like VM/chroot images smaller can lead to higher productivity in that you can spin them up faster, or spin up tons more in paralell than you would normally think of. Having the option to do such can help shape alternate modes of development and open up possibilities previously undreamt of ("spin up 1000 docker images? Can't do that because they each need 200MB RAM and I only have 32GB of RAM").

technion2• 11 years ago

Size of cruft aside, there's value in discussing whether such cruft should exist.

It's normal for common tools to be SUID root - it's necessary for operation on a normal machine. Do you really need 30+ SUID binaries inside your Docker container built for one thing?

Docker seems to present an ideal situation for stripping such potential exploit vectors back.

ejholmes• 11 years ago

Having been running Docker in a production system now for 6+ months, the size of the images is really a non-issue if you're using the Docker layer cache effectively. We use all of the official language images and builds are under a minute, with deploys happening in ~5-10 seconds (machines generally only need to download a single layer).

thrilleratplay• 11 years ago

For simple containers, this is a great base image. I have been using it for an rsync server for a few months. https://github.com/Thrilleratplay/docker-ssh-rsync

The only problem is that the package library is not as extensive as Ubuntu or Arch. https://pkgs.alpinelinux.org/packages

_euvw2• 11 years ago

Why not? Let's run the numbers.

* http://wiki.alpinelinux.org/wiki/Special:ActiveUsers

14 active users. That is not a lot. In fact, that is tiny. Maybe their redmine has more? http://bugs.alpinelinux.org/projects/alpine says 16 users in the 'developers' group.

But maybe they're very pro-active on the mailinglist? Let's check their security announce list:

* http://lists.alpinelinux.org/alpine-security/

1 message. From 2009. Hmm. Well, their alpine-devel list then? 5110 messages in 10 years. 9 Messages per week. By comparison: the debian developers mailinglist had 492 messages in November 2015 alone.

So even though Alpine Linux looks nice and lean, it is maintained by a very small group of developers.

Now. If building your own container were very very hard, I'd sure understand grasping for something like Alpine.

But here's how you build an Ubuntu Trusty container:

     debootstrap --variant="minbase" --include="systemd-sysv" trusty ${TMPDIR} ${UBUNTU_MIRROR}
     chroot ${TMPDIR} 
     dpkg-divert --local --rename --add /sbin/initctl
     ln -sf /bin/true /sbin/initctl
     dpkg-divert --local --rename /usr/bin/ischroot 
     ln -sf /bin/true /usr/bin/ischroot

Just tarball it and throw it in 'docker import'. Your done.

Need to add or remove software? Use Ansible to configure specific containers with specific confgurations.

Need security-updates? chroot into the folder, apt-get update; apt-get upgrade.

Throw the new tarball into docker import again. You use long-term supported methods and systems. There are tens of thousands of packages. Bazillions of PPAs to use.

Edit: typo in codesnippet

woah• 11 years ago

You're probably right, but have you ever thought that maybe Debian has so much mailing list activity because it is such a huge project? There's something to be said for lightweight software. Of course, workaday devs should use the accepted best practices, but can't people experiment with better techniques until they have been proven out?

mverwijs5• 11 years ago

A huge community and installable packages does not mean you need to use all those packages. The smallest container I've built is about 90MB, using Ubuntu. That is pretty lightweight. Of course, the container doesn't actually do anything....

Another thing to consider: if you software works inside you self-built Ubuntu container you can be pretty sure it works on any Ubuntu install anywhere. Even if your company does not use containers everywhere, your developers can.

Edit: typo and sentence finishing.

nalck• 11 years ago

OpenBSD is likewise developed by a small number of users. A Linux distribution is arguably easier to maintain for a smaller group because the core components are developed upstream.

Alpine does well at making security measures like SELinux accessible. Meta-distributions like Debian serve a different purpose.

mverwijs5• 11 years ago

Alpine Linux supporting selinux is only relevant in this discussion if you run Alpine as the container host. To the Alpine containers it is of no consequence.

OpenBSD has more than a great track record on security, maintainability, community spirit. As has Debian.

Alpine, after ten years, was simply not on the radar as a distro.

It is merely developers that do not seem to care about the actual systems these containers are built from that find Alpine interesting.

It's small, so even on a 3g connection you can download those containers and get the functionality a developer seeks. Fast. And that is fine. It gets alpha code out in a timely manner without too many resources.

Just do not pretend that this way of working will deliver sustainable, maintainable and consistent code that will work just as well inside as well as outside containers.

Maintained, secure, stable and proven distributions have served any purpose given in the past. From embedded systems to HPCs, from trading floors to satellites.

Saying any of the "old school" distro's are a bad fit for running in a container is a display of ignorance at best.

mvc• 11 years ago

We took alpine, added the oracle jre, and use it as a base image for our clojure apps. Seems to be a reasonable choice for that use-case since you just need something that will start your jar.

I'd have thought the same would be true for apps written in Go.

_6d9t• 11 years ago

You can actually take things way further in Go: https://blog.codeship.com/building-minimal-docker-containers...

shykes• 11 years ago

Fun fact: the creator of Alpine Linux, Natanael Copa works at Docker :)

scott_karana2• 11 years ago

For anyone wondering what "APK" is, I think it's the Android packager. Interesting choice!

https://en.wikipedia.org/wiki/Android_application_package

mitchty• 11 years ago

Different apk format. Alpine linux apk is just a tar.gz of a signing key, .APKBUILD file and the files rooted in /

scott_karana2• 11 years ago

Whoops, yeah.

http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package

BenjaminCoe• 11 years ago

When packaging up various npm components, BusyBox was recommended to me as a great solution for creating containers with a low overhead -- I eventually stumbled across Alpine (which is built on top of BusyBox) and have been really happy.

Alpine has a tiny footprint, which is great for wrapping Node.js which itself is tiny; But wait, there's more, Alpine has a great package-manager similar to apt, called apk -- this is what sold me on it over BusyBox.

_pmf_• 11 years ago

It comes with its own package format, naturally.

arca_vorago• 11 years ago

What I like about Alpine is grsec being bult in, and personally I like grsecs new distribution model. Remove openssh, put tinyssh (curve25519) ossec, hiawatha, a few ither tweaks and you have a pretty secure system. I wish they were more gnu friendly but still...

bobbles• 11 years ago

Of course all the HN comments on a page about making a small docker image are just bitching about the person making a small docker image because of <reasons> that would all make it not a small docker image any more

anderspitman• 11 years ago

Love Alpine. The biggest use case I've found for small images so far is for testing a microservices system on Travis or a similar CI. You package each of your services in a container, then use docker-compose1[1] to start everything up. The faster it can pull down the images, the faster your CI build runs, so size can be important here.

One interesting thing about Alpine is that it uses MUSL[2] for its libc. If you want the bare minimum image size, you can use a scratch or busybox image and statically compile your binaries[3].

[1] https://docs.docker.com/compose/

[2] http://www.musl-libc.org/

[3] http://blog.xebia.com/create-the-smallest-possible-docker-co...

ben_hall• 11 years ago

It's been great for us. We use it for deploying applications such as curl or netcat in containers without overhead of Ubuntu potentially being downloaded onto a host.

kylequest• 11 years ago

If you like Alphine and it works for you great, but it's not always an option. If you use Ubuntu and you still want small containers there are a number of options. DockerSlim (http://dockersl.im) is one of these options. A sample node app container build from Ubuntu is around 14MB.

manojlds• 11 years ago

Is that used heavily in production? Looking at a container based on usage, and slimming sounds very risky to me.

itomato• 11 years ago

Alpine Linux has packages for Inkscape.

This runs against the notion of minimalism in the context of a harness for containers in my view.

Super small Docker image based on Alpine Linux

Related Stories