14 ms·

Super small Docker image based on Alpine Linux

261 points by antouank 11y ago

deleted 11y ago
[deleted]
AdamGibbins 11y ago
Although not clear from the GitHub link, this is actually the official Docker image of Alpine: https://hub.docker.com/_/alpine/ https://hub.docker.com/_/alpine/ - see the Dockerfile links.
okasaki 11y ago
Interestingly, alpine doesn't use systemd.
- bespoke_engnr 11y 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 11y 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.
    - bespoke_engnr 11y ago
      Actually, I take it back -- you are probably wiser than me, pre-empting the systemd battles that always ensue :-D.
  - jlappi 11y 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 11y 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).
- dbalan 11y 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 11y 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.
  - kgilpin 11y 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).
    - timdorr 11y ago
      If you're providing an all-in-one solution like that, it sounds like you would be better served by just providing an OVF image to them. Or better yet, keep 6 distinct containers like you should, and use docker-compose to spin them up together. Makes upgrades easier because you can simply point to a newer version of whatever service containers you're using without having to take out everything. If you're using containers as a VM, you're essentially adding overhead for no good reason.
  - mkobit 11y 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-zombie-reaping-problem/ https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb... [2]: https://phusion.github.io/baseimage-docker/ https://phusion.github.io/baseimage-docker/
- vezzy-fnord 11y ago
  Does upstream systemd build on musl now?
CSDude 11y 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 11y ago
Sounds great. Will definitely give a try !
simula67 11y 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.
- npsimons 11y 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 11y 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".
mrmondo 11y 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 11y 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 11y 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.
- wtbob 11y 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.
  - _Codemonkeyism 11y 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.
bespoke_engnr 11y 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 11y 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 11y ago
  Why can't you build an image with the JDK based on Alpine and use that as your base image for everything else?
  - rickycook 11y 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
    - iheartmemcache 11y ago
      Alpine has Sable, and you can also compile your own OpenJDK (if it doesn't have it already). There are plenty of reasons to use Alpine and just as many not to use it, but lack of a JVM isn't one of them (Pretty much same with Docker- it added nothing of apparently value to me more than that LXC did (or BSD jails like someone above me mentioned), but I'm sure it provides value to some people.)
- creshal 11y ago
  I haven't yet used Alpine, but from its wiki it seems you can easily create the packages yourself?
- woadwarrior01 11y 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-docker-containers/ https://developer.atlassian.com/blog/2015/08/minimal-java-do...
- 11y ago
kenOfYugen 11y ago
Anybody using Alpine for a minimal Desktop OS? How does it compare to something like Arch?
- nextos 11y 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.
  - kenOfYugen 11y ago
    Thanks! I'll give it a try then and maybe Nix too!
  - iheartmemcache 11y 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-guix-package.html 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 11y 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.
cm2187 11y 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.
- rickycook 11y 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
  - cm2187 11y 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?
    - rickycook 11y ago
      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)
      - ersoft 11y ago
        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 https://github.com/flynn/flynn/tree/master/slugrunner [1] https://github.com/flynn/flynn/tree/master/slugbuilder https://github.com/flynn/flynn/tree/master/slugbuilder
nickjj 11y 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.
- rickycook 11y 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"
  - nickjj 11y 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.
    - rickycook 11y ago
      yeah totally. my rule of thumb is that if it's got c extensions, Debian is fine. if it's compiled, you'll be doing that outside your container anyway (because who wants gcc in prod aye?) so you may as well copy your 20kb binary into alpine rather than Debian
fidget 11y 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 11y 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 https://news.ycombinator.com/item?id=10783021 [1]: https://news.ycombinator.com/item?id=10782946 https://news.ycombinator.com/item?id=10782946
  - Gigablah 11y ago
    You're seriously suggesting censorship as a counter to "groupthink"?
- Gigablah 11y ago
  > so I pay the download cost once Not if you're spinning up new hosts via autoscaling.
  - fidget 11y 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.
dbalan 11y 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].
- justincormack 11y 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 11y 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.
- mverwijs 11y 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.
- deleted 11y ago
  [deleted]
