13 ms·

Docker Official Images Are Moving to Alpine Linux

246 points by infodroid 11y ago

hackerboos 11y ago
Has Alpine Linux solved the glibc problem? I recall you can't simply install Oracle Java 7+ on Alpine linux without a lot of setup first because of the dependency on glibc.
- bleakgadfly 11y ago
  Alpine Linux has a glibc solution. The glibc problem lies with other applications.
  - hackerboos 11y ago
    I think it's easier to get Alpine to fix the issue than Oracle. Until then the issue remains https://github.com/gliderlabs/docker-alpine/issues/11 https://github.com/gliderlabs/docker-alpine/issues/11
- kylequest 11y ago
  Sort of... They have a glib package. Take a look at this Atlassian post to see how you can make your Oracle Java based apps run with Alpine: https://developer.atlassian.com/blog/2015/08/minimal-java-docker-containers/ https://developer.atlassian.com/blog/2015/08/minimal-java-do... I still prefer to use DockerSlim to shrink images. I'm too lazy to worry about the Alpine gotchas :)
regecks 11y ago
That seems ... brave? I have used Alpine a few times in Docker images and it's fantastic, but we did run into incompatibilities due to musl.
- gtaylor 11y ago
  I've ran into this as well. Having a hard time remembering what the issue was. Maybe DNS-related?
  - stonogo 11y ago
    These incompatibilities arose from software that was written to rely on glibc-specific name resolution quirks. Neither musl nor docker rely on these misplaced expectations, but unfortunately some projects have decided to blame a standards-compliant libc implementation rather than fix their own software.
    - kylequest 11y ago
      It sure would be nice if everything was working according to the standards :-)
    - monkmartinez 11y ago
      I am not familiar enough with the quirks of glibc name resolution to say much more than a lot of my stuff relies on binaries compiled against it. Who, in your opinion is to blame here, and what can we do to fix it?
    - ageofwant 11y ago
      If Alpine does not support the software I depend on I have no use for it. I would like to use the official Docker containers as far as I can but I'm most certainly not going to spend time recompiling third party deps to accomplish that. Shipped products trumps "security" and by god "size" every time, always.
  - coleca 11y ago
    Looks like the DNS issue might finally be getting resolved: https://github.com/gliderlabs/docker-alpine/issues/8 https://github.com/gliderlabs/docker-alpine/issues/8
- kylequest 11y ago
  Alpine is pretty nice though using it in containers you are not getting the best part of it: the hardened kernel. I'd say Alpine is a better fit for the host OS where you have a few moving parts. It will be great for compiled language base images, but even there it might be tricky if you rely on 3rd party packages. Libc compatibility issues are also real. It's great that they are slowing addressing them though.
  - daxfohl 11y ago
    Wouldn't CoreOS be the better host though, if just hosting containers is the only goal? Or are there things Alpine would do better?
    - kylequest 11y ago
      I didn't mean to say Alpine is the best host OS option. It's just it's a better idea compared to Ubuntu :-)
    - lisivka 11y ago
      CentOS will be better option for host. Why you need CoreOS?
      - jjm 11y ago
        Beg to differ. You should read the docs for CoreOS. One OS is made to host containers, the other is more general.
        lisivka 11y ago
        I see same things but under different branding. It's all.
        lisivka 11y ago
        Anonymous coward: explain your downvote, please.
Zekio 11y ago
Damn, the Alphine linux ISO is tiny
- deleted 11y ago
  [deleted]
- anon987 11y ago
  Red Hat's Project Atomic "installer ISO" is ~630mb and the uncompressed qcow2 is >900mb. I was impressed with Atomic's size, but seeing how much smaller Alpine is, I can't help but wonder what all the additional size is in Red Hat's images.
  - rdtsc 11y ago
    RHEL is an enterprise OS. It is designed to handle various drivers (video, network, storage). It has monitoring, auditing, reporting stuff. Some of those dependencies are bringing others (say the monitor needs a mail client to sent messages, ok, install the mail client, oh looks like that brings in perl, etc). Then there might be multiple version of said monitoring. And think they just never really try to make it small. That is just what their customers pay for. If Alpine did what RHEL does out of the box it would be hundreds of MBs as well.
    - tdurden 11y ago
      RHEL != Atomic
      - Conan_Kudo 11y ago
        Atomic is intended to be used as a host OS and uses RHEL, CentOS, or Fedora as a base typically. And the installer ISO is that large precisely because it bundles hardware, language, and all kinds of other support. However, if you'd like to craft your own minimal Atomic host, you can. Making minimal containers is pretty easy, though, since yum/dnf lets you create execution trees that contain only what's needed for an application to run (as others have mentioned). So, really, doing micro-services on RHEL/CentOS/Fedora hosts is pretty easy.
