
Super small Docker image based on Alpine Linux - antouank
https://github.com/gliderlabs/docker-alpine/tree/d751bb2bcacd2a6536280cdc7d313bc6584aa40e
======
kstenerud
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)

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

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

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

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

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

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

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

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

And yet it happens.

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

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

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

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

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

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

~~~
krisdol
>And yet it happens.

I can understand that argument. It's an edge case, and building a sane
Dockerfile on top of Alpine that runs applications through S6 (or runit),
which developers use for their applications is the way to go for me. This is
what phusion baked in?

>The SSH server is incredibly useful [...] (although it's not really necessary
anymore with docker exec).

It's an additional attack vector and, by your own admission, it's useless.
docker exec has been baked into docker for over a year.

>Or just run [cron] in-container to keep your service clusters together.

Per-container cron sounds painful. Then you have to deal with keeping every
container's system time in sync with the host (yes, they can deviate). Not
only that, if you have a periodic cron job that runs an app to update some
database value, scaling becomes bottlenecked and race conditions (and data
races) can get introduced. You are prevented from running multiple instances
of one application to alleviate load because the container has the side-effect
of running some scheduled job. Cron should be separate.

One can also choose the degree to which they want to throw out good practices
that prevent them from repeating others' mistakes.

~~~
ffk
Have you ever seen a container's system time deviate from a host? This makes
sense with boot2docker since it runs in a VM but I can't think of a reason
this would happen in a container.

~~~
_yy
Yes, time keeping is up to the host kernel. The time can't deviate in the
container.

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

------
nickjj
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
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"

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

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

~~~
technion
Yes, I found out Rails containers were problematic with Alpine because
therubyracer would segfault when run under musl. It appeared to be a known
issue at the time, though I haven't looked into whether it's fixed.

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

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

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

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

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

> run something which indicates more technological prowess than does Ubuntu:

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

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

They did, and they should be congratulated for that. I like to believe that
Debian learnt a hard lesson from its long delay.

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

Ubuntu on the server has essentially been Debian unstable-ish. It's not really
a case of learning another distro.

Your argument would also apply to running OS X Server, and I don't think
anyone outside of Cupertino thinks that's a good idea…

> There one difference between how I develop -- I don't develop to show my
> technological prowess

If you like, substitute 'competence' for 'prowess.' Running Ubuntu is like
running Windows: it's popular; it's not really _wrong_ ; it even has
advantages; but running Windows doesn't indicate any level of competence. In
Bayesian terms, P(competence | Ubuntu) < P(competence | ~Ubuntu).

~~~
rdtsc
> Your argument would also apply to running OS X Server,

And it does! Old work had a few in house servers with OS X. If it was free,
we'd see a lot more of it, I am convinced.

> If you like, substitute 'competence' for 'prowess.' Running Ubuntu is like
> running Windows: it's popular;

Isn't the ability to quickly ship a stable, reliable product that customers
are happy to pay for, a better sign of competence than say picking Slack or
FreeBSD for server for now good reason except to show competence?

The question is who is the show of competence for? Other developers,
customers, management? I can see developers boasting who knows how to
configure and run obscure distros and use exotic functional languages and
that's cool. I was just saying after a while you realize that show of prowess
is not what is important.

~~~
wtbob
> Isn't the ability to quickly ship a stable, reliable product that customers
> are happy to pay for, a better sign of competence than say picking Slack or
> FreeBSD for server for now good reason except to show competence?

Sure! What I'm saying is that if someone is unable or unwilling to run
something other than Ubuntu then I suspect he is less likely to be able to
build that stable, reliable product in the first place.

It's like how I suspect I'm likely to have a better meal if the cook prepares
it from fresh ingredients than if everything comes pre-made off of a truck.

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

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

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

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

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

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

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

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

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

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

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

~~~
felixgallo
quantity-of-people-involved is a terrible, irrelevant metric for code quality.

~~~
smt88
Maybe, but it's a fantastic metric when guessing how many undiscovered bugs
and security vulnerabilities there are.

GP also goes into some detail about the amount of discussion and updates to
Alpine Linux, which are excellent metrics for code quality.

~~~
felixgallo
Nonsense, it's just a straight up ridiculously uncorrelated, terrible metric.
Which would you say has been more buggy and broken, djbdns or php? nacl or
mysql? qnx or openssl? windows 95 or ping? Which one of each do you think has
had more "discussion and updates"? Which one of you think is better code?

Code quality has nothing to do with how much jibber-jabber there is on some
mailing list, nor with how widely used a piece of code is. It has to do with
the actual code.

