Review: Alpine Linux is made for Docker

Alpine Linux is a minimal Linux distribution, originally built with Gentoo, but now independent and self-hosting. In some respects Alpine Linux is conceptually similar to NanoBSD, in that technical users can start with Alpine Linux to build a Linux system with just what is need to accomplish the mission, and nothing more.

Typically seen embedded in devices or appliances, Alpine Linux got a big boost when it was selected to replace Ubuntu as the base image for Docker. Security, reliability, and solid development practices were the main reasons.

Alpine Linux is unlike any Linux distribution that a typical Linux desktop user will have encountered. Let’s start by looking at the /bin directory, where system utilities are kept: 

IDG

Notice that nearly all binaries are links to /bin/busybox. Busybox is a set of common user and system utilities packaged into a single binary for faster startup, lower space requirements, and generally better security, at the cost of reduced functionality. Many of the infrequently used options to the utilities have been removed, but all of the commonly used options remain.

In addition to this, Alpine uses musl libc, a minimal implementation of the standard C/POSIX library and extensions, designed for static linking and real-time embedded applications, avoiding the GNU-bloat of glibc. Static linking means faster startup, but takes more space, so is best suited to smaller systems. By combining all system binaries into a single executable and linking with musl, Alpine gets a small and fast set of system binaries, which is what is required in an embedded system.

Finally, there is a focus on security. The system includes Grsec/PaX kernel patches, which provide a collection of security features to the Linux kernel including address space protection, enhanced auditing, and role-based access and process control. With typical Linux distributions, users would have to compile and run their own kernel to get these patches, something even most advanced users would probably avoid.

Alpine Linux installation and configuration

There is a lot that is unusual about installing Alpine Linux. This is mostly rooted in its original intended use in embedded systems, like routers. As such Alpine is designed to boot and run from RAM, though hybrid options are available. In keeping with this origin, Alpine Linux uses extlinux, a Syslinux variant, as its bootloader. Syslinux is not normally used for booting full Linux installations because Linux is not normally installed on FAT file systems. Instead, Syslinux is often used for boot or rescue floppy discs, live USBs, and other lightweight boot systems. Alpine uses parts of the Syslinux project to allow booting from CD-ROMs, and uses extlinux to boot from Linux filesystems or FAT filesystems for USB devices.FAT filesystems have some limitations, such as size of files and length of filenames.

Alpine supports three installation modes: diskless, “data,” and “sys.” In a data installation, the OS is loaded into RAM from read-only media, but mounts read/write partitions to store data. This might be used, for example, if a router based on Alpine were storing intrusion or access logs on a disk. Copying logs into RAM would be a waste of a valuable resource. Diskless mode is similar, but the read/write partition is usually smaller, and used to store OS configuration details. Sys is a traditional disk-based installation mode.

When installing in diskless or data mode, the Alpine Local Backup system is used to store configuration files. This is done with lbu (local backup utility), which tracks files that have changed in the /etc directory and saves those changes in .apkovl "overlay" files (tar-gzip archives). With lbu, administrators can, for example, compare, merge, or revert to prior configurations.

I began by attempting a diskless install because I wanted to run Alpine as it was originally intended, as an OS for appliances. Sadly, I encountered a longstanding (2015) bug in a VMware install that hasn’t been repaired, nor has the documentation been updated. It seems that the virtual floppy image is not being mounted at boot time. This means that configuration changes are lost at each reboot.

I finally resorted to a sys installation, which went just fine. The first thing to notice is that nothing, not even SSH, is installed by default. If  building embedded systems, this is probably a good thing. Linux newbies should prepare for a steep learning curve. After reading a bit about the Alpine Package Manager (APK), I installed a minimal set of tools to get started: Sudo, SSH, and the web-based graphical system management tool, ACF.

Alpine Linux system administration

Whereas most Linux systems have a graphical system administration tool, Alpine uses shell scripts for setup. I used an umbrella script, setup-alpine, to configure all the basics such as networking, host name, disks, time zone, etc. Although setup-alpine is sufficient to get a workable system, anything more advanced will require editing system configuration files directly and using lbu to save them to writeable media. Note that setup-alpine is also the installer, so a disk name can be provided and it will write the OS to media, prompting for a writable partition for the /etc and /var directories.