JasonSage 11y ago
Last I'd heard (I believe) the creator of Alpine Linux was looking for work and the future of the project was a bit uncertain. I'm happy to hear that he'll be able to continue working with Alpine Linux and that we'll still be able to make great Docker images with it.
- fidget 11y ago
  Wait, the future of Alpine is dependant on 1 person? I'll stick with Ubuntu I think
  - marshallford 11y ago
    I agree, if that is the case those using Alpine in production should be wary.
    - Gigablah 11y ago
      Here's a list of people on their issue tracker: http://bugs.alpinelinux.org/projects/alpine http://bugs.alpinelinux.org/projects/alpine Can't be too sure though, maybe they're all aliases of one person.
      - uggedal 11y ago
        Those are indeed real people.
  - JasonSage 11y ago
    Maybe "future of the project is a bit uncertain" was a bit too strong. Here's all I originally saw: https://twitter.com/richfelker/status/662535718267392000 https://twitter.com/richfelker/status/662535718267392000 Either way, it seems it's now getting some backing by Docker. I can only imagine that the number of contributors and packages for it will grow and mature.
kev009 11y ago
Alpine makes me not totally hate Linux, and musl libc is just great code. Good to see them getting publicity and adoption!
- lisivka 11y ago
  musl is about 2x slower than glibc: http://www.etalabs.net/compare_libcs.html http://www.etalabs.net/compare_libcs.html . Other libraries are even worse.
  - hga 11y ago
    Note that comparison is by the musl author, but it's several point releases old for it and glibc.
GauntletWizard 11y ago
Great move by the docker team. The promise of containers has always been to make the environment that processes live in super lightweight, with a minimum of unnecessary binaries and permissions. Having a full ubuntu installation per container has been a major hazard to that, as it's required the use of overlays and other tricks to avoid having huge disk overhead per container. Moving to a much lighterweight base image means you need fewer overlays, because you can pay the 5mb cost for days. It also reduces the attack surface by a lot, for much greater security.
- mverwijs 11y ago
  It was not the promise as I understood it. As I understood it the promise was to have my production environment run on my desktop. I cannot run my production on Alpine. (Yes, every startup I know can. But I work for a lot of older companies that have legacy systems. And that is a huge market that cannot use Alpine.)
auvi 11y ago
does this mean i can practically email a container? wow!
iso-8859-1 11y ago
What's with the weird comparison to the Windows start button? Is that if you encode the button as a BMP? Or is it the size of the compressed vector graphics? Or is it the size of the binary used to implement the start button? Does it include the shared libraries that binary uses? wtf.
- mastazi 11y ago
  Exactly what I thought while I was reading that sentence.
x5n1 11y ago
w00t
gtirloni 11y ago
Alpine is fine but it would be really nice to have smaller images from the RHEL/CentOS/Fedora or Debian/Ubuntu ecosystems, if that's possible.
- sandGorgon 11y ago
  +1 I would love to have a stripped down Debian 8 base.
  - mverwijs 11y ago
    sudo apt-get install debootstrap mkdir deb8 sudo debootstrap jessie deb8 Combine that with apt-cacher-ng and whooosh. And now all you have to do is tell Ansible what needs to get done in that chroot. And you have a container that matches production one-on-one.
- u320 11y ago
  On fedora, you can do something like mkdir /tmp/myimage dnf --releasever=23 --installroot=/tmp/myimage install <package-name> rm -rf /tmp/myimage/var/cache/dnf tar zcvf - /tmp/myimage | docker import - myimage Gives you an image that is ~30M (15M compressed) plus the size of whatever package you are installing. The advantage is that you get access to Fedora's package database with security updates. This could probably be slimmed down further with custom versions of the base packages.
jmspring 11y ago
Blog claims Alpine is based around being secure and light weight...but gives no indication on why it is secure. Oh, lightweight because of busy box? Is there scrutiny on packages installed? I don't see the security component. Maybe Docker can reveal more there, though given how they iterate and things break, I'm not sure they are willing (or capable).
- hiou 11y ago
  From the article > 2. Security is improved as the image has a smaller footprint thus making the attack surface also smaller Not saying you need to agree with that. But that does appear to be at least an "indication"
  - jmspring 11y ago
    Image footprint has nothing to do with the packages installed in that image. This is complete hogwash from a security point of view. Yes "smaller" could = "more secure", but, yeah, no.
    - nickpsecurity 11y ago
      Remind them that DOS was pretty small. Must be way more secure than Linux due to reduced attack surface. ;)
- viraptor 11y ago
  From the Alpine linux site: "Alpine Linux was designed with security in mind. The kernel is patched with grsecurity/PaX out of the box, and all userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities." I got excited, but then remembered - grsec will not affect containers. Neither will PaX unfortunately. PIE + stack smashing protection is already available in most serious distros. From the basic info I can find, I don't see a huge difference. For comparison Ubuntu provides its list here: https://wiki.ubuntu.com/Security/Features https://wiki.ubuntu.com/Security/Features It's similar to Fedora: https://fedoraproject.org/wiki/Security_Features_Matrix https://fedoraproject.org/wiki/Security_Features_Matrix And to Arch (no nice table though) https://wiki.archlinux.org/index.php/DeveloperWiki:Security https://wiki.archlinux.org/index.php/DeveloperWiki:Security - Alpine doesn't seem to provide similar summary. [edit: sorry, I stealth-edited the realisation]
