LXD 2.0 series (1): getting started with LXD

LXD 2.0 series (1): getting started with LXD
GuideLXD is an LXC container manager that provides RESTAPI, mainly a third-party manager that manages linux containers. Maybe you haven't heard of it yet. Let's get started with LXD.

What is LXD?

To put it simply, LXD is an LXC container manager that provides REST APIs. LXD's main goal is to use Linux containers rather than hardware virtualization to provide users with a user experience close to virtual machines.

What is the relationship between LXD and Docker/Rkt?

This is the most frequently asked question. Now let's point out the differences directly. LXD focuses on system containers, also known as architecture containers. This means that the LXD container actually runs a complete Linux operating system on bare metal or virtual machines.
These containers generally publish Images Based on a clean one and run for a long time. Traditional configuration management tools and deployment tools can be used together with LXD on virtual machines, cloud instances, and physical machines.
Docker focuses on short-term, stateless, and minimal containers. These containers are usually not upgraded or reconfigured, but replaced as a whole. This makes Docker and similar projects more like a software release mechanism than a machine management tool.
These two models are not completely mutually exclusive. You can use LXD to provide your users with a complete Linux system, and then they can install Docker in LXD to run the software they want.

Why use LXD?

We have been developing and improving LXC for several years. LXC has successfully achieved its goal, providing a series of excellent underlying tools and libraries for creating and managing containers.

However, these underlying tools are not very user-friendly. Using them requires users to have a lot of basic knowledge to understand their work methods and objectives. At the same time, the backward compatibility with old containers and deployment policies also makes LXC unable to use some security features by default, which leads to the need for more manual operations to achieve the work that can be completed automatically.

We use LXD as a good opportunity to solve these defects. As a long-running daemon, LXD can bypass many restrictions of LXC, such as dynamic resource restrictions, container migration failure, and efficient online migration. At the same time, it also provides an opportunity to create a new default experience: the security feature is enabled by default, which is more user-friendly to users.

Main Components of LXD

LXD consists of several main components that appear in the LXD directory structure, command line client, and API structure.

Container

Containers in LXD include the following parts:

• Root file system (rootfs)
• List of configuration options, including resource restrictions, environment, and Security Options
• Devices: including disks, unix characters/Block devices, and network interfaces
• A group of inherited container configuration files
• Properties (container architecture, temporary persistence, container name)
• Runtime status (when CRIU is used for interruption/recovery)

Snapshots

Container snapshots are the same thing as containers, except that snapshots cannot be modified. They can only be renamed, destroyed, or used to restore the system, but cannot be modified in any case.

It is worth noting that, because we allow users to save the runtime status of containers, this effectively provides us with the "stateful" snapshot function. This means that we can use snapshots to roll back the container status, including the CPU and memory status at the time of the snapshot.

Images

LXD is implemented based on images. All LXD containers come from images. Container images are usually pure Linux distributions, similar to the images you use on virtual machines and cloud instances.

Therefore, you can "publish" a container: Use a container to create an image and use it on a local or remote LXD host.

Generally, images are differentiated by sha256 hash codes. Because it is inconvenient for users to enter a long hash code, the image can be distinguished by several attributes, which makes it easy for users to search for images in the image store. You can also map a user-friendly name to the hash code of an image one by one using an alias.

Three remote image servers have been configured during LXD installation (see the following remote section ):

• "Ubuntu": provides a stable version of Ubuntu Image
• "Ubuntu-daily": provides a daily Ubuntu build image
• "Images": an image server maintained by the Community. It provides a series of other Linux releases using upstream LXC templates.

The LXD daemon automatically caches the remote image for a period of time (the default value is 10 days) from the time when the image was last used. After the time limit is exceeded, these images will become invalid.

In addition, LXD automatically updates the remote image (unless it is specified that it is not updated), so the local image is always the latest version.

Configuration

A configuration file defines container configurations and container devices in one place and then applies them to a series of containers.