Developing and distributing software is different on Alpine too. Partly this is because of its intended use in embedded systems, or as a base image for containers, but also because the authors felt that existing package management systems would not function well in a system usually run from RAM. The Alpine Package Manager (APK) meets all these requirements, with low overhead and fast installation times. However, I wish they had layered over an API that was more standard. We have enough package management APIs already, and there is something to be said for compatibility. APK is used to configure containers or standalone systems.

Delivering packages is done via a ports tree that reminds me of FreeBSD’s ports collection. However, instead of being driven by a sophisticated makefile system, it uses another Alpine Linux invention, abuild. The aports repository mirrors the ports tree around the world, and apk add … is definitely a lot faster than other package management systems.

The other thing to notice about Alpine is the use of OpenRC for the init system. One of a dozen or so init systems for Linux now, OpenRC started in Gentoo (as did Alpine). Nothing is lacking functionally, but be prepared to learn a new system of run levels and init commands.

Fortunately much of the day-to-day administration can be done via the web-based Alpine Configuration Framework (ACF), though working with ACF wasn’t completely smooth. It did not detect the regular user I added for myself via adduser, for example. The ACF GUI looks a lot like the web interface of your typical Linux-based router:

IDG

ACF also takes some digging to find and install. A casual user would not have discovered the system unless attentive, and even then there are no installation instructions.

Alpine Linux storage and networking

Alpine supports several storage options beyond RAM-only, with configuration stored on a medium, and flash cards. However, the documentation, or rather lack of it, made understanding storage difficult. For example, I wanted to burn a custom ISO with an application that is not available in aports, likely a common enough occurrence. The documentation for doing so was a dead end:

IDG

Four-and-a-half years seems a long time to wait. To be fair, storage was never a big part of the Alpine equation, with its focus on embedded applications, so it is no surprise this should be a weak area. There is ongoing work in most of the areas expected from a Linux distro, such as LVM, iSCSI, and RAID, but prepare to spend a fair bit of time trying to make sense of the documentation, or reading the source code, to figure it all out.  

Networking with Alpine is a very different story than storage. The documentation for networking is better written and more complete, and often includes best practices for setting up efficient networks. IP4, IP6, bonding, VLAN, bridging, and pretty much any networking setup desired is supported. You’ll even find instructions for setting up satellite internet connections!

Configuration can be done with traditional tools like ifconfig and route, or some newer packages like iproute2. Worthy of mention is an interesting subproject called Alpine Wall, a Linux firewall configuration tool. Even PPP over serial lines is supported, which is somewhat surprising in this day and age.

I learned a lot reading this documentation, discovering several configuration hints I did not know before, as well as some heretofore unknown networking utilities. This part of the documentation is worth bookmarking as a quick reference for networking how-to, even if you’re not using Alpine Linux.

Alpine Linux upgrades and downgrades

Alpine Linux release engineering is not nearly as rigorous or formal as mature systems like FreeBSD, but it covers the basics. And it is well suited to Alpine’s primary use cases of Docker hosting and appliances.

There are essentially two streams, edge and stable. Edge is a rolling release branch, a snapshot of wherever development happens to be every six months. Packages move through edge and, when ready, are promoted to stable/community where they are supported for six months by the community. Packages that survive that and continue to develop eventually make it to stable/main, where they are supported for two years.

A bit of care needs to be taken when upgrading from the 2.x to 3.x branch because of the change in C libraries (from uClibc to musl). If you’re not careful, the system could fail halfway through an upgrade. Upgrading packages along the 3.x line is simpler, though still a manual process driven for the most part by scripts. The trick to understanding the upgrade process is to get the correct APK repository (community, edge, or main), clear the cache, and then let APK upgrade all of the packages with apk upgrade.

Upgrading the kernel is straightforward as well, and uses the setup-bootable script to write the new kernel and busybox to the boot medium.

Overall, there are not too many moving parts to an Alpine system, so once the architecture is understood, figuring out the upgrade is not difficult.

Alpine Linux at a glance

Alpine Linux is a great choice for any system that is network-oriented and single-purpose. Intrusion detection, network monitoring, and IP telephony are examples of good applications for Alpine Linux. And it’s a natural choice for containers. Applications that make heavy use of disk should be tested carefully. Users should prepare to spend some time getting involved in the community, and rolling up their sleeves to get their hands dirty. Trial and error will be required.