hogeland 11y ago
Good, using Ubuntu as a base for official images always seemed dumb.
- bcook 11y ago
  Explain (consisely).
  - infamouscow 11y ago
    Because all you're really doing is increasing your attack surface and wasting storage space. If you have a need for a specific piece of software, you should be able to identify that and include that in your docker image. Starting with a kitchen sink is only good when you're too lazy to spend an hour to understand what your software depends on.
    - lisivka 11y ago
      If you run _same_ application in container with 20MB of files and in container with 2000MB of files, how it can affect attack surface at all? Bytes on disk are just data. Moreover, if I use standard RPM package to run service using non-root user in limited environment using Systemd, then it will be much less riskier than running same service in container using root user, by order of magnitude less safer. Container are not solution to problems with security. Much often they are huge security hole.
- siliconc0w 11y ago
  Ubuntu is great because people already understand it and probably already know how to install their apps on it which makes moving to Docker easy. Most businesses unsurprisingly don't like the idea of running on a OS they never heard of with tooling their engineers don't have experience with, limited community or enterprise support, or even internal repos. Alpine may be the 'technically correct' choice but Ubuntu is easily a much better business choice.
  - vidarh 11y ago
sandGorgon 11y ago
What worries me about Alpine is that it invents YET-ANOTHER package manager(apk) . I think it claims that it builds on top of Gentoo... But could someone explain why Deb or rpm could not be used. Does using Deb or rpm screw up size or security in some way. We could also have gotten access to the Debian/Fedora repository in a pinch. Not all of us run statically compiled go executables and often have tons of dependencies that need to be installed for webapp. P.S. And the package manager apk is unfortunately named to conflict with IMHO the biggest package repo in the world:Android. It is virtually impossible to Google anything meaningful without running into android.
- digi_owl 11y ago
  From their wiki, the format itself it basically a tar.gz wrapped in a digital signature.
- monkmartinez 11y ago
  What is the fall back if a package is not available? For example, I was able to find an APK for python 3.5.1-r0. However, I can find nothing for Python 3.4 except a bug report and some hacky fixes. Also, it looks like running anything that require binaries that have compiled against glibc will be wonky as hell.
  - jwatte 11y ago
    The whole point is: Do not run with glibc! If you need something that's not available, build it.
    - monkmartinez 11y ago
      Then I am debugging builds, no?
    - seanp2k2 11y ago
      We've been down this road many times before. It does not historically lead to happy places. Why will it be different this time?
hharnisch 11y ago
Does DNS based service discovery work yet? If not these images don't play nice with kubernetes.
- shykes 11y ago
  Yes. And Docker 1.10 does DNS service discovery out of the box.
- justincormack 11y ago
  Based on my understanding of the threads on the Musl list, part of this was some features that are now implemented in Musl, and part was Kubernetes using DNS in ways that are incorrect.
- deleted 11y ago
  [deleted]
- steeve 11y ago
  Don't have the link here to musl added domain support on Jan 26 2016, so it's close :)
  - steilpass 11y ago
    As far as I can see it's currently in master: http://git.musl-libc.org/cgit/musl/commit/?id=3d6e2e477ced37fd328870f018950b283cb7293c http://git.musl-libc.org/cgit/musl/commit/?id=3d6e2e477ced37... But has not been released yet: http://wiki.musl-libc.org/wiki/Roadmap#musl_1.1.13 http://wiki.musl-libc.org/wiki/Roadmap#musl_1.1.13 http://git.musl-libc.org/cgit/musl/ http://git.musl-libc.org/cgit/musl/
gizi 11y ago
I agree with snubbing glibc, systemd, and apt-get. Seriously, it is about time to put an end to the bloated fatibubbul fest going on over there! I intend to move my dockers to alpine. I will only come back to debian after and not before they have downsized, trimmed and layed off all the useless fat around their bellies!
- digi_owl 11y ago
  Dunno if it is about snubbing, but i get the impression that having systemd inside the container makes it damn hard to work it if you do not also have it outside the container. And at that point, systemd is likely to take over control completely rather than play nice with docker.
  - ownagefool 11y ago
    Na, that's not how it works at all. When you run a docker container, you'll be running your app directly, thus systemd won't be involved and isn't even needed within the container. The problem with debian and centos is they weren't create with containers in mind, thus by default their base images pull in a lot of stuff that's required to actually init hardware. We can see with fedora that efforts have been made to slim it down, I suspect as containers become a popular usecase we're going to see smaller base containers, except with access to 30,000 stable packages and a mainstream community.
    - digi_owl 11y ago
      Could have sworn i had read something about using systemd inside containers hosted by systemd.
      - ownagefool 11y ago
        You might find people attempting to start systemd as pid 1 then running their containers as sort of lightvm, but that's not really the typical use case. More common is folks not wanting to deal with splitting processes that are grouped together such as an internal gitlab instance that has, nginx, unicorn, postgres, ssh, and sidekick running. Best practice is arguably that you should be able to run all these processes in different containers and share the directories or sockets where possible, but the pragmatist is probably running them together using supervisor.
