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.
P.S. In my experience APK has been rock-solid and simple to use.
For a startup like mine, I already estimate I'm installing hundreds of libraries (Ruby gems, Python wheels, etc). I'm pretty sure some of them are weird dependencies... but I have come to trust apt and dnf.
There is zero reason for me to trust Alpine's new package manager that is managed by a single dev. Disk space is cheap - my time is not.
This is the big blocker - if Alpine can figure out a way to co-exist with apt or dnf (pick your own poison), that makes it compelling.
But then again, I would ask - can something like Alpine be achieved with debian or centos. Even if it is 3X the size (30mb) ?
EDIT: I run a fat docker VM based on debian with nginx, rsyslog, postgresql and ruby+puma using supervisord. There is absolutely ZERO need for OpenRC. I have been running this in production for over 18 months since before Docker was this stable.
No. In the past I've tried several times to create a lightweight Debian derivative that would still allow me to install Debian/ubuntu packages from their repositories. The smallest I've been able to get things without completely breaking everything was around 230mb. This required lots of ugly hacks such as post install triggers that would remove useless garbage such as /usr/share/doc/ and man pages.
It's simply not possible to take the Debian eco-system and magically turn it into a slim version of itself.
I would never run Alpine stand-alone on a server. But for containers, it's absolutely amazing. I don't need the full Debian ecosystem. All I need is some basic tools such as NPM, Pip or gem. They can take care of the rest. The whole point of containers is to escape from the dependency and package hell that we're currently in.
# debootstrap stable mydir
# chroot mydir apt-get remove -y vim-common nano netcat-traditional e2fsprogs
# chroot mydir apt-get clean
# du -sh mydir
for p in $(dpkg --get-selections | cut -d $'\t' -f 1); do echo $(du -kc /x $(for i in `dpkg-query -L $p`; do [[ -f $i ]] && echo $i; done) | tail -n 1 | cut -d $'\t' -f 1) $p; done | sort -n | tail
Compressing Apt indices saves another 20MB 
The system is now down to 123MB.
this is by one of the posters above you. its called Dockersl.im
> Here are a few numbers to give you an idea (using on Ubuntu 14 base image):
> node: 431MB -> 14MB python: 433MB -> 15MB ruby: 406 MB -> 14MB java: 743MB -> 100MB
What happens when your npm/pip/gem package depends on a C library like libpq or libsasl2? Restricting yourself to pure JS/Python/Ruby code to avoid having a few MBs sitting on the disk sounds like a terrible tradeoff.
When I trying to optimize my system of containers, I move everything common into topmost container, to make application containers smaller. You are doing opposite. Why?
There's a way to have small Docker images using the standard distros like Ubuntu where you get to use your favorite packages. DockerSlim  was created for this. It collects the artifacts your are actually using in the container throwing everything else away...
Here are a few numbers to give you an idea (using on Ubuntu 14 base image):
node: 431MB -> 14MB
python: 433MB -> 15MB
ruby: 406 MB -> 14MB
java: 743MB -> 100MB
It's a work in progress, so there might be corner cases where it's less than ideal. It's not tested well enough with "fat" images. Pull Requests are greatly appreciated :-)
You also get auto-generated Seccomp (already usable) and AppArmor (WIP) profiles, so you don't have to create them manually.
You should have posted this independently - there you go https://news.ycombinator.com/item?id=11046797
could you put up some precreated docker images that we can pull and test out ? That should really be the quickstart.
The quoted numbers are based on the set of sample apps you can find in the repository. Take a look in sample/apps. You'll see the code and the Dockerfiles that go along with them.
I haven't thought about publishing the images. Thanks for the idea!
Luckily since this is Docker you can just use a 'fat' container as base if you need the CentOS/Fedora/Debian/Ubuntu platform.
(inactive Alpine dev).
Also, it looks like running anything that require binaries that have compiled against glibc will be wonky as hell.
Then use another distro if you're not prepared to invest the effort into it. The point of people wanting to move Docker images to distros like Alpine is to minimize size. That matters if you're going for massive density etc., but depending on your use cases, using e.g. Ubuntu or Debian or Centos as a base can be just fine.
It's worthwhile to move the official images to it because they are used so widely. It's not necessarily worth it for every random image someone puts together.
If the 'alpine experiment' results in more work on portable build tools for complex projects, that's a win for the open source community.
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?
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?
Why is this so difficult? It does not put any constraints on the user that vendors of proprietary software haven't artificially erected.
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.
"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.
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.
Can't be too sure though, maybe they're all aliases of one person.
Maybe Docker can reveal more there, though given how they iterate and things break, I'm not sure they are willing (or capable).
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]
Edit: I see your edit. Yep.
Not saying you need to agree with that. But that does appear to be at least an "indication"
This is complete hogwash from a security point of view.
Yes "smaller" could = "more secure", but, yeah, no.
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.
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.
Ideally, base image must be full installation of everything, one large image for all. You will just download it, and it will just work.
Why not just put those images in the snapshot/installer you're using to initialize those hosts?
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.
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.)
dnf --releasever=23 --installroot=/tmp/myimage install <package-name>
rm -rf /tmp/myimage/var/cache/dnf
tar zcvf - /tmp/myimage | docker import - myimage
This could probably be slimmed down further with custom versions of the base packages.
sudo apt-get install debootstrap
sudo debootstrap jessie deb8
> Docker has hired the creator of Alpine Linux, Natanael Copa <
I still prefer to use DockerSlim to shrink images. I'm too lazy to worry about the Alpine gotchas :)
Alpine may be the 'technically correct' choice but Ubuntu is easily a much better business choice.
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.
With tons of packages available (with patches and live maintainers). With formal stabilization process. With well tested package management system (with hundreds of bug fixes in 20 years of use). Which can be used as host and as container (so you will need to learn well and support just one OS). With Systemd, which handles daemons well. With well supported LTS version (RHEL/CentOS). With option for paid support. With glibc, which is much faster and feature-richer than musl.
Why I should use Alpine, which cannot even handle versioned dependencies between packages? Literally, I cannot tell that package A needs package B >= 3.x or package C < 2.x, which causes serious troubles in complex systems.
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.
If Alpine did what RHEL does out of the box it would be hundreds of MBs as well.
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.
What a waste of energy for everyone so they can save a few cents on bandwidth.
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.
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.
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
But has not been released yet:
Does Oracle runs on it?
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.