Systemd服务管理实践

背景: 我们在构建Kubernetes容器化平台时，会在节点上部署各种 agent ，虽然容器化当道的今天很多程序可以直接采用docker方式进行运行，但我们在整个集群内部仍然大量使用了 systemd 来管理基础服务。不过在使用过程中发现可能出现相关依赖的服务组件异常后导致节点上服务不可用，其次还有可能出现个别服务bug而导致整个节点资源消耗殆尽的情况(幸好发现的早，及时处理后没有产生业务上的应用)，因此，诞生了使用 systemd 在管理服务的过程中，能帮我们管理上下游依赖服务的状态，且能相对限制部分资源的想法。

通常情况下，当用户自己使用systemd进行管理服务时，需要关注systemd service 中的如下几个配置块:

Unit: 主要用于配置整个服务的详情信息以及服务依赖，用于快速识别该服务的相关情况以及依赖项目
Service: 主要用于配置整个服务生命周期的管理行为
Install: 用于配置服务的安装级别，当我们设置服务在Linux的那种级别下启动或开机自启动时会加载该部分(典型的当chkconfig nginx on或者systemctl enable|disable nginx.service时会读取该部分的配置)

Unit 块

Unit 块除了可以简单描述整个服务的相关详情外，还有最重要的一点可以用来管理该服务的启动顺序和启动依赖(必须也得由systemd管理)。

比如通常我们有一些服务，必须依赖一些基础环境(ntpd，rsyslog，network)才能启动成功，或者必须在某个服务后启动，那我们就可以在这里进行配置。

注意: 在Unit 快中，每个指令后都可以指定一个以空格分隔的列表

服务描述

在systemd 的 service 配置中，我们通常会使用如下几个配置项来描述该服务的基本信息:

Description: 服务的简单描述
Documentation: 指定服务的文档，便于管理员快速追溯，一般可以使用"http://", “https://”, “file:”, “info:”, “man:” 五种 URI 类型

服务依赖管理

systemd 中会有几种服务依赖管理的指令，可能在实际使用过程中会有一些疑惑，有时候功能可能重叠，因此需要根据具体的使用场景进行组合。

After: 用于指定该服务在那些服务之后启动，停止时正好相反
Before: 用于指定该服务在那些服务之前启动，停止时正好相反
Requires: 设置该服务必须依赖的其他服务，因此在该服务启动之前，指定的服务列表必须全部在线，否则服务将启动失败或掉线。但如果未设置After和Before指令时，该服务和依赖的服务将会并行的同时启动。注意: 该指令依赖的服务不一定要在整个生命周期都保持一直在线，这取决于其他的检查条件
Requisite: 和Requires类似，区别是在该服务启动时，该指令指定的依赖资源必须全部处于启动成功的状态，否则该服务立马失败，并且不会启动那些失败的依赖服务。因此一般建议Requisite和After 一起联合使用会比较好。
Wants: Requires的弱化版，当该服务启动时，尽可能的启动该指令指定的服务，但不会影响该服务的启动
BindsTo: 和Requires类似，但是依赖性更强，这里列出来的任何服务停止运行或崩溃，该服务将立即被停止。考虑服务的启动依赖，一般会和After一起使用
PartOf: 和Requires类似，但仅作用于服务的停止和重启，表示该服务是所列服务的一部分，会随指定服务的启动而启动。注意: 该指令是单向依赖，服务的主动的重启不会影响其他

Unit块的依赖属性

示例


# 这里指定了内部的Kubelet进程必须在docker 和kube-proxy 之后启动，且需要强依赖，减少调度失败和pod转发失败的问题
[Unit]
Description=kubelet - k8s node lifecycle manager.
Documentation=https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet/
After=docker.service kube-proxy.service
Requisite=docker.service kube-proxy.service

Service 块