dschiptsov 11y ago
So, that Alpine linux has more man-power and resources to maintain kernel and core libraries stability and binary compatibility than Ubuntu (with its huge community) or Fedora/RH/CentOS (with its money)? Does Oracle runs on it?
- ageofwant 11y ago
  Alpine is built by one guy, that now works for Docker. So I understand. I really hope I'm wrong.
  - uggedal 11y ago
    Alpine is not built by one guy. There is only one creator though.
- RaleyField 11y ago
  ls -l ~/.bashrc
ARothfusz 11y ago
Why does the size of a base image matter? What happened to the shared layers between images? Did the new file systems completely sacrifice that? The original filesystem (AUFS) used shared read-only layers, so if two images used the same base image, only their differences contributed to disk usage. I know there has been a lot of work to move to filesystems supported by more kernels, but if shared layers have been sacrificed, that makes me sad.
- vidarh 11y ago
  > Why does the size of a base image matter? What happened to the shared layers between images? It matters because when bootstrapping new hosts you still need to download all the base images, and because in many systems the base images can come to totally dominate the storage needs. It still can often save a lot, but it's not enough for a lot of places where people want to use Docker.
  - icebraining 11y ago
    It matters because when bootstrapping new hosts you still need to download all the base images Why not just put those images in the snapshot/installer you're using to initialize those hosts?
  - lisivka 11y ago
    If you need a library, you will download it anyway. But you can download it once, in base image, or multiple times. IMHO, the fatter _base_ image is, the better. Ideally, base image must be full installation of everything, one large image for all. You will just download it, and it will just work.
