LXC (Linux Containers) - is everything really good?

On the Internet, you can find more than one article, where they praise LXC and argue that this technology has a future. This is the third time I sit down to study the current status and each time it turns out a lot of nuances. The first attempt was about a year and a half or two years ago, the second - after the release of Debian 7, the third - this weekend. The reason is that I like Debian / Ubuntu an order of magnitude more than CentOS / RHEL. But unfortunately, in terms of container virtualization (in particular OpenVZ) in Debain / Ubuntu, it has become quite sad in recent releases. Including due to the more active promotion of LXC. Actually, LXC is so LXC - if only it solves the necessary tasks. I am not a hoster and I use such virtualization mainly for the purposes of development, testing and for the work of some of my own projects.

Looking ahead, I can say that the third attempt was again unsuccessful. The LXC still looks extremely raw, even for domestic use, not to mention commercial exploitation. The reasons below.

Guinea pigs

In the near future release promised LXC 1.0. In addition, another Ubuntu LTS is released in April - 14.04 (with long-term support). Armed with Debian 7, Ubuntu 12.04 and Ubuntu 13.10, I went to see progress and the current state. Places will be comparisons with OpenVZ. This is due to the fact that, for the sake of experiment, I wanted to try to replace one of the servers with OpenVZ containers with LXC containers.
')

Debian 7

The LXC version is 0.8.0-rc1.

The most striking moment remembered from the last time is that the Debian 7 container template did not work out of the box in LXC on Debian 7. In commercial development, this kind of problem is usually considered show stoppers. In spite of the 3rd update, and now there. If you look at / usr / share / lxc / templates / and try other templates, it turns out that fedora is not enough for yum, opensuse is not enough for zypper, ubuntu-cloud wants ubuntu-cloudimg-query, and if you try altlinux, then happily report that we have no ALTLinux host. Actually, for the same Debian 7 template, it is proposed to search for a repaired one and download it, or try to fix it yourself. For OpenVZ, the site has a repository with official and unofficial templates - and this is very convenient. For Vagrant there is www.vagrantbox.es but it scares links to Dropbox and Google Drive. You can hope for honesty, and you can easily get a protonated axis. For LXC at the moment, either the fact that the distribution, or scour the expanses of the Internet (that is, even less than for Vagrant).

Ubuntu 12.04

LXC Version - 0.7.5

The version is older for obvious reasons. But the container with Ubuntu is created without problems.

We try backup / restore'om. A backup is created by copying the contents of rootfs to /var/lib/lxc/ct-name/rootfs.backup1 It seems that it’s customary to create an archive, and not just stupidly copy it to a nearby directory. If I decide to copy backups to another host, I will be forced to create archives myself. On the Ubuntu site regarding LXC and backup / restore, you can read the recommendation not to use this functionality. Suddenly.

Another point that interested - the migration of containers, at least offline. Indeed, one of the convenient advantages of virtual machines is their easy migration between physical servers. Unfortunately, in the LXC there is no help in this regard - do it yourself.

Ubuntu 13.10

LXC version - 1.0.0.alpha1

The first thing that catches your eye is the output of lxc-checkconfig says that we have problems. In particular, a certain “User namespace: missing”. For a person who is far from the guts of technology - this, firstly, looks suspicious, and secondly, practically does not say “what will not work because of this.” Moreover, at 12.04 everything was fine on all counts.

We look further - a container with Ubuntu is created (we are already happy about such things :)) Instead of lxc-list, we are told we should now use lxc-ls. It is clear that the API to 1.0 did not promise to keep stable, but still looks from the side a dubious innovation.

What about backup / restore? Utilities lxc-backup / lxc-restore for some reason are missing. Whether this is the specifics of my installation (but what?), Or whether they really decided to throw it away - the question remained open. We look again at the list of commands with the prefix lxc- and the lxc-checkpoint falls into view. We try to use and we receive "checkpoint function not implemented". Sadly

Returning to the main topic - the use of the container. Launching it is done with the lxc-start command. After executing this command, we find ourselves in the container console - a rather strange choice of default behavior. To prevent this from happening, you need to remember to pass the -d key. The second point is adequate leaving the console. Documentation says about the method of Ctrl + aq, but it does not work (and apparently not only me).

The next moment - after logging in, we see that the amount of memory and disk space coincides with the values ​​in the host system. We look at it with the help of traditional df and free. Intuitively, it would be desirable for the lxc-create command (similar to vzctl) to see the parameters that will help set the amount of memory and disk space for the container, but such parameters are not visible. Since this moment is very important for me, I try to figure it out. Since the last study at LXC in this regard, almost nothing has changed. In the kernel, it is not possible to set quotas on a subtree, and from the advice you are usually suggested to try using LVM volumes as FS for a container. The method is clearly not convenient and simple. The memory limit in some form can be set by writing some lxc.cgroup.memory.limit_in_bytes directive in the container configuration. The method again can not be called user friendly, but the trouble is not even that. Firstly, not all memory will be limited, and secondly, in the container on free -m, we are still shown the limits of the host system. Yes, the new limit actually appeared and, if a certain process exceeds it, the OOM killer will beat it. But at first glance it seems that mongo in such a container should not be launched. And in any case, this approach does not look usable. Imagine you got a virtual machine at your disposal and nobody told you the type of virtualization. You will look at the amount of available memory by traditional means and then wonder why some processes die, although there should be enough memory.

findings

Although this is a very superficial study, it is quite enough to make a decision for yourself once again - LXC still needs to grow. Do not leave the feeling that you are trying to slip a little more advanced chroot, instead of this container virtualization. Despite the fact that LXC support is in the kernel and it is enough to deliver utilities to start using, this is still not enough. Of course, you can use it for some tasks now, which, for example, the same Docker is trying to do. But obviously, it’s not worth counting on mass use until the points that I mentioned here as minuses are completed. Here is the case when “95% ready” is still not ready.

PS For interest on this topic, you can still look through the presentation - www.slideshare.net/kolyshkin/seven-problems-of-linux-containers