CoreOS Practice Guide (III): System service Housekeeper SYSTEMD

"Editor's note" as an operating system, CoreOS uses a highly streamlined system kernel and peripheral customization to implement many of the functions that require complex human operations or Third-party software support at the operating system level, while excluding other software that is not core to the server system, such as GUI and package manager. Linfan, a software engineer from ThoughtWorks, will bring the "Walk Cloud: CoreOS Practice Guide" series to take you through the CoreOS essence and recommended practice. This article is based on the third: system Services Butler SYSTEMD.

Author Introduction:

Linfan, born in the tail of the IT siege Lions, thoughtworks Chengdu Office Cloudops team members, usually like in the spare time to study DevOps related applications, currently in preparation for AWS certification and promotion of Docker related technologies.

In the first chapter of the series, we have mentioned Systemd, whose main design goal is to overcome the inherent disadvantages of traditional Linux mainstream launcher Sysvinit and improve the system start-up speed. Compared to similar sysvinit competitors, such as Ubuntu's upstart,systemd design is more avantgarde, in simple terms, its design ideas borrowed from the Mac system startup program launchd. In fact, SYSTEMD is far more than just the boot system, it takes over functions such as startup, completion, status query, and log archiving of system services, and supports timed tasks and tasks triggered by specific events such as inserting a specific USB device and specific port data. In the CoreOS world, the recommended approach is to use SYSTEMD to manage all user services, including those running in application containers such as Docker.

It is worth noting that SYSTEMD is not a CoreOS-specific service. SYSTEMD is essentially a stand-alone project that is not attached to any Linux distribution, because Systemd's author Lennart Poettering is in Red Hat, and the whole project is actually led by the Redhat company. Although Redhat Linux did not use SYSTEMD until mid-2014, Redhat's Fedora introduced SYSTEMD as its startup management program as early as 2011.

Before you start using SYSTEMD, find out what's special about SYSTEMD.

The design concept of

systemd

start less process as much as possible

When the Sysvinit program initializes the system, all possible background service processes are run. However, users need to wait for the system to start all services before they can log on. This approach can lead to two problems: the system's startup time is too long and system resources are wasted.

SYSTEMD provides the ability to start a service on demand, making a specific service start only when it is actually requested. In particular, specific hardware-related services, such as Bluetooth service only when the Bluetooth adapter is inserted only need to run, print service only when the printer connection or program to print only need to run, even the SSHD service only need to use SSH to connect to the server when the user needs to start. This capability is based on the systemd of the Dbus bus or a particular socket port, and this design is more disruptive than the traditional startup program.

to start more processes in parallel as much as possible

In the era of Sysvinit, the numbering of each service item is executed sequentially by executing the startup script. Later Ubuntu upstart solves the parallel startup between the startup items that are not directly dependent. and systemd through the socket cache, Dbus cache and the establishment of temporary mount points and other methods to further resolve the dependency between the START process, so that all the system services concurrent startup, this design is also systemd unique creative. Of course, for user-defined services, SYSTEMD allows them to configure their startup dependencies, ensuring that the services are run in the necessary order, and later detailing the specific usage.

Comparison of SYSTEMD startup model with other startup models

uses Cgroup to track and manage the lifecycle of processes

Cgroup's full name is controller group, the Linux kernel feature that groups any process into a group, originally proposed by Google's engineers, and officially enabled from the Linux kernel version 2.6.24. For Android, its application isolation is the technology used. For a long time, in the broader server sector, there has been no mainstream service management program that can take full advantage of the features that have already brought wide benefits to the phone.

And Systemd is the expert of Cgroup, its appearance just make up for this area of omission. The CGROUP,SYSTEMD not only enables access isolation between services, but also limits the access quotas of specific applications to system resources (such as CPU usage, amount of memory), and the precise Management Service lifecycle. In the later part of this article, we will describe the specific practices involved in the operation.

Unified Management Service log using SYSTEMD must know also its partners: the Journald Log service, designed to overcome the shortcomings of the existing Syslog service's log content is easy to forge and the log format is not uniform. And it is now a standard child service for SYSTEMD. Journald saves all log information in binary format, and users need to use the JOURNALCTL command to view log information.  Later in this article, I'll show you how to view the service log.


First Hello World Service unit and target

Introduce two concepts first, unit and target.

The unit is the systemd of the Management Service, and each service is considered to be a units, and is defined using a single. The unit file needs to contain descriptions of the corresponding services, attributes, and commands to run. The commands that the service runs in CoreOS are usually a series of container operations, and the specific service processes are encapsulated in the container.

Target is the way in SYSTEMD that specifies the service startup group (equivalent to the "Run level" in Sysvinit, and if it is not clear that this concept is not relevant, search "Linux run Level" to find a number of related articles). Every time the system starts, all services associated with target at the same level as the current system are run, and if the service does not need to follow the system to start automatically, the target content can be completely ignored. Most of our Linux users usually use the "multiuser mode" level, and the target value is "Multi-user.target".