In the case of Alpine Linux (which I've never used), probably 50% of the code
is the linux kernel itself, another 20% is musl and busybox, and the rest is
random gnu utilities. Which of those things is 'low quality' and has
'undiscovered bugs and security vulnerabilities' that broken, random, low-
quality high-politics tire fires like most linux distributions don't have?

But conversely, is it not intrinsically obvious that not having the grotesque
pile of random freshman desktop apps and terrible init systems that other
distros have, could reduce the attack surface to a point where a single
organization could conceivably make sense of it?

~~~
_euvw
You are correct on all points concerning the quality of code of Alpine Linux.
I do not doubt it. But it is irrelevant to the discussion. The Linux kernel is
not part of the containers that are based off of Alpine. That is the whole
point of this level of virtualization: sharing the kernel.

Furthermore, the problem I have with Alpine-based containers is that using
those as the basis of tooling used for building your own product, your own
product will have a hard time becoming maintainable, sustainable an secure.

I've had developers doing make; make install in Dockerfiles just because
Alpine doesn't have some library or version packaged.

Containerization brings all manner of sweetness to the table, but the current
way it is used is a throwback to 1998.

Not having desktop software inside a small container does reduce the attack
surface. Debian, Ubuntu, Centos can handle that requirement just fine. What is
your point?

~~~
felixgallo
Your sentences don't make sense next to each other. If you're unable to point
to any fault in the quality of Alpine Linux, then why are you trying to create
FUD about how Alpine Linux is unmaintainable, unsustainable, and insecure?
Could you maybe, instead of just repeating it over and over without evidence,
provide some example of how Alpine is concretely any one of those things?

While you're at it, please show me the Debian, Ubuntu, or CentOS distribution
that doesn't have desktop bus installed. I'll wait.

~~~
mverwijs
Appologies if I am unclear.

> why are you trying to create FUD about how Alpine Linux is unmaintainable,
> unsustainable, and insecure?

I never tried to make that claim.

What I am trying to say is that if YOU built YOUR software against Alpine, IT
will be hard to maintain/sustain/insecure. Because your software will probably
have dependencies. Dependencies not found in Alpine. And now you have to
maintain and test those dependencies. You'll have to keep informed on all the
security advisories of those dependencies. All the changelogs. And by then,
you've started to reinvent wheels that the fine folks of Debian, Ubuntu,
Centos have invented already.

That is a resource drain on companies that is inefficient and cumbersome with
little to no added value.

> While you're at it, please show me the Debian, Ubuntu, or CentOS
> distribution that doesn't have desktop bus installed.

A container is not the same beast as a distribution. It does not have the same
requirements. It is just a tarball. And you can throw anything into it, or out
of it.

I'm just saying to use debootstrap to throw stuff in that tarball so you have
the benefits of an enterprise-level, proven distribution, instead of using
this something that has not yet proven itself. So if you ever need to take
your software OUT of the container and run it on an AWS instance, or on your
own hardware, you'll have no problem with it.

In short: I see no added value for Alpine. It does not address my operational
concerns, and raises a bucketload of new ones when I compare it to Debian,
Ubuntu or Centos.

~~~
felixgallo
That makes a little more sense, thanks. Although, I will disagree that your
software will probably have dependencies that are not in Alpine; I tested it
out and installed a large software stack and found no such issue. And I think
you radically underestimate the crumminess and incompetence of the, e.g.,
debian package system. Nevertheless, good luck with your systems and Merry
Christmas.

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

------
okasaki
Interestingly, alpine doesn't use systemd.

~~~
dbalan
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]

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

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

------
anderspitman
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-
co...](http://blog.xebia.com/create-the-smallest-possible-docker-container/)

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

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

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

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

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

------
rockyj
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
Why can't you build an image with the JDK based on Alpine and use that as your
base image for everything else?

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

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

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

~~~
raverbashing
It's a good practice nonetheless

It's not about only size (though getting something that's 10x-20x smaller is
helpful)

It's about getting only what you need, reducing security issues, disk usage,
memory usage, etc

~~~
cm2187
Makes sense.

~~~
NyxWulf
Impressive, I can't think of another time I've seen someone just acknowledge a
response like that on the interwebs. Most Impressive.

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

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

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

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

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

------
kylequest
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
Is that used heavily in production? Looking at a container based on usage, and
slimming sounds very risky to me.

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

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

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

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

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

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

~~~
iheartmemcache
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-...](https://www.gnu.org/software/guix/manual/html_node/Invoking-
guix-package.html) 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.

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

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

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

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

~~~
Gigablah
> so I pay the download cost once

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

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

------
itomato
Alpine Linux has packages for Inkscape.

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

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

------
_pmf_
It comes with its own package format, naturally.

------
mickael-kerjean
Sounds great. Will definitely give a try !

------
scott_karana
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
Different apk format. Alpine linux apk is just a tar.gz of a signing key,
.APKBUILD file and the files rooted in /

~~~
scott_karana
Whoops, yeah.

[http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package](http://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package)

