Docker Official Images Are Moving to Alpine Linux

[sandGorgon]

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.

[JasonSage]

Alpine uses the musl libc and the OpenRC init system. In order for a deb or rpm package to install correctly, the binary would have to be built for musl already and the necessary information to set up services on the init system be provided. I don't know how the latter works for other package managers, be it in a way compatible with OpenRC or not.

P.S. In my experience APK has been rock-solid and simple to use.

[monkmartinez]

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.

[ape4]

The name conflict with Android make this the worse named piece of software. Any other name would be better.

[digi_owl]

From their wiki, the format itself it basically a tar.gz wrapped in a digital signature.

[tianon]

Primary curator of the program here (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/), 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/b7b6b86124682ef1...

I would definitely welcome PRs to make this verbiage more accurate or more informative of pros and cons.

[iso-8859-1]

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]

Exactly what I thought while I was reading that sentence.

[JasonSage]

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]

Wait, the future of Alpine is dependant on 1 person? I'll stick with Ubuntu I think

[jmspring]

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).

[viraptor]

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 It's similar to Fedora: https://fedoraproject.org/wiki/Security_Features_Matrix And to Arch (no nice table though) https://wiki.archlinux.org/index.php/DeveloperWiki:Security - Alpine doesn't seem to provide similar summary.

[edit: sorry, I stealth-edited the realisation]

[mverwijs]

This does not give me a vote of confidence: http://lists.alpinelinux.org/alpine-security/

[hiou]

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"

[ARothfusz]

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]

> 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.

[regecks]

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.

[kylequest]

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.

[gtaylor]

I've ran into this as well. Having a hard time remembering what the issue was. Maybe DNS-related?

[GauntletWizard]

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]

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.)

[kev009]

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

[lisivka]

musl is about 2x slower than glibc: http://www.etalabs.net/compare_libcs.html . Other libraries are even worse.

[gtirloni]

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.

[u320]

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.

[sandGorgon]

+1 I would love to have a stripped down Debian 8 base.

[tommis]

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 <

[hackerboos]

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.

[kylequest]

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-do...

I still prefer to use DockerSlim to shrink images. I'm too lazy to worry about the Alpine gotchas :)

[bleakgadfly]

Alpine Linux has a glibc solution. The glibc problem lies with other applications.

[hogeland]

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

[siliconc0w]

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.

[bcook]

Explain (consisely).

[gaius]

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

[digi_owl]

Slackware?

[auvi]

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

[Zekio]

Damn, the Alphine linux ISO is tiny

[duaneb]

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.

[gizi]

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]

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.

[pepijndevos]

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

[profmonocle]

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.

[hharnisch]

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

[shykes]

Yes. And Docker 1.10 does DNS service discovery out of the box.

[steeve]

Don't have the link here to musl added domain support on Jan 26 2016, so it's close :)

[justincormack]

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.