Systemd-nspawn Quick Guide

Systemd-nspawn Quick Guide

Currently, I have migrated chroot to systemd-nspawn, and I have written a Quick Guide. To put it simply, I strongly recommend that users using systemd convert from chroot to systemd-nspawn, because it has almost no disadvantages if your Kernel configuration is correct.

The users in the major production editions should be familiar with chroot, And I guess Gentoo users should use it from time to time.

Chroot challenges

In most interactive environments, running only chroot is not enough. We usually need to mount/proc,/sys, and bind to ensure that there will be no errors such as "loss of ptys" (Note: bind is an option of mount) mount/dev. If you use tmpfs, you may want to mount the new tmp, var/tmp as tmpfs. Next, you may want to bind other mount points to the chroot. These are not especially difficult, but you usually need to write a script to manage it.

Now I perform the backup operation according to my daily plan. Of course there are some unnecessary data such as the tmp directory or any bind mounting content. After I configure a new chroot, it means I want to update my backup configuration, but I often forget this because the chroot mount point is not running most of the time. If a backup is performed when these mount points still exist, there will be a lot of unnecessary backup content.

When the bind mount point contains other mount points (for example, the-rbind option is used for mounting), the default Processing Method of systemd is slightly different in this case. When you detach something in the bind mount, systemd uninstalls the directory on the other side of the bind. Imagine that If I unmount a directory of/dev mounted to bind in chroot, I find that/dev/pts and/dev/shm on the host are also missing, I would be surprised. However, it seems that there are other methods to avoid, but this is not the focus of our discussion.

Advantages of Systemd-nspawn

Systemd-nspawn is used to start a container, and its simplest mode can run like chroot. By default, it automatically configures the container overhead such as/dev and/tmp. You can configure other bind mount points by using some options. When the container exits, all mount points are cleared.

When the container is running, it does not look changed externally. In fact, five different systemd-nspawn container instances can be generated from the same chroot, except for the file system (excluding/dev,/tmp, etc., only/usr, /etc changes will be passed) There is no connection between them. Your backup will ignore the bind mount point, tmpfs, and any content mounted in the container.

It also has the advantages of other excellent containers, such as containment-which can kill all activities in the container without affecting the external, and so on. Its security is not impeccable-it serves only to prevent unexpected errors.

If you are using compatible sysvinit (which includes systemd and openrc), you can start the container. This means that you can use fstab in the container to add a mount point and run the daemon process. With only one chroot overhead, you can obtain almost all the benefits of Virtualization (without the need to build a kernel, etc ). Running systemctl poweroff in a container that looks like chroot looks strange, but this command works.

NOTE: If no additional configuration is required, the container will share the network of the host, so the container on the host should not run sshd. It is not difficult to run a separated network namespace. DHCP can be used for new instances. Remember to bind interfaces after the separation.

Procedure

Making it work is the most brief part of this discussion.

First, the system kernel must support namespaces and devpts:

CONFIG_UTS_NS=yCONFIG_IPC_NS=yCONFIG_USER_NS=yCONFIG_PID_NS=yCONFIG_NET_NS=yCONFIG_DEVPTS_MULTIPLE_INSTANCES=y

Starting namespace like chroot is very simple:

systemd-nspawn -D .

You can also quit like chroot. Run mount internally and you can see that it has prepared/dev and/tmp by default. "." Is the chroot path, that is, the current path. Bash is run inside it.

It is easy to add some bind mount points:

systemd-nspawn -D . --bind /usr/portage

Now, the/usr/portage in the container is bound to the corresponding directory of the host. We do not need to sync/etc. If you want to bind to the specified path, you only need to add ": dest" after the original path, which is equivalent to the root of chroot (-- bind foo and -- bind foo: foo are the same ).

If the container has the init function and can run internally, you can start it by adding the-B option:

systemd-nspawn -D . --bind /usr/portage -b

You can see the operation of init. When the container is disabled, the system automatically exits.

If the container runs systemd, you can use the-h option to redirect its log to the systemd log of the Host:

systemd-nspawn -D . --bind /usr/portage -j -b

Use nspawn to register the container so that it can be displayed in machinectl. This allows you to conveniently operate on the host, such as starting a new getty, ssh connection, and shutdown.

If you are using systemd, open chroot and hug nspawn.

This article permanently updates the link address: