
Docker Official Images Are Moving to Alpine Linux - infodroid
https://www.brianchristner.io/docker-is-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.

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

~~~
jwatte
The whole point is: Do not run with glibc! If you need something that's not
available, build it.

~~~
FreeFull
And if it's a proprietary piece of software and you don't have the source
code? Or you do have the source, but the build process is too convoluted to
figure out?

~~~
newjersey
1\. If it is proprietary, we don't need it in docker. If they want to play in
this ecosystem, they have to make their source free.

2\. If the build process is too convoluted, we try our best to simplify it.

Building something like Mozilla Firefox might take a few hours the first time
but it will not always take that long. I for one would fully support this new
pro-source software distribution mechanism. We could probably use git tags to
find out when we have updates if we could get people to agree on some kind of
convention...

Processor vendors should love this change because every server will build all
the software it needs from source.

Edit: downvoters, care to leave a note?

~~~
tokenizerrr
> Edit: downvoters, care to leave a note?

Sure. You don't get to dictate what I run in MY docker containers hosted on MY
private registry used in MY environment. If I want to run proprietary software
in my docker containers, I damn well will. And I expect Docker not to work
against that, if just for the reason that it works fine today, why not
tomorrow?

~~~
newjersey
You're more than welcome to build that from source too! Where you get the
source code could still be a private, authenticated area. You could choose to
never publish your docker files. That's fine. I'm just saying that we should
move to a better model where if you distribute software, you should also
distribute the source code (and hopefully build tools) for it.

Why is this so difficult? It does not put any constraints on the user that
vendors of proprietary software haven't artificially erected.

~~~
monkmartinez
Talk about creating more problems than you solve. If this was such a good
model, why aren't all linux distros shipped with a minimal set of tools, where
the users are given a "go build it all yourself" note on the box? I will tell
you why; because it's a suckfest that can drag expert and non-expert linux
swashbucklers into the weeds for untold amounts of time depending on the
software that needs to be built.

~~~
newjersey
Just because something is a bad idea today doesn't necessarily mean it will
forever remain so. What we have today is far from perfect and I think any
effort to branch out is a good idea. In the worst case, we won't be any worse
off than we are today.

Of course, my whole idea depends on many things such as the hypothesis that
processing and storage will continue to get cheaper with time. I don't know if
it will be true. I hope it will though.

------
tianon
Primary curator of the program here ([https://github.com/docker-
library/official-images/blob/319cb...](https://github.com/docker-
library/official-
images/blob/319cb294e869a54985fb4beb9d862982a8cc99ce/MAINTAINERS#L1)).

"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/b7b6b86124682ef1...](https://github.com/docker-
library/docs/blob/b7b6b86124682ef11a349b84b27bda24ba53f41f/.template-
helpers/variant-alpine.md)

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

~~~
marshallford
I agree, if that is the case those using Alpine in production should be wary.

~~~
Gigablah
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
Those are indeed real people.

------
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](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]

~~~
jwatte
Having less crap in by default reduces the attack surface area. Having a
smaller libc makes it easier to audit. (It still needs to actually be audited
of course)

~~~
mentat
I'd like to hear who audits obscure libcs.

~~~
pyvpx
musl isn't very obscure to those who are..."into" (for want of a better term)
libc alternatives

~~~
mentat
Since I'm getting downloaded into oblivion over this, where is the latest
audit?

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

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

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

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

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

~~~
monkmartinez
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?

------
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](http://www.etalabs.net/compare_libcs.html)
. Other libraries are even worse.

~~~
hga
Note that comparison is by the musl author, but it's several point releases
old for it and glibc.

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

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

~~~
mverwijs

        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.

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

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

~~~
hackerboos
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)

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

~~~
vidarh
Nothing stops people from using the ubuntu images as the base for their own
containers, so this is pretty much irrelevant.

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

~~~
gaius
Sure, but my point stands. Will Alpine exist in 5 years, 10 years?

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

------
Zekio
Damn, the Alphine linux ISO is tiny

~~~
anon987
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
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
RHEL != Atomic

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

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

~~~
ownagefool
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
Could have sworn i had read something about using systemd inside containers
hosted by systemd.

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

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

~~~
steeve
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

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

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

~~~
steilpass
As far as I can see it's currently in master: [http://git.musl-
libc.org/cgit/musl/commit/?id=3d6e2e477ced37...](http://git.musl-
libc.org/cgit/musl/commit/?id=3d6e2e477ced37fd328870f018950b283cb7293c)

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

------
dschiptsov
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
Alpine is built by one guy, that now works for Docker. So I understand. I
really hope I'm wrong.

~~~
uggedal
Alpine is not built by one guy. There is only one creator though.

------
x5n1
w00t

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

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