Hello World Service Unit file

Do not pretend, now we use SYSTEMD to create a simple system service.

In the previous section of this series, we created a cluster of 3 CoreOS virtual machine nodes, in which we only need to use any one of them, such as the COREO-01 node. First use the SSH connection to enter this node (this method applies to Linux/mac users, for Windows users need to use Putty Client, specific reference).

vagrant ssh core-01

After a successful login, the prompt becomes "core@core-01 ~ $", congratulating you on another important step towards CoreOS, and then you can start playing in CoreOS.

SYSTEMD Convention, the service's unit file is placed in the/etc/systemd/system or/usr/lib/systemd/system directory, but because the latter directory in CoreOS is a read-only partition (whole/ The USR directory mounts all the read-only system partitions, so we usually put the user-defined unit service files in the/etc/systemd/system directory. Enter this directory, create a new file called "Hello.service", content.

[Unit]


Description=hello World


After=docker.service


Requires=docker.service


[Service]


timeoutstartsec=0


Execstartpre=-/usr/bin/docker Kill Busybox1


Execstartpre=-/usr/bin/docker RM busybox1


Execstartpre=/usr/bin/docker Pull BusyBox


Execstart=/usr/bin/docker run--name busybox1 busybox/bin/sh-c "while true; do Echo Hello world; Sleep 1; Done "


execstop= "/usr/bin/docker kill Busybox1"


[Install]


Wantedby=multi-user.target

In this unit file, we first provide a short line of description for the service and then indicate that it needs to rely on Docker services and that it will run after the Docker service runs. The entire unit file is used in the INI file style of the packet configuration format, the beginning of this configuration is placed in the group. In the next service group, use the Execstart and Execstop properties to specify the command to be executed at the time the service runs and ends. Finally, in the configuration of the install group, we specified the target for the service to be multi-user.target.

here are two places to note, first Execstart attribute can only contain one main command, and before and after this property can use Execstartpre and execstartpost respectively to specify more auxiliary commands, execstop the same. Some auxiliary commands add a minus sign that ignores the errors of these commands (because some "auxiliary" commands are not necessarily successful, such as trying to empty a file, but the file may not exist). Second timeoutstartsec=0 The purpose of this line is to turn SYSTEMD's service startup timeout check off, which is necessary for the Docker application because Docker may need to download or update the mirrored file at run time, making the service startup times very long,  This prevents the SYSTEMD from killing the process by thinking that the service failed to start.


Start Service

With the unit file, you can now start the Hello World Service and enter the following command on the console:

sudo systemctl start hello.service

TIP: the. Service suffix at the end of this name can be omitted because the systemctl default suffix is. Service. The meaning of the unit file suffix will be explained in detail in the next step of the article.

Systemd automatically finds the Hello.service file in the/usr/lib/systemd/system directory and launches the service defined therein. If the unit file you created earlier is placed in a different directory, you need to use the full path to the file. It takes a while to wait for the first run because Docker needs to download the required mirrors from the network. After startup is complete, you can see if the service is already running through the Systemctl list-units command (This command takes an optional parameter as a filter for the service name and outputs all services without any arguments).

core@core-01 ~ $ sudo systemctl list-units hello*


Unit LOAD ACTIVE SUB DESCRIPTION


Hello.service loaded active running Hello World

We can also specify the service to start automatically when the system starts by using the Systemctl enable command.

sudo systemctl enable Hello.service

The target group that was previously defined is used, and the enable operation simply creates a connection file below the directory of the specified target group. This can be confirmed by the following command.

core@core-01 ~ $ ls/etc/systemd/system/multi-user.target.wants/hello.service


/etc/systemd/system/multi-user.target.wants/hello.service->/etc/systemd/system/  When the Hello.service system starts, it automatically runs all the linked services in the directory corresponding to its target level.


Log Management

At this point, our first service has been playing in the background, but the good "echo Hello World"? We haven't seen any output from the service from beginning to end.

In fact, we started the service has been in the background silently output "Hello world".

SYSTEMD is redirected to the log file through its standard log service Journald printing all the background processes it manages to the std:out (that is, the console). The log file is in binary format, so you must use a specific tool to view it. Journald provides a companion program journalctl for processing log content. The use of Journalctl is very simple, the default without any parameters will output the system and all the background process of the mixed log, commonly used parameters have--DMESG for viewing the kernel output log,--system to view the system output log,-- Unit plus the name of the unit to specify a log to output a specific unit, such as the following command.

Journalctl as hello.service other useful parameters, such as using--follow real-time trace log output, using--since and--until to specify the log time interval to display, etc. The Journalctl--help command obtains a complete parameter description.