LXC Linux Containers

One of my more popular articles on my old website was my investigation into lxc, commands for manipulating Linux containers.  I wrote a few management scripts to make lxc admin a little easier, and deployment a little faster.  I got some nice feedback.

This week, I investigated the current state of LXC, and wow, has it advanced.  The last version I played with was v0.7.5, and now it’s up to 1.0.7 (stable version, devs keep working on the next big version).  All the ideas I had are taken care of, and more.  LVM backing store lets you isolate the containers filesystems, so they’re never mounted on the host.  Templates are a cool idea, a way to install any ditro of Linux from scratch (provided you have the neccessary build tools, such as yum and apt-get).

The container.conf file is still a mess, and there are still precious few working examples on the Internet (but more than there used to be).  Networking is still a mystery to too many people, and all Linux comes with a simple bridges.  You can do VLANs on the linux bridge, I’ve done it before, but it’s not for the newbie.

LXC came out of the box setup with all the containers on their own bridge, lxcbr0, isolated from the outside world, and a NAT/PAT firewall running on the host itself, to give them outbound only access (by default).  Nice idea, especially for a working default config, right out of the box.

I rather like the LVM backing store, but noticing the zfs and btrfs support makes we really want to start using and learning more about them now.  Endless new technology to explore!

2 thoughts on “LXC Linux Containers”

  1. Wow. One day later, and mind blown all over again. Unprivileged containers. LXC 1.0.7 supports user-space containers, with uid/gid space mapped to different ranges for each container, reducing risk of privilege escalation. Root in each container is actually a regular user in the base context of the host OS. You create a local user, then install the container config files under its home directory. The user launches the container, instead of root, and all uids and gids in the container are remapped in the host OS to a different, much higher range, which has no identify or authority in the host OS. Neat!

    I’ve also downloaded and started messing with OpenVSwitch, some software to run and manage ethernet virtual switching software to let your containers communicate with each other and the world. It’s much easier to design secure networking now, to keep access to the host OS away from the Internet and containers.

  2. I had to get lxc working again for a project at work. We are only allowed a particular version of a particular popular commercial linux product. Someone asked if there was any way we could run and support a particular product which only supports Ubuntu, Red Hat or CentOS. I found LXC was supported on our OS, but work http proxy limitations prevented building the container on the work machine.

    So I waited until I got home, where I was able to build a working Ubuntu 14.04 LTS host and Ubuntu and CentOS
    containers with all the prerequisites already installed. Then it was a simple matter of tarring it all up and bringing it into work. Now we can run software that thinks it’s running under an Ubuntu system, in a nice, safe, isolated container with it’s own IP address. Cool.

Comments are closed.