A container can be applied to multiple configuration files. When building the final container configuration (usually the extended configuration), these configuration files will be applied to the container in their defined order. When there is a duplicate configuration key or device, the new one will overwrite the old one. Then, the local container settings will be applied on these basis to overwrite all options from the configuration file.

LXD comes with two pre-configured configuration files:

The "default" configuration is automatically applied to all containers unless you provide a series of alternative configuration files. Currently, this configuration file is only used to define the eth0 network device for the container.
The "docker" configuration is a configuration file that allows you to run Docker containers in the container. It requires LXD to load some required kernel modules to support container nesting and create some devices.

Remote

As I mentioned earlier, LXD is a network-based daemon. The command line client can communicate with Multiple Remote LXD servers and image servers.

By default, our command line client will communicate with the following predefined remote servers:

• Local: the default remote server that uses UNIX socket to communicate with the local LXD daemon.
• Ubuntu: Ubuntu backup storage, which provides stable Ubuntu Images
• Ubuntu-daily: Ubuntu backup storage, which provides the daily build version of Ubuntu.
• Images: images.linuxcontainers.org backup storage

All the combinations of these remote servers can be used in the command line client.

You can also add any number of remote LXD hosts and configure them to listen to the network. You can add an anonymous open backup storage or an authenticated backup storage that can manage remote containers.

It is precisely this remote mechanism that makes it possible to interact with the remote backup storage and to copy and move containers between hosts.

Security

A core requirement for designing LXD is to make containers as secure as possible without modifying the modern Linux release.
LXD uses the LXC library to implement the following security features:

Kernel namespace. Especially the username space, which completely isolates the container from the rest of the system. By default, LXD uses the username space (opposite to LXC) and allows users to close containers as needed (Mark containers as "privileged "). Seccomp system call. Used to isolate potentially dangerous system calls. AppArmor. Additional restrictions on access to mount, socket, ptrace, and files. In particular, cross-container communication is restricted. Capabilities. Prevents containers from loading the kernel module, modifying the host system time, and so on. CGroups. Restrict resource usage to prevent DoS attacks on hosts.

To be user-friendly, LXD builds a new configuration language to abstract and encapsulate most of these features, rather than exposing these features directly like LXC. For example, a user can tell LXD to put host devices into the container without manually checking their master/secondary device number to manually update the CGroup policy.
Communication with LXD is based on the link protected by TLS 1.2. Only a limited number of allowed key algorithms are allowed. When communicating with hosts outside of the system certificate authentication, LXD will prompt the user to verify the remote fingerprint of the host (in SSH mode), and then cache the fingerprint for future use.

REST Interface

LXD is implemented through the REST interface. There is no other communication channel between the client and the daemon. The REST interface can be accessed through a local unix socket, which only requires user group authentication or communication through HTTP socket Client Authentication. The structure of the REST interface can match different components mentioned above. It is a simple and intuitive method of use. When a complex communication mechanism is required, LXD performs websocket negotiation to complete the remaining communication work. This is mainly used for interactive terminal sessions, container migration, and Event Notifications. LXD 2.0 comes with a stable API of version 1.0. Although we have added additional features to API 1.0, this does not compromise backward compatibility in API endpoints 1.0, because we will declare additional API extensions so that the client can find new interfaces.

Container Scale

Although LXD provides a good command line client, this client cannot manage a large number of containers on multiple hosts. In this case, we can use the nova-lxd plug-in of OpenStack, which enables OpenStack to use the LXD container like a virtual machine. This allows you to deploy a large number of LXD containers on a large number of hosts, and then use OpenStack APIs to manage networks, storage, and Server Load balancer.

Additional information

LXD main site: https://linuxcontainers.org/lxdLXD GitHub Repository: https://github.com/lxc/lxdLXD mailing list: https://lists.linuxcontainers.orgLXD IRC channel: # lxcontainers on irc.freenode.net

From: https://linux.cn/article-7618-1.html

Address: http://www.linuxprobe.com/lxd-2-0-introduce.html