毋庸置疑的是，我们通常使用systemd 最初的想法是用来启动和停止进程，因此，整个systemd最核心的部分也就在 Service 块了，因此我们需要对该部分有很熟悉的理解。

基本指令

Type: 指定进程的启动类型，必须设为 simple, exec, forking, oneshot, dbus, notify, idle 之一。常用的几种如下
- simple: 一般没有其他指令时，为默认值，表示ExecStart后的指令为主进程，主进程启动后服务即启动成功。如果进程需要为其他进程提供服务，需要通过socket来进行
- exec: 同simple类似，但是表示该服务的主服务进程执行完成之后，才真正启动成功。
- forking: 标识在使用ExecStart后的指令启动程序后，会进行fork()的系统调用。传统Unix中守护进程的经典做法，如果使用此类型，建议设置PIDFile=来指定该服务的主进程。比如nginx进程的daemon方式，主进程执行完成后，至少有1个进程在运行，此时服务状态会变成active状态
- oneshot: 同simple类似，但是表示只有在该服务的主服务进程退出之后，才真正执行成功。一般用于执行一次性任务(配置RemainAfterExit=yes设置可停止的一次性服务)
PIDFile: 指定该服务的PID文件路径。systemd会在启动后读取主服务进程的PID，并记录在MAINPID变量中，在停止服务后，会主动进行删除该文件
KillMode: 指定停止服务时，杀死进程的方式，必须设为 control-group, process, mixed, none之一。(process表示仅杀死主进程;mixed表示向主进程发SIGTERM信号，然后想服务内cgroup的其他进程发SIGKILL信号;none表示仅执行ExecStop动作，而不杀死进程)

注意: 建议对长时间持续运行的服务尽可能使用 Type=simple；如果有master/slave进程的建议使用 Type=forking

环境变量初始化

通常我们的服务主进程可能会有比较多的参数，建议的做法是使用环境变量方式进行维护对应的参数，而在 systemd 中可支持K/V和配置文件方式来进行设置。

Environment: 指定Key=Value 的环境配置
EnvironmentFile: 指定包含key=value 的配置文件

注意: 通常情况下，我们会看到EnvironmentFile=-filename 和EnvironmentFile=filename 的写法，前者表示可忽略，即当文件不存在或环境变量加载失败时也不影响后续的处理逻辑。(在etcd的高版本里，大部分参数采用了环境变量加载的方式，可见未来通过环境变量来控制服务的启动参数已经是趋势)

进程生命周期管理

整个进程的生命周期是从准备启动进程开始到整个进程结束的过程管理。通常情况下，可以包含为如下几个环节:

ExecStartPre: 启动前，该指令可用于在进程启动前加载一些列的基础环境以及初始化检查机制
ExecStart: 启动逻辑，该指令用于启动进程的核心逻辑
ExecStartPost: 启动后，该指令用于在启动进程后进行回调的相关操作
ExecReload: 热加载，该指令用于对进程进行热加载，通常情况用于配置变更后的热重启(/bin/kill -s HUP $MAINPID)
ExecStop: 停止，该指令用于对进程执行指定的停止操作，通常情况下用于进行进程的优雅停止(/bin/kill -s TERM $MAINPID)
ExecStopPost: 停止后，该指令用于在进程停止后，进行一些列的资源释放和等待操作，因为通常情况当进程停止后，相关资源不能立即释放，因为服务不算真正呗停止，如果此时认为进程已停止而强制做一些操作，可能会影响到相关服务处理逻辑
TimeoutStopSec: 停止超时时间，指定服务停止后的超时时间，一般在通知服务是会使用SIGTERM信号，待超时时间内资源未释放，将使用SIGKILL进行强制杀死

重启策略

Restart: 当服务进程正常退出、异常退出、被杀死、超时的时候，是否重新启动该服务。
RestartSec: 多久后重启
StartLimitBurst: 启动的最大次数限制，超过后停止继续重启
StartLimitInterval: 启动时间的最大间隔

