LXC: features, pros, and cons of Linux Con­tain­ers

Thanks to its user friend­li­ness, Linux Con­tain­ers is very popular and has now become an important component of IT security. The eponymous LXC (Linux Con­tain­ers) container platform is used to isolate several processes from one another and the rest of the system sim­ul­tan­eously. An image is then generated through vir­tu­al­isa­tion which allows every container to be con­tinu­ously portable and con­sist­ent from creation to test phase and until operation. As such, in­di­vidu­al ap­plic­a­tions have a virtual en­vir­on­ment but still col­lect­ively use the kernel of the host system.

What does LXC (Linux Con­tain­ers) provide? Is sim­pli­city always an advantage? And how many virtual machines are there in a Linux container?

The term Linux Con­tain­ers (LXC) applies to both vir­tu­al­ised ap­plic­a­tions in the Linux kernel as well as the un­der­ly­ing container platform, and tech­no­logy. This should be kept in mind when dis­cuss­ing al­tern­at­ive container platforms that also use Linux Con­tain­ers as their base tech­no­logy.

LXC is an open-source container platform that promises user-friend­li­ness and an intuitive, modern user ex­per­i­ence, which is quite atypical for container systems, through various tools, languages, templates, and libraries. In addition, the vir­tu­al­isa­tion en­vir­on­ment can be installed and used across all current Linux dis­tri­bu­tions.

The idea for Linux Con­tain­ers tech­no­logy came about in 2001. Initially, an isolated en­vir­on­ment was im­ple­men­ted within the framework of the VServer project. That was the basis for the es­tab­lish­ment of several con­trolled namespaces in Linux and for what is now called Linux Con­tain­ers. Other tech­no­lo­gies such as cgroups (control groups), which could control and limit the usage of resources for a process or an entire group of processes, then followed. After that came systemd, an ini­tial­isa­tion system for the man­age­ment of namespaces and their processes.

In practice, LXC allows for ap­plic­a­tions to be developed more quickly. Container tech­no­logy is useful for porting, con­fig­ur­a­tion, and isolation. Con­tain­ers also show their strengths when it comes to data streaming in real-time in that they provide the required scalab­il­ity for ap­plic­a­tions. Linux con­tain­ers adapt to an in­fra­struc­ture, and do so in­de­pend­ently to a large extent, so that they can be used either locally, in the cloud or in a hybrid en­vir­on­ment.

The basic idea of LXC does not appear to be very different from the idea of classic vir­tu­al­isa­tion at first glance. Only when looking at the broader context do the dif­fer­ences become more obvious. The most basic principle is the following: Con­tain­ers work at the level of the operating system, whereas virtual machines work at the hardware level. This means that con­tain­ers split an operating system and isolate ap­plic­a­tion processes from the rest of the system, whereas classic vir­tu­al­isa­tion allows several operating systems to run sim­ul­tan­eously on one system.

Linux con­tain­ers use fewer resources than a virtual machine and also have a default interface from which several con­tain­ers can be managed sim­ul­tan­eously. A platform with LXC can also be organised across several clouds. This provides port­ab­il­ity and guar­an­tees that ap­plic­a­tions running correctly on the developer’s system will also function correctly on every other system. Larger ap­plic­a­tions can be started or stopped, and their en­vir­on­ment variables can also be changed from the Linux Con­tain­ers interface.

To summarise, the goal of LXC is to create an en­vir­on­ment that comes as close as possible to a standard Linux in­stall­a­tion without the need for a separate kernel.

The current Linux Con­tain­ers platform uses the following kernel features to “enclose” ap­plic­a­tions and processes in con­tain­ers:

• Kernel namespaces (ipc, uts, mount, pid, network and user)
• AppArmor and SELinux-Profile
• Seccomp policies
• Chroots (using pivot_root)
• Kernel cap­ab­il­it­ies
• cgroups (control groups)

Linux con­tain­ers are meant to be compact. As such, they are composed of only a few separate com­pon­ents:

• the liblxc library
• several API language bindings:
  • python3 (long-term support in 2.0.x)
  • lua (long-term support in 2.0.x)
  • Go
  • Ruby
  • Python
  • Haskell
• an array of standard tools to manage the con­tain­ers
• dis­tri­bu­tion templates

Isolation and vir­tu­al­isa­tion are important because they aid in managing resources and security aspects as ef­fi­ciently as possible. For example, they make mon­it­or­ing for errors in the system easier, which often have nothing to do with newly developed ap­plic­a­tions. But how does LXC work? Or, to put it another way: how does Linux Con­tain­ers work?

