(originally posted at https://radar231.com/Use Cases for LXD.html)
References
Introduction
In response to the request for LXD usage examples posted to the Linux Containers forum, I’ve decided to describe a couple of my personal uses of LXD.
First, a bit of background information. I’ve recently retired from a 41 year career in the Canadian Public Service, where I worked in a variety of Electronics Engineering and Information Technology positions. My last position was working as a systems analyst, designing and implementing systems integration solutions. My last project was to develop a system to act as a communications bridge between two very different legacy systems.
Since retirement I’ve filled my time by setting up what I consider a fairly modest but quite effective home lab environment. A post describing my home lab can be found in the references section of this post.
Both of these examples leverage LXD extensively.
Communications Bridge
While the production deployment of the final system didn’t utilize LXD, the design and development of the solution was performed exclusively on LXD containers. I had been using LXD containers for many years, both as development systems as well as for testing code and configurations on a variety of Linux distributions. In this particular case, the final system was going to end up a multi-channel meshed system consisting of many physical servers. Each channel consisted of a number of servers and firewalls, each performing a function of protocol translation, data routing or security isolation. The channels were configured in a mesh interconnection, providing redundancy and fault tolerance, with the capability to detect node failures and modify the routing to bypass the failures.
As can be seen from my description, this was going to be a fairly complex system, and was going to be a challenge to develop as well as to perform initial and ongoing systems testing. LXD containers provided a perfect development platform for this. I had a custom deployment script that would spin up more than 15 containers from a custom local image, set up the isolated networks that provided the interconnection at various levels within the system, deployed the applicable code to each node and then finally reboot all the containers to bring the development system up into operations.
Once done with a development session, another script would shut down all the containers, tear down the virtual networks and remove all of the containers. Deployment of the development environment would only take a few minutes to accomplish, and the clean up and removal of the environment was complete within another minute or so.
While a similar environment could have been created using something like terraform to manage virtual machines, it would have been many orders of magnitude slower to deploy than a set of LXD containers, and would have ended up using a much larger amount of system resources. In fact, the whole LXD development environment was actually deployed within a VM running LXD (albeit, a rather beefy VM :-)).
Home Labs and LXD
After having used LXD for so many years at work, it only made sense to go all in with LXD for my home lab. While I have a number of virtualization servers in my home lab, all production workloads are containerized, and run either on my kubernetes cluster, or on docker encapsulated within an LXD container. I do have KVM/QEMU via libvirt running, but this is mainly only used for desktop VM’s that require sound. This is due to the lack of virtio sound card emulation making sound an issue for LXD VM’s. I do try to use LXD VM’s for any server or test environment that doesn’t require sound though.
As can be seen from the following screen capture, I have a number of LXD containers running. Some are acting as X86 nodes for my kubernetes cluster. There are currently two that are running as docker aggregation servers, where I run containerized applications that won’t run correctly on the k8s cluster. I have a development system where I do my coding as well as ansible based management of the home lab servers. I also have one running Nginx Proxy Manager which manages internal access to applications running in either the kubernetes cluster or in docker containers within the home lab.
Conclusion
These two examples are fairly small in scope, and barely scratch the surface of what LXD is capable of. They do illustrate both development/testing as well as production usage of LXD though. Moving forward I see no reason to stop using LXD for both containers and VM’s. I have a few LXD related postings on my blog now, and there will probably be more posts added as I move forward with LXD.
)