coleca 11y ago
Alpine Linux looks great. Unfortunately there is an outstanding issue (https://github.com/gliderlabs/docker-alpine/issues/8 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 11y 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 11y 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 11y 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 https://github.com/bontibon/digitalocean-alpine
hathym 11y ago
I'm currently using rancherOS, it's awesome!!
hharnisch 11y 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 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 11y 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 http://lists.alpinelinux.org/alpine-user/0002.html
- Gigablah 11y 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.
kstenerud 11y 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 https://github.com/phusion/baseimage-docker
- _Codemonkeyism 11y ago
  "Will it still be maintained a few years from now?" What would you suggest? Debian? Ubuntu LTS?
  - kstenerud 11y 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.
    - _Codemonkeyism 11y ago
      Thanks!
  - e40 11y ago
    Or CentOS 7 (Docker is not supported any more on 6.x).
    - floatboth 11y ago
      CentOS is the gold standard of ANCIENT packages. I think they still ship Ruby 1.8.
      - loudmax 11y ago
        RHEL (and by extension CentOS) 7 provides Ruby 2.0. And a 3.10 kernel even. If you're running docker with CentOS, this is what you're likely to use. RHEL/CentOS 6 provides Ruby 1.8.7 and a 2.6.32 kernel. It can be made to run with docker, but it's unsupported and it won't be easy. RHEL/CentOS 5 provides Ruby 1.8.5. The 2.6.18 kernel it comes with won't even run go binaries such as docker, much less lxc. Yes this is ancient. It was released in 2007 and it will be supported until 2017.
ejholmes 11y 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 11y 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 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 https://pkgs.alpinelinux.org/packages
_euvw 11y ago
Why not? Let's run the numbers. * http://wiki.alpinelinux.org/wiki/Special:ActiveUsers 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 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/ 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 11y 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?
  - mverwijs 11y 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.
shykes 11y ago
Fun fact: the creator of Alpine Linux, Natanael Copa works at Docker :)
scott_karana 11y ago
For anyone wondering what "APK" is, I think it's the Android packager. Interesting choice! https://en.wikipedia.org/wiki/Android_application_package https://en.wikipedia.org/wiki/Android_application_package
- mitchty 11y ago
  Different apk format. Alpine linux apk is just a tar.gz of a signing key, .APKBUILD file and the files rooted in /
  - scott_karana 11y ago
    Whoops, yeah. http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
BenjaminCoe 11y 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_ 11y ago
It comes with its own package format, naturally.
arca_vorago 11y 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 11y 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 11y 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/ https://docs.docker.com/compose/ [2] http://www.musl-libc.org/ http://www.musl-libc.org/ [3] http://blog.xebia.com/create-the-smallest-possible-docker-container/ http://blog.xebia.com/create-the-smallest-possible-docker-co...
ben_hall 11y 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 11y 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 http://dockersl.im) is one of these options. A sample node app container build from Ubuntu is around 14MB.
- manojlds 11y ago
  Is that used heavily in production? Looking at a container based on usage, and slimming sounds very risky to me.
itomato 11y 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.

261 points by antouank 11y ago

deleted 11y ago

[deleted]

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

okasaki 11y ago

Interestingly, alpine doesn't use systemd.

bespoke_engnr 11y 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 11y 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.
  - bespoke_engnr 11y ago
    Actually, I take it back -- you are probably wiser than me, pre-empting the systemd battles that always ensue :-D.
- jlappi 11y 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 11y 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).
dbalan 11y 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 11y 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.
- kgilpin 11y 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).
  - timdorr 11y ago
    If you're providing an all-in-one solution like that, it sounds like you would be better served by just providing an OVF image to them. Or better yet, keep 6 distinct containers like you should, and use docker-compose to spin them up together. Makes upgrades easier because you can simply point to a newer version of whatever service containers you're using without having to take out everything. If you're using containers as a VM, you're essentially adding overhead for no good reason.
- mkobit 11y 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-zombie-reaping-problem/ https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb... [2]: https://phusion.github.io/baseimage-docker/ https://phusion.github.io/baseimage-docker/
vezzy-fnord 11y ago
Does upstream systemd build on musl now?

CSDude 11y 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 11y ago

Sounds great. Will definitely give a try !

simula67 11y 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.

npsimons 11y 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 11y 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".

mrmondo 11y 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 11y 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 11y 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.
wtbob 11y 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.
- _Codemonkeyism 11y 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.