ageofwant 11y ago
This is silly nonsense. Before I care about image size or "security", I need to ship my products. After I've accomplished that, I make sure my firewall is still good and if necessary buy $20 more volume space. You have "solved" a problem that no one has. I don't care about image size, and neither should you. I don't care about container security, and neither should you. How does struggling with a anaemic non-distribution hacked together by a handful of kids that believes software is about size and "security" help me accomplish shipping shit ? It does not. This decision is ill-advised.
duaneb 11y ago
The base image size does not explain the switch in package manager. Why not use the ubuntu one, and simply trim the base image to minimal? What a waste of energy for everyone so they can save a few cents on bandwidth.
tommis 11y ago
To you complaining "its just one guy maintaining the distro" etc. Did you not read the article? > Docker has hired the creator of Alpine Linux, Natanael Copa <
pepijndevos 11y ago
From the Alpine website, the iso is 82 MB. What's up with that?
- profmonocle 11y ago
  Well, the ISO includes the Linux kernel. A Docker image only comes with user space components since the host provides the kernel, so an ISO would need to be larger.
  - steeve 11y ago
    Boot2docker creator here (although I don't actively maintain it) TCL is only 9 mb, oh which the kernel is 4mb if my memory serves me well. So most of the size is likely not due to the kernel (modules maybe?) I'd like to see an Alpine based b2d though
diebir 11y ago
Awesome, can we now move Docker somewhere ever further, where it can't be seen or found all together?
gaius 11y ago
Red Hat, Debian, Suse. Stood the test of time. Everything else is not a wise choice for anything but a personal system.
- digi_owl 11y ago
  Slackware?
  - gaius 11y ago
    Sure, but my point stands. Will Alpine exist in 5 years, 10 years?
tianon 11y ago
Primary curator of the program here (https://github.com/docker-library/official-images/blob/319cb294e869a54985fb4beb9d862982a8cc99ce/MAINTAINERS#L1 https://github.com/docker-library/official-images/blob/319cb...). "Moving" is a bit of a strong word. It would be much more accurate to say "providing alternatives". For example, the "golang" image now has an "alpine" variant for each supported version (https://hub.docker.com/_/golang/ https://hub.docker.com/_/golang/), but the default variant is still Debian-based (especially given that switching the base outright would break far too many existing Dockerfiles). Additionally, the documentation calls out that there might be libc compatibility issues in the spirit of trying to ensure our users are properly informed about the potential problems they might run into in their quest for the smallest possible base: https://github.com/docker-library/docs/blob/b7b6b86124682ef11a349b84b27bda24ba53f41f/.template-helpers/variant-alpine.md https://github.com/docker-library/docs/blob/b7b6b86124682ef1... I would definitely welcome PRs to make this verbiage more accurate or more informative of pros and cons.

246 points by infodroid 11y ago

Has Alpine Linux solved the glibc problem? I recall you can't simply install Oracle Java 7+ on Alpine linux without a lot of setup first because of the dependency on glibc.

bleakgadfly 11y ago
Alpine Linux has a glibc solution. The glibc problem lies with other applications.
- hackerboos 11y ago
  I think it's easier to get Alpine to fix the issue than Oracle. Until then the issue remains https://github.com/gliderlabs/docker-alpine/issues/11 https://github.com/gliderlabs/docker-alpine/issues/11
kylequest 11y ago
Sort of... They have a glib package. Take a look at this Atlassian post to see how you can make your Oracle Java based apps run with Alpine: https://developer.atlassian.com/blog/2015/08/minimal-java-docker-containers/ https://developer.atlassian.com/blog/2015/08/minimal-java-do... I still prefer to use DockerSlim to shrink images. I'm too lazy to worry about the Alpine gotchas :)

regecks 11y ago

That seems ... brave? I have used Alpine a few times in Docker images and it's fantastic, but we did run into incompatibilities due to musl.

gtaylor 11y ago
I've ran into this as well. Having a hard time remembering what the issue was. Maybe DNS-related?
- stonogo 11y ago
  These incompatibilities arose from software that was written to rely on glibc-specific name resolution quirks. Neither musl nor docker rely on these misplaced expectations, but unfortunately some projects have decided to blame a standards-compliant libc implementation rather than fix their own software.
  - kylequest 11y ago
    It sure would be nice if everything was working according to the standards :-)
  - monkmartinez 11y ago
    I am not familiar enough with the quirks of glibc name resolution to say much more than a lot of my stuff relies on binaries compiled against it. Who, in your opinion is to blame here, and what can we do to fix it?
  - ageofwant 11y ago
    If Alpine does not support the software I depend on I have no use for it. I would like to use the official Docker containers as far as I can but I'm most certainly not going to spend time recompiling third party deps to accomplish that. Shipped products trumps "security" and by god "size" every time, always.
- coleca 11y ago
  Looks like the DNS issue might finally be getting resolved: https://github.com/gliderlabs/docker-alpine/issues/8 https://github.com/gliderlabs/docker-alpine/issues/8
kylequest 11y ago
Alpine is pretty nice though using it in containers you are not getting the best part of it: the hardened kernel. I'd say Alpine is a better fit for the host OS where you have a few moving parts. It will be great for compiled language base images, but even there it might be tricky if you rely on 3rd party packages. Libc compatibility issues are also real. It's great that they are slowing addressing them though.
- daxfohl 11y ago
  Wouldn't CoreOS be the better host though, if just hosting containers is the only goal? Or are there things Alpine would do better?
  - kylequest 11y ago
    I didn't mean to say Alpine is the best host OS option. It's just it's a better idea compared to Ubuntu :-)
  - lisivka 11y ago
    CentOS will be better option for host. Why you need CoreOS?
    - jjm 11y ago
      Beg to differ. You should read the docs for CoreOS. One OS is made to host containers, the other is more general.
      - lisivka 11y ago
        I see same things but under different branding. It's all.
        lisivka 11y ago
        Anonymous coward: explain your downvote, please.

Zekio 11y ago

Damn, the Alphine linux ISO is tiny

deleted 11y ago
[deleted]
anon987 11y ago
Red Hat's Project Atomic "installer ISO" is ~630mb and the uncompressed qcow2 is >900mb. I was impressed with Atomic's size, but seeing how much smaller Alpine is, I can't help but wonder what all the additional size is in Red Hat's images.
- rdtsc 11y ago
  RHEL is an enterprise OS. It is designed to handle various drivers (video, network, storage). It has monitoring, auditing, reporting stuff. Some of those dependencies are bringing others (say the monitor needs a mail client to sent messages, ok, install the mail client, oh looks like that brings in perl, etc). Then there might be multiple version of said monitoring. And think they just never really try to make it small. That is just what their customers pay for. If Alpine did what RHEL does out of the box it would be hundreds of MBs as well.
  - tdurden 11y ago
    RHEL != Atomic
    - Conan_Kudo 11y ago
      Atomic is intended to be used as a host OS and uses RHEL, CentOS, or Fedora as a base typically. And the installer ISO is that large precisely because it bundles hardware, language, and all kinds of other support. However, if you'd like to craft your own minimal Atomic host, you can. Making minimal containers is pretty easy, though, since yum/dnf lets you create execution trees that contain only what's needed for an application to run (as others have mentioned). So, really, doing micro-services on RHEL/CentOS/Fedora hosts is pretty easy.

JasonSage 11y ago

Last I'd heard (I believe) the creator of Alpine Linux was looking for work and the future of the project was a bit uncertain. I'm happy to hear that he'll be able to continue working with Alpine Linux and that we'll still be able to make great Docker images with it.

fidget 11y ago
Wait, the future of Alpine is dependant on 1 person? I'll stick with Ubuntu I think
- marshallford 11y ago
  I agree, if that is the case those using Alpine in production should be wary.
  - Gigablah 11y ago
    Here's a list of people on their issue tracker: http://bugs.alpinelinux.org/projects/alpine http://bugs.alpinelinux.org/projects/alpine Can't be too sure though, maybe they're all aliases of one person.
    - uggedal 11y ago
      Those are indeed real people.
- JasonSage 11y ago
  Maybe "future of the project is a bit uncertain" was a bit too strong. Here's all I originally saw: https://twitter.com/richfelker/status/662535718267392000 https://twitter.com/richfelker/status/662535718267392000 Either way, it seems it's now getting some backing by Docker. I can only imagine that the number of contributors and packages for it will grow and mature.

kev009 11y ago

Alpine makes me not totally hate Linux, and musl libc is just great code. Good to see them getting publicity and adoption!

lisivka 11y ago
musl is about 2x slower than glibc: http://www.etalabs.net/compare_libcs.html http://www.etalabs.net/compare_libcs.html . Other libraries are even worse.
- hga 11y ago
  Note that comparison is by the musl author, but it's several point releases old for it and glibc.

GauntletWizard 11y ago

Great move by the docker team. The promise of containers has always been to make the environment that processes live in super lightweight, with a minimum of unnecessary binaries and permissions. Having a full ubuntu installation per container has been a major hazard to that, as it's required the use of overlays and other tricks to avoid having huge disk overhead per container. Moving to a much lighterweight base image means you need fewer overlays, because you can pay the 5mb cost for days. It also reduces the attack surface by a lot, for much greater security.

mverwijs 11y ago
It was not the promise as I understood it. As I understood it the promise was to have my production environment run on my desktop. I cannot run my production on Alpine. (Yes, every startup I know can. But I work for a lot of older companies that have legacy systems. And that is a huge market that cannot use Alpine.)

auvi 11y ago

does this mean i can practically email a container? wow!

iso-8859-1 11y ago

What's with the weird comparison to the Windows start button? Is that if you encode the button as a BMP? Or is it the size of the compressed vector graphics? Or is it the size of the binary used to implement the start button? Does it include the shared libraries that binary uses? wtf.

mastazi 11y ago
Exactly what I thought while I was reading that sentence.

x5n1 11y ago

w00t

gtirloni 11y ago

Alpine is fine but it would be really nice to have smaller images from the RHEL/CentOS/Fedora or Debian/Ubuntu ecosystems, if that's possible.

sandGorgon 11y ago
+1 I would love to have a stripped down Debian 8 base.
- mverwijs 11y ago
  sudo apt-get install debootstrap mkdir deb8 sudo debootstrap jessie deb8 Combine that with apt-cacher-ng and whooosh. And now all you have to do is tell Ansible what needs to get done in that chroot. And you have a container that matches production one-on-one.
u320 11y ago
On fedora, you can do something like mkdir /tmp/myimage dnf --releasever=23 --installroot=/tmp/myimage install <package-name> rm -rf /tmp/myimage/var/cache/dnf tar zcvf - /tmp/myimage | docker import - myimage Gives you an image that is ~30M (15M compressed) plus the size of whatever package you are installing. The advantage is that you get access to Fedora's package database with security updates. This could probably be slimmed down further with custom versions of the base packages.

jmspring 11y ago

Blog claims Alpine is based around being secure and light weight...but gives no indication on why it is secure. Oh, lightweight because of busy box? Is there scrutiny on packages installed? I don't see the security component. Maybe Docker can reveal more there, though given how they iterate and things break, I'm not sure they are willing (or capable).

hiou 11y ago
From the article > 2. Security is improved as the image has a smaller footprint thus making the attack surface also smaller Not saying you need to agree with that. But that does appear to be at least an "indication"
- jmspring 11y ago
  Image footprint has nothing to do with the packages installed in that image. This is complete hogwash from a security point of view. Yes "smaller" could = "more secure", but, yeah, no.
  - nickpsecurity 11y ago
    Remind them that DOS was pretty small. Must be way more secure than Linux due to reduced attack surface. ;)
viraptor 11y ago
From the Alpine linux site: "Alpine Linux was designed with security in mind. The kernel is patched with grsecurity/PaX out of the box, and all userland binaries are compiled as Position Independent Executables (PIE) with stack smashing protection. These proactive security features prevent exploitation of entire classes of zero-day and other vulnerabilities." I got excited, but then remembered - grsec will not affect containers. Neither will PaX unfortunately. PIE + stack smashing protection is already available in most serious distros. From the basic info I can find, I don't see a huge difference. For comparison Ubuntu provides its list here: https://wiki.ubuntu.com/Security/Features https://wiki.ubuntu.com/Security/Features It's similar to Fedora: https://fedoraproject.org/wiki/Security_Features_Matrix https://fedoraproject.org/wiki/Security_Features_Matrix And to Arch (no nice table though) https://wiki.archlinux.org/index.php/DeveloperWiki:Security https://wiki.archlinux.org/index.php/DeveloperWiki:Security - Alpine doesn't seem to provide similar summary. [edit: sorry, I stealth-edited the realisation]

hogeland 11y ago

Good, using Ubuntu as a base for official images always seemed dumb.

bcook 11y ago
Explain (consisely).
- infamouscow 11y ago
  Because all you're really doing is increasing your attack surface and wasting storage space. If you have a need for a specific piece of software, you should be able to identify that and include that in your docker image. Starting with a kitchen sink is only good when you're too lazy to spend an hour to understand what your software depends on.
  - lisivka 11y ago
    If you run _same_ application in container with 20MB of files and in container with 2000MB of files, how it can affect attack surface at all? Bytes on disk are just data. Moreover, if I use standard RPM package to run service using non-root user in limited environment using Systemd, then it will be much less riskier than running same service in container using root user, by order of magnitude less safer. Container are not solution to problems with security. Much often they are huge security hole.
