5 Reasons Why We Use LXD
Linuxcontainer and the Container-Hypervisor LXD are one of my favorite technologies since Ubuntu 16.04. We use Linuxcontainer in our school for our web applications or other services. There are some things I really like about LXD. So: Why LXD?
1. LXC Client and REST API
In addition to LXD, there is also the command line program
lxc. It is very easy to use and very powerful. It’s fun to work with it.
lxc uses the REST API of LXD. Here are a few small examples:
Create and start a new Ubuntu container (x stands for Xenial):
$ lxc launch ubuntu:x my_container
root in the container:
$ lxc exec my_container bash
Show all containers:
$ lxc list
Copy a file into the container:
lxc file push /my/local/path my_container/my/path/in/container
The great thing about IMHO is that you can make the API available over the network. So I can add several remotes to my computer. For example, we have several LXD hosts in use. If I want to access these hosts without logging in each time via SSH, I simply add them as remote:
$ lxc remote add host1 IP of the host
Now I can use the same commands as above. Just enter the name of the remote host before the container name:
$ lxc launch ubuntu:x host1:container2 $ lxc list hosts1: $ lxc exec host1:container2 bash
Linuxcontainers are quickly created and you can start and stop them very quickly. This usually takes only a few seconds. This may not be a unique selling point for LXD, because the same applies to dockers and other container technologies.
3. Snapshots & Migration
Snapshots are a feature of LXD. I can easily create an image of each container, to which I can return later.
$ lxc snapshot my_container
lxc info my_container I can display my snapshots and return to the last snapshot with the following command:
$ lxc restore my_container snap0
But I can also create a new container (here test) from a snapshot to test an update or a change.
$ lxc copy my_container/snap0 test
Here too, I can do this not only locally on one host, but can also migrate a container from one host to another (live). There are two options. Either I make a copy or I move the container. I sometimes make use of it, e.g. when I test a new application locally on my computer, I can simply move it later on to the host in school.
$ lxc copy my_container host1:my_container $ lxc move my_container host1:my_container
Linuxcontainers use very little storage space because they share many components with the container host. A fresh Ubuntu image, for example, consumes only a few MB of disk space. All containers also share memory and CPU resources. In this way, a much higher density can be achieved compared to virtual machines, which require considerably more resources. Canonical speaks of the fact that on a server 10x more container VMs are possible compared to classical virtual machines (e. g. KVM).
5. Flexible network and storage configuration
With LXD, a wide variety of application scenarios are possible. Different storage backends are supported and different network drivers. You can also have several storage back-ends on one host and decide on which memory to start it on when you create a container. An overview of all possible memories can be found in the documentation.
There are also different network options available. By default, LXD creates its own subnet for the containers. However, you can also set up network bridges or use VLANs to give the container the desired IP or use the existing infrastructure.
If you work a lot with Linux VMs, you should definitely look at LXD. For me, LXD is the perfect blend of the benefits that containers bring and the familiar environment you’re used to from a Linux VM. It’s like a “real” virtual machine, but faster.
What are your experiences with containers in general and with LXD in particular?