bespoke_engnr 11y 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 11y 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 11y ago
Why can't you build an image with the JDK based on Alpine and use that as your base image for everything else?
- rickycook 11y 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
  - iheartmemcache 11y ago
    Alpine has Sable, and you can also compile your own OpenJDK (if it doesn't have it already). There are plenty of reasons to use Alpine and just as many not to use it, but lack of a JVM isn't one of them (Pretty much same with Docker- it added nothing of apparently value to me more than that LXC did (or BSD jails like someone above me mentioned), but I'm sure it provides value to some people.)
creshal 11y ago
I haven't yet used Alpine, but from its wiki it seems you can easily create the packages yourself?
woadwarrior01 11y 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-docker-containers/ https://developer.atlassian.com/blog/2015/08/minimal-java-do...
11y ago

kenOfYugen 11y ago

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

nextos 11y 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.
- kenOfYugen 11y ago
  Thanks! I'll give it a try then and maybe Nix too!
- iheartmemcache 11y 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-guix-package.html 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 11y 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.

cm2187 11y 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.

rickycook 11y 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
- cm2187 11y 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?
  - rickycook 11y ago
    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)
    - ersoft 11y ago
      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 https://github.com/flynn/flynn/tree/master/slugrunner [1] https://github.com/flynn/flynn/tree/master/slugbuilder https://github.com/flynn/flynn/tree/master/slugbuilder

nickjj 11y 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.

rickycook 11y 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"
- nickjj 11y 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.
  - rickycook 11y ago
    yeah totally. my rule of thumb is that if it's got c extensions, Debian is fine. if it's compiled, you'll be doing that outside your container anyway (because who wants gcc in prod aye?) so you may as well copy your 20kb binary into alpine rather than Debian

fidget 11y 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 11y 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 https://news.ycombinator.com/item?id=10783021 [1]: https://news.ycombinator.com/item?id=10782946 https://news.ycombinator.com/item?id=10782946
- Gigablah 11y ago
  You're seriously suggesting censorship as a counter to "groupthink"?
Gigablah 11y ago
> so I pay the download cost once Not if you're spinning up new hosts via autoscaling.
- fidget 11y 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.

dbalan 11y 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].

justincormack 11y 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 11y 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.

mverwijs 11y 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.
deleted 11y ago
[deleted]

coleca 11y ago

Alpine Linux looks great. Unfortunately there is an outstanding issue (https://github.com/gliderlabs/docker-alpine/issues/8 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 11y 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 11y 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 11y 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 https://github.com/bontibon/digitalocean-alpine

hathym 11y ago

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

hharnisch 11y 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 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 11y 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 http://lists.alpinelinux.org/alpine-user/0002.html

Gigablah 11y 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.

kstenerud 11y 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 https://github.com/phusion/baseimage-docker

_Codemonkeyism 11y ago
"Will it still be maintained a few years from now?" What would you suggest? Debian? Ubuntu LTS?
- kstenerud 11y 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.
  - _Codemonkeyism 11y ago
    Thanks!
- e40 11y ago
  Or CentOS 7 (Docker is not supported any more on 6.x).
  - floatboth 11y ago
    CentOS is the gold standard of ANCIENT packages. I think they still ship Ruby 1.8.
    - loudmax 11y ago
      RHEL (and by extension CentOS) 7 provides Ruby 2.0. And a 3.10 kernel even. If you're running docker with CentOS, this is what you're likely to use. RHEL/CentOS 6 provides Ruby 1.8.7 and a 2.6.32 kernel. It can be made to run with docker, but it's unsupported and it won't be easy. RHEL/CentOS 5 provides Ruby 1.8.5. The 2.6.18 kernel it comes with won't even run go binaries such as docker, much less lxc. Yes this is ancient. It was released in 2007 and it will be supported until 2017.

ejholmes 11y 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 11y 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 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 https://pkgs.alpinelinux.org/packages

_euvw 11y ago

Why not? Let's run the numbers. * http://wiki.alpinelinux.org/wiki/Special:ActiveUsers 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 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/ 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 11y 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?
- mverwijs 11y 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.

shykes 11y ago

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

scott_karana 11y ago

For anyone wondering what "APK" is, I think it's the Android packager. Interesting choice! https://en.wikipedia.org/wiki/Android_application_package https://en.wikipedia.org/wiki/Android_application_package

mitchty 11y ago
Different apk format. Alpine linux apk is just a tar.gz of a signing key, .APKBUILD file and the files rooted in /
- scott_karana 11y ago
  Whoops, yeah. http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package

BenjaminCoe 11y 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_ 11y ago

It comes with its own package format, naturally.

arca_vorago 11y 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 11y 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 11y 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/ https://docs.docker.com/compose/ [2] http://www.musl-libc.org/ http://www.musl-libc.org/ [3] http://blog.xebia.com/create-the-smallest-possible-docker-container/ http://blog.xebia.com/create-the-smallest-possible-docker-co...

ben_hall 11y 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 11y 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 http://dockersl.im) is one of these options. A sample node app container build from Ubuntu is around 14MB.

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

itomato 11y 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.