siliconc0w 11y ago
Ubuntu is great because people already understand it and probably already know how to install their apps on it which makes moving to Docker easy. Most businesses unsurprisingly don't like the idea of running on a OS they never heard of with tooling their engineers don't have experience with, limited community or enterprise support, or even internal repos. Alpine may be the 'technically correct' choice but Ubuntu is easily a much better business choice.
- vidarh 11y ago

sandGorgon 11y ago

What worries me about Alpine is that it invents YET-ANOTHER package manager(apk) . I think it claims that it builds on top of Gentoo... But could someone explain why Deb or rpm could not be used. Does using Deb or rpm screw up size or security in some way. We could also have gotten access to the Debian/Fedora repository in a pinch. Not all of us run statically compiled go executables and often have tons of dependencies that need to be installed for webapp. P.S. And the package manager apk is unfortunately named to conflict with IMHO the biggest package repo in the world:Android. It is virtually impossible to Google anything meaningful without running into android.

digi_owl 11y ago
From their wiki, the format itself it basically a tar.gz wrapped in a digital signature.
monkmartinez 11y ago
What is the fall back if a package is not available? For example, I was able to find an APK for python 3.5.1-r0. However, I can find nothing for Python 3.4 except a bug report and some hacky fixes. Also, it looks like running anything that require binaries that have compiled against glibc will be wonky as hell.
- jwatte 11y ago
  The whole point is: Do not run with glibc! If you need something that's not available, build it.
  - monkmartinez 11y ago
    Then I am debugging builds, no?
  - seanp2k2 11y ago
    We've been down this road many times before. It does not historically lead to happy places. Why will it be different this time?

hharnisch 11y ago

Does DNS based service discovery work yet? If not these images don't play nice with kubernetes.

shykes 11y ago
Yes. And Docker 1.10 does DNS service discovery out of the box.
justincormack 11y ago
Based on my understanding of the threads on the Musl list, part of this was some features that are now implemented in Musl, and part was Kubernetes using DNS in ways that are incorrect.
deleted 11y ago
[deleted]
steeve 11y ago
Don't have the link here to musl added domain support on Jan 26 2016, so it's close :)
- steilpass 11y ago
  As far as I can see it's currently in master: http://git.musl-libc.org/cgit/musl/commit/?id=3d6e2e477ced37fd328870f018950b283cb7293c http://git.musl-libc.org/cgit/musl/commit/?id=3d6e2e477ced37... But has not been released yet: http://wiki.musl-libc.org/wiki/Roadmap#musl_1.1.13 http://wiki.musl-libc.org/wiki/Roadmap#musl_1.1.13 http://git.musl-libc.org/cgit/musl/ http://git.musl-libc.org/cgit/musl/

gizi 11y ago

I agree with snubbing glibc, systemd, and apt-get. Seriously, it is about time to put an end to the bloated fatibubbul fest going on over there! I intend to move my dockers to alpine. I will only come back to debian after and not before they have downsized, trimmed and layed off all the useless fat around their bellies!

digi_owl 11y ago
Dunno if it is about snubbing, but i get the impression that having systemd inside the container makes it damn hard to work it if you do not also have it outside the container. And at that point, systemd is likely to take over control completely rather than play nice with docker.
- ownagefool 11y ago
  Na, that's not how it works at all. When you run a docker container, you'll be running your app directly, thus systemd won't be involved and isn't even needed within the container. The problem with debian and centos is they weren't create with containers in mind, thus by default their base images pull in a lot of stuff that's required to actually init hardware. We can see with fedora that efforts have been made to slim it down, I suspect as containers become a popular usecase we're going to see smaller base containers, except with access to 30,000 stable packages and a mainstream community.
  - digi_owl 11y ago
    Could have sworn i had read something about using systemd inside containers hosted by systemd.
    - ownagefool 11y ago
      You might find people attempting to start systemd as pid 1 then running their containers as sort of lightvm, but that's not really the typical use case. More common is folks not wanting to deal with splitting processes that are grouped together such as an internal gitlab instance that has, nginx, unicorn, postgres, ssh, and sidekick running. Best practice is arguably that you should be able to run all these processes in different containers and share the directories or sockets where possible, but the pragmatist is probably running them together using supervisor.

dschiptsov 11y ago

So, that Alpine linux has more man-power and resources to maintain kernel and core libraries stability and binary compatibility than Ubuntu (with its huge community) or Fedora/RH/CentOS (with its money)? Does Oracle runs on it?

ageofwant 11y ago
Alpine is built by one guy, that now works for Docker. So I understand. I really hope I'm wrong.
- uggedal 11y ago
  Alpine is not built by one guy. There is only one creator though.
RaleyField 11y ago
ls -l ~/.bashrc

ARothfusz 11y ago

Why does the size of a base image matter? What happened to the shared layers between images? Did the new file systems completely sacrifice that? The original filesystem (AUFS) used shared read-only layers, so if two images used the same base image, only their differences contributed to disk usage. I know there has been a lot of work to move to filesystems supported by more kernels, but if shared layers have been sacrificed, that makes me sad.

vidarh 11y ago
> Why does the size of a base image matter? What happened to the shared layers between images? It matters because when bootstrapping new hosts you still need to download all the base images, and because in many systems the base images can come to totally dominate the storage needs. It still can often save a lot, but it's not enough for a lot of places where people want to use Docker.
- icebraining 11y ago
  It matters because when bootstrapping new hosts you still need to download all the base images Why not just put those images in the snapshot/installer you're using to initialize those hosts?
- lisivka 11y ago
  If you need a library, you will download it anyway. But you can download it once, in base image, or multiple times. IMHO, the fatter _base_ image is, the better. Ideally, base image must be full installation of everything, one large image for all. You will just download it, and it will just work.

ageofwant 11y ago

This is silly nonsense. Before I care about image size or "security", I need to ship my products. After I've accomplished that, I make sure my firewall is still good and if necessary buy $20 more volume space. You have "solved" a problem that no one has. I don't care about image size, and neither should you. I don't care about container security, and neither should you. How does struggling with a anaemic non-distribution hacked together by a handful of kids that believes software is about size and "security" help me accomplish shipping shit ? It does not. This decision is ill-advised.

duaneb 11y ago

The base image size does not explain the switch in package manager. Why not use the ubuntu one, and simply trim the base image to minimal? What a waste of energy for everyone so they can save a few cents on bandwidth.

tommis 11y ago

To you complaining "its just one guy maintaining the distro" etc. Did you not read the article? > Docker has hired the creator of Alpine Linux, Natanael Copa <

pepijndevos 11y ago

From the Alpine website, the iso is 82 MB. What's up with that?

profmonocle 11y ago
Well, the ISO includes the Linux kernel. A Docker image only comes with user space components since the host provides the kernel, so an ISO would need to be larger.
- steeve 11y ago
  Boot2docker creator here (although I don't actively maintain it) TCL is only 9 mb, oh which the kernel is 4mb if my memory serves me well. So most of the size is likely not due to the kernel (modules maybe?) I'd like to see an Alpine based b2d though

diebir 11y ago

Awesome, can we now move Docker somewhere ever further, where it can't be seen or found all together?

gaius 11y ago

Red Hat, Debian, Suse. Stood the test of time. Everything else is not a wise choice for anything but a personal system.

digi_owl 11y ago
Slackware?
- gaius 11y ago
  Sure, but my point stands. Will Alpine exist in 5 years, 10 years?

tianon 11y ago

Primary curator of the program here (https://github.com/docker-library/official-images/blob/319cb294e869a54985fb4beb9d862982a8cc99ce/MAINTAINERS#L1 https://github.com/docker-library/official-images/blob/319cb...). "Moving" is a bit of a strong word. It would be much more accurate to say "providing alternatives". For example, the "golang" image now has an "alpine" variant for each supported version (https://hub.docker.com/_/golang/ https://hub.docker.com/_/golang/), but the default variant is still Debian-based (especially given that switching the base outright would break far too many existing Dockerfiles). Additionally, the documentation calls out that there might be libc compatibility issues in the spirit of trying to ensure our users are properly informed about the potential problems they might run into in their quest for the smallest possible base: https://github.com/docker-library/docs/blob/b7b6b86124682ef11a349b84b27bda24ba53f41f/.template-helpers/variant-alpine.md https://github.com/docker-library/docs/blob/b7b6b86124682ef1... I would definitely welcome PRs to make this verbiage more accurate or more informative of pros and cons.