Containerization |Part 2: From LXD to Kubernetes

containers

In my last post (which was the part 1) where I introduced containerization and the types of containers I know, I said I will be writing on Docker next but I then decided to visit the dark side and learn more about Linux Containers (LXC: pronounced Lex-cee). In this article, I will be introducing you to LXC/LXD and how to install it on your local computer.

Let’s dive in

LXC is self-contained execution environments with their own isolated CPU memory block IO, and network resources now they share the kernel of the host operating system. So, it really makes it extremely efficient.

LXD which means Linux Daemon and pronounced Lex-Dee, is a system container manager built on top of LXC to provide a new, better user experience. Under the hood, LXD uses LXC through liblxc and its Go binding to create and manage the containers. It’s basically an alternative to LXC’s tools and distribution template system with the added features that come from being controllable over the network. All LXD does is that it exposes a REST API over a local Unix socket as well as over the network (if enabled). Clients, such as the command-line tool provided with LXD itself then do everything through that REST API.
Unlike Docker which wraps applications up within a self-contained file system, LXD uses a base user image. LXD is like a rolled back version of Docker in that we deal more with machine containers and less concern with individuals applications that are running inside them. You can read more about LXD here.

Let’s Get LXD installed and set up

First lets update and upgrade our apt repository and download package information from all configured sources using this:

updating apt repo

apt repository update&upgrade

Once that is completed, you should have an output like the one above. Now it’s time to install LXD. As at the time of this installation I used version 3.0.3. Install LXD using:

installing lxd

If you get an error, you should try installing using sudo, just type in sudo !! and this will run the previous command as a superuser. The first installation (lxd) contains all that’s needed in order for this particular machine to accept API call, and the Linux client or lxd-client client makes those API calls. If all goes well you should have an output that the application is installed, for some users, you might have lxd and lxd-client pre-installed so your output would look like the one below:

lxd installation

The next step is to initialize lxd using this command:

Again if you encounter permission error, elevate your privileges and run as root. The next steps are quite clumsy but I will try my best to break each down to the level by which I understand it. The image below shows the configurations I applied for initializing lxd

lxd init output

I would break down what each term means and you will specify the configuration you want to use or not based on your preference

• LXD Clustering: LXD can be run in clustering mode, where any number of LXD servers share the same distributed database and can be managed uniformly using the lxc client or the REST API. you can read more here. I used my default IP as the name used to identify the cluster node, yours will be different. Also, I allowed my default IP to be used to reach the cluster node. Since I don’t have an existing cluster I went with the default. It is advisable to set up password authentication for your cluster but for this article am not setting any password, the default is always yes but I changed it to no.
• Storage Pool: The storage pool created by lxd init will be the default storage pool on which containers are created. This is more or less like specifying a storage space for the container. Instances etc.are stored in the storage pools You can also read more about storage pools and the types of storage backend here. I am using btrfs (because btrfs allows you to have your home separate from your install without having a separate partition). Of cos, you have three variants to choose from. I don’t have any existing block device so I went with the default option which is no. I gave the pool size 12gb because the image I have running is 40GB large in size. You can as well configure a remote storage pool if you have one running.
• MAAS Server: Using LXD to install MAAS into containers is a good choice for users who want to test MAAS, or who may want to continue leveraging an existing container architecture or policy. You can read more about MAAS and installation here.
• Network Bridge: LXD supports three network types: bridge, macvlan, and sriov. The bridge creates an L2 bridge for connecting instances to (can provide local DHCP and DNS). This is the default. Macvlan provides preset configuration to use when connecting instances to a parent macvlan interface. And Sriov provides preset configuration to use when connecting instances to a parent SR-IOV interface.
• Fan Overlay Network: this enables users to grow the number of LXD containers they can address in a single environment. The Fan overlay network for containers expands address space 250x on each container host.
• Cached Image: LXD uses an image-based workflow. It comes with a built-in image store where the user or external tools can import images. Containers are then started from those images. It’s possible to spawn remote instances using local images or local instances using remote images. In such cases, the image may be cached on the target LXD. Literally what means LXD locally caches images and uses this cached version of the image locally so you wouldn't have to download the image again.
• The last option there just prints your configurations/settings in a YAML format to the terminal.

The next step is to launch an instance using the lxc launch command, the format is:

lxc launch imageserver:imagename instancename

imageserver: name of a built-in or added image server (example ubuntu, alpine).

imagename: the name of an image (example 16.04, /3).

instancename: the name you wish to call the instance, this name will be used to address the instance.

I will be launching an Ubuntu image, it’s quite heavy so you should expect some delay during the creation of the instance.

And you should have the output below

launch instance

You can list all the instance running using

lxc list

Now let’s log-in to the new instance created since we launched an Ubuntu image we will be using bash as the command interpreter. The format for executing the instance is

lxc exec instancename -- /bin/bash

Run this command to login into the instance

And you should have an output like this

list and login

And with this, you should be logged in as root and have root privileges in your instance.

Yeah, you made it to the end of the installation!!!!! In the coming week, I will be diving more into LXD and how you can leverage it as an Engineer.

Don’t forget LXD is API driven and accepts API call. And if you are a fan of OpenStack there’s also Nova LXC which can be used alongside Openstack and LXD.

PS: This installation was done on a server running an Ubuntu Image. Also to delete the instance you will need to first stop it (it’s a safety measure so you don’t mistakenly delete your container) and then delete it. To stop the instance and delete use this command

Subscribe to FAUN topics and get your weekly curated email of the must-read tech stories, news, and tutorials 🗞️

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