The easiest and most sensible way to use Linux Con­tain­ers is by linking each container to a process, allowing for complete control. For each process, the namespaces that make resources available for one or more processes using the same namespaces are es­pe­cially important. The processes also act as access controls in securing the con­tain­ers.

To use an LXC en­vir­on­ment, the features and their functions have to be clear. cgroups (kernel control groups) limit and isolate process resources, such as CPU, I/O, memory, and network resources. In addition, the content of a control group can be managed, monitored, pri­or­it­ised, and edited.

The functions are easily un­der­stand­able, which has the advantage of making an LXC platform very beginner friendly. However, it also has some dis­ad­vant­ages which will be explained in the following section.

The user-friend­li­ness of Linux Con­tain­ers is its greatest advantage in com­par­is­on to classic vir­tu­al­isa­tion tech­niques. However, the in­cred­ible spread of LXC, a virtually all-en­com­passing ecosystem along with in­nov­at­ive tools, can mostly be at­trib­uted to the platform Docker which brought about Linux Con­tain­ers. When compared to other container systems like rkt, OpenVZ, and Cloud Foundry Garden, which are sig­ni­fic­antly more limited in their usage, LXC benefits from its close ties to the fore­run­ner in container platforms.

A system ad­min­is­trat­or who has already worked with a hy­per­visor-based vir­tu­al­iz­a­tion method like Hyper-V will have no problems using LXC. The entire set-up, including the creation of container templates and their de­ploy­ment, the con­fig­ur­a­tion of the operating system and es­tab­lish­ing con­nec­tions, and the de­ploy­ment of ap­plic­a­tions, remains the same. All scripts and workflows that have been written for virtual machines can also be used for Linux Con­tain­ers. As such, de­velopers are not given new, cus­tom­ised solutions or tools but can seam­lessly continue to work in a familiar en­vir­on­ment with their own scripts and auto­ma­tion workflows.

One major dis­ad­vant­age of LXC becomes very obvious when it comes to memory man­age­ment: Even though various memory backends are supported (Ivm, overlayfs, zfs and btrfs), everything is saved to rootfs by default. There is no pos­sib­il­ity to register images. In this respect, other container platforms offer smarter and more flexible solutions, both for saving con­tain­ers and the man­age­ment of images.

LXC is an open-source project that is fin­an­cially supported by Canonical, the company behind the Linux dis­tri­bu­tion Ubuntu. The greatest support, however, comes from the user community which col­lect­ively develops stable versions and security updates and also pushes the project forward. Various editions of LXC now even come with ongoing support and regular security updates. Other versions are main­tained as best as possible, usually until a newer, more stable version appears.

In most cases, Linux Con­tain­ers is used as a sup­port­ing, sup­ple­ment­ary container tech­no­logy, which is not unusual in this field since, in contrast to virtual machines, con­tain­ers are still a very new tech­no­logy. However, you should keep in mind that container tech­no­logy providers are con­stantly growing, along with the ecosystem around the tech­no­logy.

LXC is currently an entirely viable al­tern­at­ive to existing tra­di­tion­al ap­plic­a­tions, which is spe­cific­ally geared towards VM ad­min­is­trat­ors. The trans­ition from a virtual machine to a container tech­no­logy is easier with Linux Con­tain­ers than with other container tech­no­lo­gies.

The most popular LXC al­tern­at­ive is Docker. This platform, based on Linux Con­tain­ers, has been con­tinu­ously developed over the past few years and can now also be run on Windows systems. As such, the largest cloud providers, such as Google, IBM, AWS and Azure, are now able to offer native Docker support.

A well-known container al­tern­at­ive (Linux) for the vir­tu­al­isa­tion of a complete server is OpenVZ. Like LXC, OpenVZ uses the kernel of the host operating system and makes the virtual server available to users in an isolated en­vir­on­ment.

KVM is an open-source vir­tu­al­isa­tion tech­no­logy that is already built into Linux. KVM stands for “Kernel-based Virtual Machine.” It can be used to convert Linux into a hy­per­visor, allowing the host computer to run multiple isolated en­vir­on­ments.

Kuber­netes ori­gin­ally came from Google which was one of the first sup­port­ers of the Linux Con­tain­ers tech­no­logy. This open-source platform automates the activ­it­ies of Linux Con­tain­ers. Entire groups of hosts running the con­tain­ers are assembled into clusters, making it very easy to manage them all.