[LINUX] systemd-nspawn beginning

systemd_nspawn chroot Before getting into the main subject, there are some points to understand. In Linux, a process has a ** root directory ** as one of its attributes. It is usually used in the process to interpret absolute paths starting with / and is usually set to the system root directory (/). The chroot () system call changes the root directory to the specified path. This makes it possible to limit the files that can be accessed.

systemd-nspawn systemd-nspawn can be interpreted as an enhanced version of chroot. The difference from chroot is that systemd-nspawn The file system hierarchy, process tree, various IPCs, host names, domains, etc. are completely virtualized and isolated. It isolates the namespace and can be treated as a lightweight container.

Also, one of the motivations for using systemd-nspawn is that Linux distributions that use systemd can be used without thinking.

Difference from Docker

You can do anything you can in the directory tree of the recreated distribution. Docker builds a container for each application, while systemd-nspawn configures one Linux system in the container. You can build an environment close to VM-type virtualization that allows you to start multiple applications in a container in the same way as a normal Linux environment.

Get started

I use Ubuntu, which I usually use, as a host, and create a container environment there using systemd-nspawn.

environment

Linux karkador 5.0.0-37-generic #40~18.04.1-Ubuntu SMP Thu Nov 14 12:06:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Preparation

Use debootstrap to prepare the necessary files on the container. debootstrap is a tool for constructing a minimal directory tree for debian, the distribution on which Ubuntu is based. This time, I will prepare the one for Ubuntu. This time, prepare a directory for the container with the name / var / lib / machines / ubuntu and install the files there.

# debootstrap --arch=$(dpkg --print-architecture) $(lsb_release -cs) /var/lib/machines/ubuntu http://archive.ubuntu.com/ubuntu

Now the files needed for the container are created

Enter the container

# systemd-nspawn -D /path/to/container

Put it in the root shell of the prepared environment. For the time being, just set the password with passwd and exit. You can use Ctrl]]] to get out of the container.

# systemd-nspawn -b -D /var/lib/machines/ubuntu

Boot the container. That is, start ʻinit` in the container. After the familiar Ubuntu boot screen, a login shell is launched. If you come this far, you can do most of the usual things. The way to exit is the same.

# systemctl start systemd-nspawn@ubuntu

The container is started with. Operations such as automatic startup are performed with ʻenable | disable` as in the other cases.

Container operation

The systemd-nspawn command has a number of options. For example, the first -D is an option to make the specified directory the root of the container's file system. In addition to systemd-nspawn, there are commands that are convenient for operating containers.

--syscall-filter You can change the rules for system calls issued inside the container. For example, when you do not allow read --syscall-filter="~read" You can do it with (Note that you can not execute it unless you allow read)

You can check the details of the specified system call with systemd-analyze syscall-filter. (Designation in group units, etc.)

machinectl systemctl start systemd-nspawn@hostname Containers started with can be operated with the machinectl command. Show the list of running containers with machinectl list, Use machinectl list-images to display a list of container images located in / var / lib / machines. You can also use machinectl enable | disable to start automatically.

machinectl is a command that combines systemctl operations around the container and systemd-nspawn, and most operations can be done with this.

Container network

The default is to share the network with the host. Also, setting systemd-networkd to a container or host enables a wide range of network settings such as virtual Ethernet links, bridges, and port forwarding.

Summary

There are many differences from Docker, and I think it's interesting as a completely different container technology. I would like to operate it a little more and add information such as networks.

Recommended Posts

systemd-nspawn beginning
Secret calculation beginning 2019
Beginning with CTF
Beginning with Selenium
Beginning with PyTorch
Python3 Beginning Part 1