Micro Cures

High Time to Migrate

On the project's website, the team behind Flatcar provides ISO images for the install. Alternatively, the microdistribution can be rolled out with a network-based deployment tool. Moreover, a migration from CoreOS to Flatcar Linux is possible or, you might say, necessary. If the vendor is no longer supplying updates for the old system from November onward, migration already takes the highest priority.

A migration from CoreOS to Flatcar Linux should not be imagined in the way you would expect with a classic Linux distribution after a major update. As I mentioned earlier, the project is making sure that Flatcar Linux stays compatible with CoreOS. You can therefore migrate a system on the fly without problems. If you have implemented working automation for server lifecycle management, you can alternatively migrate existing servers without content and reinstall them.

Which of these approaches will be faster and more convenient depends on the respective application scenario. However, practically, you can install Flatcar Linux with Matchbox and Ignition, as was the case with CoreOS.

One-to-One Successor

Once rolled out, Flatcar Linux keeps the promise of being a one-to-one successor to CoreOS. All services known from CoreOS are also included, such as the familiar command-line environment. Etcd can be established in a few seconds as a central configuration repository in cluster mode between the different Flatcar instances. Additionally, the micro-updates for the individual CoreOS components, which can be easily installed during operation, have been kept.

Briefly summarized: If you install Flatcar Linux, you basically get CoreOS with an update promise that can then serve, for example, as a generic basis for Kubernetes. Flatcar does not tie the user into a certain Kubernetes distribution – Kinvolk even sells its own Kubernetes as an open source product named Lokomotive, which can be used on Flatcar systems.

The Kinvolk update service, which is basically centralized patch management for your own Flatcar Linux instances, also proves to be very practical and has a certain similarity to Ubuntu's Landscape, although it is based on the open source project Nebraska (Figure 5).

Figure 5: Kinvolk is based on Nebraska and offers a central update service for Flatcar Linux. © Nebraska

At least one small hair has landed in the Flatcar Linux soup: If you are already the maintainer of your own distribution or a distribution within the framework of a Linux project, you will be familiar with the resulting overhead. Naturally, the manpower required for microdistributions is less than for a full-grown Debian, but still significant. Whether Kinvolk will be able to cope with this overhead in the long term remains to be seen.

Kinvolk also has provided little information on whether and to what extent they will be providing new functions through updates. That they want to retain compatibility with the original CoreOS for the foreseeable future is certainly a great relief for existing products and workloads. Experience shows, however, that sooner or later, the desire for new features is unavoidable. Only time will tell how Kinvolk deals with this issue.

Warning Words

One thing is clear: Containers give admins various shortcuts and make maintaining and operating Linux systems easier than before. If you strictly rely on official containers and get them directly from the respective developers (i.e., Kubernetes Helm or as a Snap or Flatpak), you don't need to worry about the security issue – at least not any more than with packages. The distributors also do a good job with their container images and update them in step with the discovery of security vulnerabilities.

On the other hand, it is not a good idea to fish around and roll out arbitrary container images off the web. It doesn't matter if you choose k3OS, Flatcar, or any other microdistribution. Their advantages are usually ruined if you drag a black box in the form of an application into the house. Whereas containers for Docker and others are quickly built, "running in VMware on my MacBook Air" is not a functional benchmark for production.

Practically, you should build your own container images for the applications you want to run on Flatcar. However, this requires a functional continuous integration and continuous delivery or deployment (CI/CD) approach, at the end of which git commit ensures that a Git directory becomes an executable container. Setting up such a system is certainly complex, but the work can be easily automated.

In return, admins will benefit from lean systems and completely automated containers in which bugs can be fixed quickly in everyday life. This concept, also known as immutable underlay, should be the benchmark for new environments in the year 2020. In any case, the manufacturers of the large distributions should do their utmost to push their users in exactly this direction.