Operating systems for the cloud and containers
Young Heroes
The role of the operating system in the IT universe is at a turning point. In the pre-cloud era, the operating system was the decisive and determining component. The cloud, virtualization, and the container have rocked and permanently changed the model that has the operating system at its heart, and a number of new approaches have emerged in its wake. A lean and secure infrastructure takes care of some of the tasks; the containers built on top of this infrastructure do the rest of the work.
More or Less
Grossly simplified, the value of the service provided by an operating system is measured with reference to the software it supplies. If the expectations of the existing core software drop, then the operating system needs to have less ballast in terms of packages. Distributors offering lean Linux systems follow this principle. In the simplest case, they reduce the amount of software supplied, but if they want to do a better job, they need to look in even more depth at processes, procedures, and other design principles.
The most popular distributions that follow the lean approach are CirrOS [1], Alpine [2], JeOS (just enough operating system) [3], and the operating system formerly known as CoreOS [4], now called Container Linux, which better matches the type of operating system discussed in this article.
Scrawny Ubuntu
CirrOS (Figure 1) is a good illustration of the principle of "less is more." The project is now more than five years old. The first public version 0.3.0 was released in October 2011; version 0.3.5 is the most recent. The source code is released under the GNU General Public License version 2 (GPLv2).
This tiny cloud operating system comprises two components, an Ubuntu kernel and Buildroot [5], which was designed to install Linux systems for embedded applications where space is usually at a premium – also true of the cloud and container environment. The space occupied by the operating system needs to be as small as possible. The Ubuntu kernel is used because Scott Moser [6] is the guy backing CirrOS; his day job is as Ubuntu Server Technical Lead at Canonical.
At the present time, CirrOS has pre-built images for 32- and 64-bit architectures from the Intel and AMD worlds. It also supports ARM and PowerPC, but not 64-bit systems [7]. The developers primarily understand their cloud operating system is a tool for testing or troubleshooting. OpenStack, for example, officially designates CirrOS as a testing image in its documentation [8].
CirrOS comes with a number of wizards, which all start with cirros-
(Table 1). All commands are shell scripts and thus allow a glance behind the scenes; however, they are not very well documented – either in the code or on the project website.
Table 1
CirrOS Helpers
Command | Description |
---|---|
cirros-apply
|
Calls appropriate data source |
cirros-ds
|
Searches for cloud-init data source |
cirros-query
|
Queries data from the cloud-init data source |
cirros-userdata
|
Processes a file with user data |
cirros-dhcpc
|
Specifies options for udhcpc DHCP client
|
cirros-per
|
Runs a command at the desired frequency |
cirros-status
|
Outputs important status information from CirrOS |
At bootup, the traditional SysVinit system comes into play. Toward the end of the boot process, CirrOS-specific scripts designed to work with the cloud-init
framework [9] then step in; the matching configuration files are found in /etc/cirros-init/
. The scope of supply includes templates for Amazon EC2, for a configuration drive (configdrive
), and for local starts without a cloud [10]. Thus, you can test the complete process of creating and starting up a cloud instance – including postinstall customization.
No surprises await under the hood. Data storage is handled by the almost venerable ext3. The use of BusyBox [11] for most executable programs and of Dropbear [12] as the SSH daemon is the logical consequence of the Buildroot underpinnings. Seasoned Linux admins should find their way around easily.
Container Service
CirrOS, JeOS, and – with some restrictions – Alpine are stripped-down operating systems; yet, they can be used universally. In principle, they can serve as a basis for any kind of task.
A new variation on the leaner, open source operating system started to enter the scene as containers proliferated. In contrast to the systems already discussed, the new systems are highly specialized: Their main task is to provide a foundation for the container.
Whoever had this idea first, the former CoreOS definitely cast the idea into a product. Purists might argue that Project Atomic [13] (and the commercial variant, Red Hat Atomic Host [14]) and the original Snappy Ubuntu Core [15] showed higher degrees of specialization.
Although the first versions of these lean systems saw the light of day at the end of 2014, their ecosystem is still evolving dynamically. For example, SUSE presented a kind of micro-operating system for containers at SUSECON in November 2016 [16] known as SLE MicroOS [17]. A few months ago, CoreOS renamed its own distribution to Container Linux [18]. The name is designed to make the operating system's orientation and objective more evident.
Buy this article as PDF
(incl. VAT)