LXD, pronounced “lex-dee,” is a unified platform for managing system containers and virtual machines (VMs). The platform can be deployed as a single instance on an individual computer or as multiple instances across a large cluster. A cluster can support thousands of instances and can run containers, VMs or both. The LXD platform, which builds on and extends Linux Containers (LXC), has direct access to the underlying hardware for maximum efficiency and performance.

LXD is an open source project free to download and deploy. Canonical created the project in 2014 and remains its main contributor. Originally, the Linux Containers community managed LXD. But in July 2023, Canonical took over control of the project at version 5.15. LXD is now at version 5.21.

Users can install LXD from one of many available packages or from source code. They can also download the latest files from GitHub and build it themselves.

Should I use LXC or LXD?

Both LXC and LXD provide the tools necessary for implementing and managing Linux containers. Although the platforms share some of the same functionality, they take different approaches to container delivery. LXD offers more robust management features compared to LXC and includes VM support.

LXC is a Linux container technology that provides a user interface for Linux kernel containment features, such as namespaces; control groups, or cgroups; change roots, or chroots; secure computing, or seccomp, policies; and other kernel capabilities. The LXC platform includes several components, including the Liblxc library, language bindings such as Go and Ruby, distribution container templates and a set of standard tools.

A LXC container falls somewhere between a VM and an application container, like the type supported by Docker. An LXC container, referred to as a system container, simulates a virtual version of the full operating system. The container uses kernel functionality from the host system, providing the libraries, databases and other components typical of a full operating system (OS). Because of this architecture, an LXC container can run multiple processes at the same time, whereas an application container is limited to a single process or application. In addition, a system container can implement multiple user spaces with processes isolated within each space. An application container cannot.

Like LXC, the LXD platform supports system containers. It offers more comprehensive tools and methods for implementing and managing containers, with features and capabilities not available to LXC such as greater usability. That said, the LXD platform still uses LXC to create and manage the containers themselves, so LXD remains intrinsically tied to the LXC technology.

LXD includes another important feature: native support for virtual machines, which was added in version 4.0. A LXD VM emulates the physical host machine, while providing an environment with a completely isolated OS. In contrast, system containers share the host kernel instead of creating their own environments. This makes the containers faster and more lightweight than VMs, but they don’t provide the same level of isolation.

LXD enables users to implement containers, VMs or both, while LXC is limited to containers alone. LXC offers fewer features and capabilities than LXD and is not as easy to manage. Both platforms are free and open source.

According to Canonical, “LXC should be seen as an alternative for experienced users that want to run Linux containers on distributions that don’t support LXD.”

Containers and virtual machines diagram.
LXD unifies the management of containers and virtual machines.

Deploying the LXD platform

LXD is an image-based product with images available for many Linux distributions, including Fedora, Debian, OpenSUSE, Ubuntu, Alpine Linux, Arch Linux, Gentoo and others. The central component of an LXD implementation is the LXD daemon, which can run only on Linux systems. However, the LXD client that communicates with that daemon is available for multiple platforms, including Windows and macOS.

To install the LXD daemon, administrators can use one of the available packages or install it from source code. Installing from a package is the simplest approach, especially if using the Snap package manager, since LXD Snap packages have been tested and published for many Linux distributions.

A user can also install LXD manually from source code. This approach typically requires the latest version of Liblxc and a modern version of Golang. With both in place, the user downloads the LXC client and server to the desired directories and then adds them to the kernel to create the LXD daemon binary and the LXC command-line client.

LXD is available either as a long-term support (LTS) release or as a feature release. LTS releases are the production-ready versions, which include ongoing bug fixes and security updates over a set period. However, they typically do not receive new major features. Feature releases represent the more experimental LXD branches, appearing monthly with new features and functionality that users can try.

Managing the LXD platform

LXD provides a secure and user-friendly platform for managing and running both containers and virtual machines. The platform is built around a comprehensive representational state transfer application programming interface (API) that facilitates communication between the LXD daemon and its clients. The API runs over HTTP and can be used for both local and remote access. For local operations, the API uses a Unix socket, and for remote operations, it is encapsulated within the Transport Layer Security protocol.

Administrators can use the API to script and automate management tasks as well as integrate third-party tools into the LXD platform. For example, a DevOps team might incorporate LXD containers into their continuous integration/continuous deployment pipeline using infrastructure as code to deploy the containers. Several external tools already integrate with LXD, such as Ansible, Terraform, Bolt and Packer as well as Canonical’s own Juju and MAAS, or metal as a service.

Continuous integration/continuous deployment pipeline diagram.
DevOps teams can incorporate LXD containers into their continuous integration/continuous deployment pipeline.

In addition to the API, the LXD platform includes a command-line interface (CLI) for controlling the LXD environment. The two most important commands available to the CLI are the following:

  • lxd. The lxd command controls the LXD daemon. Administrators do not need to use this command often because the daemon typically starts automatically. However, admins can still use it for initializing, administering and debugging the daemon. These operations should be performed only by advanced users.
  • lxc. The lxc command serves as a command-line client that can interact with the LXD daemon. Administrators can use this command to access and manage LXD instances and images. For example, the command enables an admin to manage profiles, restart instances, monitor servers, create snapshots and move instances between servers.

Beginning with LXD version 5.21.0, the LXD platform also includes a web-based tool that enables administrators to perform many of the tasks associated with managing LXD instances. Canonical plans to add more features to the web tool in future releases.

Important features of LXD

The LXD platform builds on LXC and enhances its capabilities in several ways. The following are some of the more important features that LXD offers:

  • A highly scalable platform that supports thousands of instances.
  • A secure environment that deploys unprivileged containers by default, uses modern virtual hardware, or VirtIO, for VMs and restricts access to resources.
  • High-availability clustering with storage and network redundancy.
  • Device passthrough capabilities for USBs, network interface cards, disks, graphics processors and other hardware.
  • Flexible control over compute resources, with advanced network support and storage management.
  • Advanced stateful snapshotting capabilities.
  • Live migration of running containers between hosts.
  • OpenStack integration, with OpenStack images scheduled as Linux containers.
  • The ability to run Docker containers inside LXD containers.
  • The ability to interact with application containerization platforms.

What is the difference between Docker and LXD?

Although Docker and LXD are both container platforms, they typically serve different purposes. The primary reason for this difference is the type of container that each one creates.

LXD (Linux container hypervisor) diagram.
LXC and LXD containerize systems and can interact with application containerization platforms such as Docker.

The Docker platform implements application containers, which are ephemeral, stateless containers that use minimal resources. Docker can download, cryptographically verify and run application container instances. Although Docker relied on LXC in its early development, it has since changed its code base to create an entirely different platform for containers.

LXD system containers are like lightweight VMs, with each container running a virtual version of the full Linux OS. Like Docker containers, LXD containers on the same host share the same OS kernel. However, a Docker container runs only one application or process at a time, whereas a LXD container can support almost any type of workload, like a virtual or physical machine.

System and application container platforms are not mutually exclusive and can coexist to support different workload types. System containers tend to be better suited to workloads that require long-lasting environments, while application containers are usually a better fit for processes or services that run temporarily. A Docker container can even nest in a LXD container.

Containers are a valuable option for deploying applications, but they have limitations and operate differently than VMs. Explore the key differences between containers vs. VMs. Also, learn more about the history, evolution and future of containers, and follow these tips to prepare for successful container adoption.



Source link

Shares:
Leave a Reply

Your email address will not be published. Required fields are marked *