Hacker News Reader

Comment by JasonSage | Hacker News Reader

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.

View on HN

this is a huge blocker - we are already in a world where RPM and DEB dont get released in tandem. And it has taken millions of man hours to resolve deep problems in dependency resolution, circular dependencies,etc.

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.

Ehh I wouldn't worry about it too much. The whole idea behind these skinny distros is there are few if any packages. Distros can also consider using something like rpm-ostree[1] for making skinny, RPM-based immutable file systems where you only update the "master" image then push it out.

[1] https://wiki.gnome.org/Projects/OSTree

The package ecosystem is the biggest challenge for Alpine. It's just not there and there's only so much you can do yourself. You need to have enough critical mass before the majority of the 3rd party providers begin to release packages for Alpine.

There's a way to have small Docker images using the standard distros like Ubuntu where you get to use your favorite packages. DockerSlim [1] 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.

[1] http://dockersl.im

Is this your project ? DockerSlim is awesome!!

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.

Yes, I'm one of the authors. If you want to contribute too it'll be awesome and it'll be greatly appreciated!

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!

> But then again, I would ask - can something like Alpine be achieved with debian or centos. Even if it is 3X the size (30mb) ?

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.

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.

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.

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.

  # debootstrap stable mydir
  # chroot mydir apt-get remove -y vim-common nano netcat-traditional e2fsprogs
  # chroot mydir apt-get clean
  # du -sh mydir
  228M mydir

With a little more work:

    cat /etc/dpkg/dpkg.cfg.d/small
    path-exclude=/usr/share/locale/*
    path-exclude=/usr/share/man/*
    path-exclude=/usr/share/doc/*
    path-exclude=/usr/share/info/*

Saves about 15MB. Removing wget saves 50MB or so, since it uses a large library (libicu52).

    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
    2676 libssl1.0.0:amd64
    3084 tzdata
    3152 libc-bin
    3288 groff-base
    3652 iptables
    5224 coreutils
    5660 perl-base
    6036 udev
    10308 libc6:amd64
    13784 systemd

(Since I've removed things, `dpkg-query -Wf '${Installed-Size}\t${Package}\n'` isn't accurate.)

Compressing Apt indices saves another 20MB [1]

The system is now down to 123MB.

[1] https://wiki.ubuntu.com/ReducingDiskFootprint#Compress_files

Did you also try stripping out the locale's from glibc that you don't need? In CentOS that frees up about 150MB for me.

debootstrap already only comes with the minimum (en_US, I think).

Excellent. I was not aware of that, thank you!

Note the coreutils-single package in Fedora rawhide which can be used to get coreutils down to about 1MB. Details on that change at http://pkgs.fedoraproject.org/cgit/rpms/coreutils.git/commit...

You can also use separate build and deploy containers... build in a container with all the tooling you need, that exports out to a mount point everything needed to run, then turn that mount point into the new deploy container.

I posted this today - https://news.ycombinator.com/item?id=11046797

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

And your reason is ... to share less between instances? The more code in common, the better, isn't?

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?

Alpine is not managed by a single dev. There is no way for Alpine to coexist with Apt/RPM (where there are hundreds of diffrent distros/releases).

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

Reply on news.ycombinator.com