Now with the rise of containers upon us, we are seeing a lot of the same things happening as applications and services start to move into containers. And the shift of network control is continuing to move further into the servers.
Operating systems have all embraced the support for containers, including Windows now. CoreOS has emerged with a unique approach as a container focused server OS with Container Linux (formerly just CoreOS) and has built a solid reputation against the giants in the server world.
So lets dig into CoreOS as see what we can do with it!
Wikipedia - Container Linux by CoreOS
Datanauts 032: CoreOS, Tectonic & Building A Better Data Center
How To Use Cloud-Config For Your Initial Server Setup
Introducing Ignition: The new CoreOS machine provisioning utility
CoreOS Container Linux was first introduced in October of 2013 as a stripped down linux OS focused on containers. The primary features of Container Linux are:
• Automation and ease of deployment
Container Linux is a bare minimum OS using the systemd init system and etcd for clustering. In fact the OS does not even have a package manager built in. The only things included in the OS are what is needed to support a container environment such as docker, or CoreOS’s own rkt (pronounced rocket). All other applications and services are then installed within a separate container.
The first thing I noticed with Container Linux is its way more complex to get running. Out of the gate you notice its not a normal install and there is no install media to boot and install as we are used to with all other OSes. Install is done either with iPXE or from bootable media.
But just a base install will provide pretty much a useless server as it has no network setup or a way to ssh or login to the server. This all needs to be provided separately during install.
InstallTo initially configure the server, a remote configuration file which outlines the parameters and features used must be provided. This is done with either a cloud-config or the newer more flexabile ignition file.
Container Linux can also be setup directly to a local hard drive or iPXE booted with the OS stored in memory. After install the OS is mounted read-only so any changes are cleared out after a reboot.
At first this whole process is very annoying and frustrating. Why jump through all these hoops and complexities just to get a OS installed? Container Linux has several selling points on why you should use it:
• Clustering – Advanced, flexible and reliable clustering using etcd.
• Minimum footprint and resources for Cloud. Make the bean counters happy!
• Minimum downtime and outage from upgrades and updates
• Security and service isolation.
• Quicker deployments and scale-out.
ClusteringContainer Linux is designed to run within a cluster and Etcd is the preferred method of clustering. CoreOS has always sold the idea of distributed services and applications across a cluster and initially released Fleet to accomplish this. But they have recently retired Fleet and recommend shifting to Kubernetes. More on Kubernetes in future posts!
Patching and UpgradesSince all services and applications run within containers, OS upgrades and patches are de-coupled from application services. When upgrading, containers can simply be shifted to another node of the cluster.
With a read-only OS, applying patches and upgrades is a simple re-install of the OS. To do this Container Linux uses a secondary non-active boot partition to install the new version of Container Linux. Once the kernel is rebooted, the secondary partition is made active and booted. Container Linux then uses kexec to handle this process without needed a reboot. Pretty cool stuff!
To make updates even easier, CoreOS offers CoreUpdate as a part of your support subscription. This tool gives you a visual view of your clusters, what version they run and alloows you to manage patching and upgrades from a central location.
Now we know the basics of Container Linux and its benefits in a containerized environment lets get our hands dirty and install Container Linux in our lab topology! I will cover that in my next post in this series.