所谓"服务进程" 是指 ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, ExecReload= 中设置的进程。当进程是由于 systemd 的正常操作(例如 systemctl stop|restart)而被停止时，该服务不会被重新启动。所谓"超时"可以是看门狗的"keep-alive ping"超时，也可以是 systemctl start|reload|stop 操作超时.

可选值如下:

no:默认值，不会重启
on-success: 服务进程正常退出(退出码为"0"，或者进程收到 SIGHUP, SIGINT, SIGTERM, SIGPIPE 信号之一，并且退出码符合 SuccessExitStatus= 的设置)时进行重启
on-failure: 仅在服务进程异常退出(退出码不为"0"，或者进程被强制杀死(包括 “core dump"以及收到 SIGHUP, SIGINT, SIGTERM, SIGPIPE 之外的其他信号)，或者进程由于看门狗超时或者 systemd 的操作超时而被杀死)时重启
always: 无条件重启

资源限制

通常情况下，我们会对目标服务或进程进行一定资源的限制，以防止服务bug导致的整个系统资源耗尽。

在systemd 中，可以使用如下指令进行简单的资源限制:

LimitCPU: 限制CPU使用时长(秒)，等同ulimit -t
LimitNOFILE: 限制进程使用的文件描述符数量，等同ulimit -n
LimitNPROC: 限制进程的数量，等同于ulimit -u

注意: 一般为防止服务导致的系统过载，会对进程设置一些资源限制

计算资源调度

CPUSchedulingPolicy: 设置CPU的调度策略可设为 other, batch, idle, fifo, rr 之一
CPUSchedulingPriority: 设置CPU调度的优先级，取决于调度策略
CPUAffinity: 设置CPU的亲和性，可以指定cpu的编号，比如0,1

示例

[Service]
EnvironmentFile=/etc/calico/calico.env
ExecStartPre=-/usr/bin/docker pull ${CALICO_IMAGE}
ExecStart=/usr/bin/docker run --net=host --privileged ${CALICO_IMAGE}
ExecStop=-/usr/bin/docker stop calico-node
ExecStopPost=-/usr/bin/docker rm -f -v calico-node
Restart=on-failure
RestartSec=5
StartLimitBurst=3
StartLimitInterval=60s
CPUSchedulingPolicy=fifo
CPUAffinity=0,2
LimitNOFILE=1000
LimitNPROC=3000
LimitCORE=infinity

Install 块

在systemd 的服务管理中，install块主要包含了单元的启用信息。只有systemctl 的enable/disable 指令会调用该部分内容。

Alias: 指定服务的别名信息
WantedBy/RequiredBy: 设置启用服务的依赖服务

示例

[Install]
Alias=syslog.service
WantedBy=multi-user.target

完整示例

systemd service 完整配置

$ cat  /usr/lib/systemd/system/docker.service
[Unit]
Description=Docker CE Binary Release.
Documentation=https://docs.docker.com
Documentation=https://download.docker.com/linux/static/stable/x86_64/
After=network-online.target firewalld.service
Wants=network-online.target

[Service]
Type=notify
Environment="WELCOME=BGBiao Docker Base Environment."
ExecStartPre=/bin/echo ${WELCOME}
ExecStart=/usr/local/sbin/dockerd  $DOCKER_NETWORK_OPTIONS --live-restore --data-root /opt/data/docker
ExecStartPost=/usr/sbin/iptables -P FORWARD ACCEPT
ExecReload=/bin/kill -s HUP ${MAINPID}
ExecStop=/bin/kill -s TERM ${MAINPID}
ExecStopPost=/usr/bin/sleep 3

LimitNOFILE=100
LimitNPROC=3000
LimitCORE=infinity
TimeoutStartSec=0
Delegate=yes
KillMode=process
Restart=always
StartLimitBurst=3
StartLimitInterval=60s

[Install]
WantedBy=multi-user.target

service 生命周期过程

# 加载配置并重启docker
$ systemctl daemon-reload
$ systemctl restart docker

# 查看整个启动过程信息
$ cat /var/log/messages

Oct 31 14:56:39 host-192-168-0-171 systemd: Reloading.
Oct 31 14:56:43 host-192-168-0-171 systemd: Starting Docker CE Binary Release....
Oct 31 14:56:43 host-192-168-0-171 echo: BGBiao Docker Base Environment.
Oct 31 14:56:43 host-192-168-0-171 dockerd: time="2020-10-31T14:56:43.390806162+08:00" level=info msg="Starting up"
......
Oct 31 14:56:43 host-192-168-0-171 systemd: Started Docker CE Binary Release..


# 停止docker，查看整个过程

$ echo >  /var/log/messages
$ systemctl stop docker
$ cat /var/log/messages

Oct 31 15:01:11 host-192-168-0-171 systemd: Stopping Docker CE Binary Release....
Oct 31 15:01:11 host-192-168-0-171 dockerd: time="2020-10-31T15:01:11.618357841+08:00" level=info msg="Processing signal 'terminated'"
Oct 31 15:01:11 host-192-168-0-171 dockerd: time="2020-10-31T15:01:11.618919303+08:00" level=info msg="Daemon shutdown complete"
Oct 31 15:01:11 host-192-168-0-171 dockerd: time="2020-10-31T15:01:11.618948850+08:00" level=info msg="stopping healthcheck following graceful shutdown" module=libcontainerd
Oct 31 15:01:11 host-192-168-0-171 dockerd: time="2020-10-31T15:01:11.618971913+08:00" level=info msg="stopping event stream following graceful shutdown" error="context canceled" module=libcontainerd namespace=plugins.moby
Oct 31 15:01:11 host-192-168-0-171 dockerd: time="2020-10-31T15:01:11.618952081+08:00" level=info msg="stopping event stream following graceful shutdown" error="context canceled" module=libcontainerd namespace=moby
Oct 31 15:01:11 host-192-168-0-171 dockerd: time="2020-10-31T15:01:11.618954836+08:00" level=info msg="Processing signal 'terminated'"
Oct 31 15:01:15 host-192-168-0-171 systemd: Stopped Docker CE Binary Release..


# 执行
$ systemctl enable docker
Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.

# 会在多用户下创建服务软链，可保证系统在启动时默认启动服务
$ ls -ld /etc/systemd/system/multi-user.target.wants/docker.service
lrwxrwxrwx 1 root root 38 Oct 31 15:05 /etc/systemd/system/multi-user.target.wants/docker.service -> /usr/lib/systemd/system/docker.service


# 查看资源限制
## 系统的资源限制
$ ulimit -a | egrep  '(files|processes)'
open files                      (-n) 65535
max user processes              (-u) 63457

$ systemctl status docker | grep -i pid
 Main PID: 21926 (dockerd)

## dockerd 进程的资源限制(生产环境需严格设置参数)
$ cat /proc/21926/limits | egrep '(files|processes)'
Max processes             3000                 3000                 processes
Max open files            100                  100                  files

由上述的整个过程可以看到，我们在整个 dockerd 的生命周期中，systemd 如何去管理进程的生命周期的。

Tips

需要注意的是，对于资源限制，Linux中的/etc/security/limits.conf 作用域变小了(只对登录用户的资源进行限制)，可能对systemd 的 service 的资源限制不生效，因此对于systemd servie的资源限制，可以对全局文件进行修改:

$ cat /etc/systemd/system.conf
DefaultLimitNOFILE=100000
DefaultLimitNPROC=65535

屋漏偏逢连夜雨，船迟又遇打头风

Django 中使用 utf8mb4 支持 emoji 表情

Loading...

断崖上の风's 部落格

不知横跨几度银河，才终于在尽头与你相遇

Systemd服务管理实践

Unit 块

Service 块

Install 块

完整示例