使用此 Linux 命令保持日志文件更新。

日志非常适合找出应用程序在做什么或对可能的问题进行故障排除。几乎我们处理的每个应用程序都会生成日志，我们希望我们自己开发的应用程序也生成日志。日志越详细，我们拥有的信息就越多。但放任不管，日志可能会增长到无法管理的大小，反过来，它们可能会成为它们自己的问题。因此，最好将它们进行裁剪，保留我们需要的那些，并将其余的归档。

基本功能

logrotate 实用程序在管理日志方面非常出色。它可以轮转日志、压缩日志、通过电子邮件发送日志、删除日志、归档日志，并在你需要时开始记录最新的。

运行 logrotate 非常简单——只需要运行 logrotate -vs state-file config-file。在上面的命令中，v 选项开启详细模式，s 指定一个状态文件，最后的 config-file 是配置文件，你可以指定需要做什么。

实战演练

让我们看看在我们的系统上静默运行的 logrotate 配置，它管理我们在 /var/log 目录中找到的大量日志。查看该目录中的当前文件。你是否看到很多 *.[number].gz 文件？这就是 logrotate 正在做的。你可以在 /etc/logrotate.d/rsyslog 下找到此配置文件。我的配置文件如下：

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog > /dev/null 2>&1 || true
        endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages

{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                reload rsyslog > /dev/null 2>&1 || true
        endscript
}

该文件首先定义了轮转 /var/log/syslog 文件的说明，这些说明包含在后面的花括号中。以下是它们的含义：

• rotate 7: 保留最近 7 次轮转的日志。然后开始删除超出的。
• daily: 每天轮转日志，与 rotate 7 一起使用，这意味着日志将保留过去 7 天。其它选项是每周、每月、每年。还有一个大小参数，如果日志文件的大小增加超过指定的限制（例如，大小 10k、大小 10M、大小 10G 等），则将轮转日志文件。如果未指定任何内容，日志将在运行 logrotate 时轮转。你甚至可以在 cron 中运行 logrotate 以便在更具体的时间间隔内使用它。
• missingok: 如果日志文件缺失也没关系。不要惊慌。
• notifempty: 日志文件为空时不轮转。
• compress: 开启压缩，使用 nocompress 关闭它。
• delaycompress: 如果压缩已打开，则将压缩延迟到下一次轮转。这允许至少存在一个轮转但未压缩的文件。如果你希望昨天的日志保持未压缩以便进行故障排除，那么此配置会很有用。如果某些程序在重新启动/重新加载之前可能仍然写入旧文件，这也很有帮助，例如 Apache。
• postrotate/endscript: 轮转后运行此部分中的脚本。有助于做清理工作。还有一个 prerotate/endscript 用于在轮转开始之前执行操作。

你能弄清楚下一节对上面配置中提到的所有文件做了什么吗？第二节中唯一多出的参数是 sharedscripts，它告诉 logrotate 在所有日志轮转完成之前不要运行 postrotate/endscript 中的部分。它可以防止脚本在每一次轮转时执行，只在最后一次轮转完成时执行。

看点新的东西

我使用下面的配置来处理我系统上的 Nginx 的访问和错误日志。

/var/log/nginx/access.log
/var/log/nginx/error.log  {
        size 1
        missingok
        notifempty
        create 544 www-data adm
        rotate 30
        compress
        delaycompress
        dateext
        dateformat -%Y-%m-%d-%s
        sharedscripts
        extension .log
        postrotate
                service nginx reload
        endscript
}

上面的脚本可以使用如下命令运行：

logrotate -vs state-file /tmp/logrotate

第一次运行该命令会给出以下输出：

reading config file /tmp/logrotate
extension is now .log

Handling 1 logs

rotating pattern: /var/log/nginx/access.log
/var/log/nginx/error.log   1 bytes (30 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/nginx/access.log
  log needs rotating
considering log /var/log/nginx/error.log
  log does not need rotating
rotating log /var/log/nginx/access.log, log->rotateCount is 30
Converted ' -%Y-%m-%d-%s' -> '-%Y-%m-%d-%s'
dateext suffix '-2021-08-27-1485508250'
glob pattern '-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
glob finding logs to compress failed
glob finding old rotated logs failed
renaming /var/log/nginx/access.log to /var/log/nginx/access-2021-08-27-1485508250.log
creating new /var/log/nginx/access.log mode = 0544 uid = 33 gid = 4
running postrotate script
* Reloading nginx configuration nginx

第二次运行它：

reading config file /tmp/logrotate
extension is now .log

Handling 1 logs

rotating pattern: /var/log/nginx/access.log
/var/log/nginx/error.log   1 bytes (30 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/nginx/access.log
  log needs rotating
considering log /var/log/nginx/error.log
  log does not need rotating
rotating log /var/log/nginx/access.log, log->rotateCount is 30
Converted ' -%Y-%m-%d-%s' -> '-%Y-%m-%d-%s'
dateext suffix '-2021-08-27-1485508280'
glob pattern '-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
compressing log with: /bin/gzip
renaming /var/log/nginx/access.log to /var/log/nginx/access-2021-08-27-1485508280.log
creating new /var/log/nginx/access.log mode = 0544 uid = 33 gid = 4
running postrotate script
* Reloading nginx configuration nginx

第三次运行它：

reading config file /tmp/logrotate
extension is now .log

Handling 1 logs

rotating pattern: /var/log/nginx/access.log
/var/log/nginx/error.log   1 bytes (30 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/nginx/access.log
  log needs rotating
considering log /var/log/nginx/error.log
  log does not need rotating
rotating log /var/log/nginx/access.log, log->rotateCount is 30
Converted ' -%Y-%m-%d-%s' -> '-%Y-%m-%d-%s'
dateext suffix '-2021-08-27-1485508316'
glob pattern '-[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
compressing log with: /bin/gzip
renaming /var/log/nginx/access.log to /var/log/nginx/access-2021-08-27-1485508316.log
creating new /var/log/nginx/access.log mode = 0544 uid = 33 gid = 4
running postrotate script
* Reloading nginx configuration nginx

状态文件的内容如下所示：

logrotate state -- version 2
"/var/log/nginx/error.log" 2021-08-27-9:0:0
"/var/log/nginx/access.log" 2021-08-27-9:11:56

• 下载 Linux logrotate 备忘单

本文首发于作者个人博客，经授权改编。

via: https://opensource.com/article/21/10/linux-logrotate

作者：Ayush Sharma 选题：lujun9972 译者：perfiffer 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

控制组可以按照应用管理资源，而不是按照组成应用的单个进程。

作为一个系统管理员，没有事情比意外地耗尽计算资源让我更觉得沮丧。我曾不止一次填满了一个分区的所有可用磁盘空间、耗尽内存、以及没有足够的 CPU 时间在合理的时间内处理我的任务。资源管理是系统管理员最重要的工作之一。

资源管理的关键是保证所有的进程能够相对公平的访问需要的系统资源。资源管理还包括确保在需要时添加内存、硬盘驱动器空间、还有 CPU 处理能力；或者在无法添加时限制资源的使用。此外，应该阻止独占系统资源的用户，无论其是否有意。

系统管理员可以通过一些工具监控和管理不同的系统资源。例如，top) 和类似的工具允许你监控内存、I/O、存储（磁盘、SSD 等）、网络、交换空间、CPU 的用量等。这些工具，尤其是那些以 CPU 为中心的工具，大部分基于以运行的进程为基本单位进行控制的模型。它们最多只是提供了一种方式来调整 nice 数字，从而修改优先级，或者杀死一个运行的进程。（要了解 nice 数字的信息，查看 使用 Glances 监控 Linux 和 Windows 主机）。

SystemV 环境中基于传统的资源管理的其他工具，由 /etc/security/limits.conf 文件和 /etc/security/limits.d 中的本地配置文件控制。资源可以按照用户或组以一种相对粗糙但实用的方式限制。可以管理的资源包括内存的各个方面、每日的总 CPU 时间、数据总量、优先级、nice 数字、并发登录的数量、进程数、文件大小的最大值等。

使用控制组管理进程

systemd 和 SystemV 之间的一个主要差异是管理进程的方式。SystemV 将每个进程视作一个独立的实体。systemd 将相关的进程集中到一个控制组，简写做 cgroup，并将控制组作为一个整体管理系统资源。这意味着资源能够基于应用管理，而不是由组成应用的各个进程来管理。

控制组的控制单元称作 切片单元 slice unit 。切片是允许 systemd 以树状格式控制程序次序，从而简化管理的概念化。

查看控制组

我将从一些允许你查看不同类型控制组信息的命令开始。 systemctl status <service> 命令显示一个特定服务的切片信息，包括服务的切片。这个例子展示了 at 守护进程：

[root@testvm1 ~]# systemctl status atd.service
● atd.service - Deferred execution scheduler
     Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2020-09-23 12:18:24 EDT; 1 day 3h ago
       Docs: man:atd(8)
   Main PID: 1010 (atd)
      Tasks: 1 (limit: 14760)
     Memory: 440.0K
        CPU: 5ms
     CGroup: /system.slice/atd.service
             └─1010 /usr/sbin/atd -f

Sep 23 12:18:24 testvm1.both.org systemd[1]: Started Deferred execution scheduler.
[root@testvm1 ~]#

这是一个我感到 systemd 比 SystemV 和旧的初始化程序更好用的原因的绝佳示例。这里的信息远比 SystemV 能够提供的丰富。CGroup 项包括的层级结构中，system.slice 是 systemd（PID 1），atd.service 在下一层，是 system.slice 的一部分。CGroup 项的第二行还显示了进程 ID（PID）和启动守护进程使用的命令。

systemctl 命令可以列出多个控制组项，--all 参数列出所有的切片，包括当前没有激活的切片：

[root@testvm1 ~]# systemctl -t slice --all
  UNIT                             LOAD   ACTIVE   SUB    DESCRIPTION                    
  -.slice                          loaded active   active Root Slice                      
  system-getty.slice               loaded active   active system-getty.slice              
  system-lvm2\x2dpvscan.slice      loaded active   active system-lvm2\x2dpvscan.slice    
  system-modprobe.slice            loaded active   active system-modprobe.slice          
  system-sshd\x2dkeygen.slice      loaded active   active system-sshd\x2dkeygen.slice    
  system-systemd\x2dcoredump.slice loaded inactive dead   system-systemd\x2dcoredump.slice
  system-systemd\x2dfsck.slice     loaded active   active system-systemd\x2dfsck.slice    
  system.slice                     loaded active   active System Slice                    
  user-0.slice                     loaded active   active User Slice of UID 0            
  user-1000.slice                  loaded active   active User Slice of UID 1000          
  user.slice                       loaded active   active User and Session Slice          

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

11 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
[root@testvm1 ~]#

关于这个数据，第一个需要注意的是数据显示了 UID 0（root）和 UID 1000 的用户切片，UID 1000 是我登录的用户。这里列出了组成每个切片的切片部分，而不是服务。还说明了每个用户登录时都会为其创建一个切片，这为将一个用户的所有任务作为单个控制组项进行管理提供了一种方式。

探索控制组的层次结构

目前为止一切顺利，但是控制组是分层的，所有的服务单元作为其中一个控制组的成员运行。要查看这个层次结构很简单，使用一个旧命令和 systemd 的一个新命令即可。

ps 命令可以用于映射进程的和其所处的控制组层次。注意使用 ps 命令时需要指明想要的数据列。我大幅削减了下面命令的输出数量，但是试图保留足够的数据，以便你能够对自己系统上的输出有所感受：

[root@testvm1 ~]# ps xawf -eo pid,user,cgroup,args
    PID USER     CGROUP                      COMMAND
      2 root     -                           [kthreadd]
      3 root     -                            \_ [rcu_gp]
      4 root     -                            \_ [rcu_par_gp]
      6 root     -                            \_ [kworker/0:0H-kblockd]
      9 root     -                            \_ [mm_percpu_wq]
     10 root     -                            \_ [ksoftirqd/0]
     11 root     -                            \_ [rcu_sched]
     12 root     -                            \_ [migration/0]
     13 root     -                            \_ [cpuhp/0]
     14 root     -                            \_ [cpuhp/1]
<删节>
 625406 root     -                            \_ [kworker/3:0-ata_sff]
 625409 root     -                            \_ [kworker/u8:0-events_unbound]
      1 root     0::/init.scope              /usr/lib/systemd/systemd --switched-root --system --deserialize 30
    588 root     0::/system.slice/systemd-jo /usr/lib/systemd/systemd-journald
    599 root     0::/system.slice/systemd-ud /usr/lib/systemd/systemd-udevd
    741 root     0::/system.slice/auditd.ser /sbin/auditd
    743 root     0::/system.slice/auditd.ser  \_ /usr/sbin/sedispatch
    764 root     0::/system.slice/ModemManag /usr/sbin/ModemManager
    765 root     0::/system.slice/NetworkMan /usr/sbin/NetworkManager --no-daemon
    767 root     0::/system.slice/irqbalance /usr/sbin/irqbalance --foreground
    779 root     0::/system.slice/mcelog.ser /usr/sbin/mcelog --ignorenodev --daemon --foreground
    781 root     0::/system.slice/rngd.servi /sbin/rngd -f
    782 root     0::/system.slice/rsyslog.se /usr/sbin/rsyslogd -n
<删节>
    893 root     0::/system.slice/sshd.servi sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
   1130 root     0::/user.slice/user-0.slice  \_ sshd: root [priv]
   1147 root     0::/user.slice/user-0.slice  |   \_ sshd: root@pts/0
   1148 root     0::/user.slice/user-0.slice  |       \_ -bash
   1321 root     0::/user.slice/user-0.slice  |           \_ screen
   1322 root     0::/user.slice/user-0.slice  |               \_ SCREEN
   1323 root     0::/user.slice/user-0.slice  |                   \_ /bin/bash
 498801 root     0::/user.slice/user-0.slice  |                   |   \_ man systemd.resource-control
 498813 root     0::/user.slice/user-0.slice  |                   |       \_ less
   1351 root     0::/user.slice/user-0.slice  |                   \_ /bin/bash
 123293 root     0::/user.slice/user-0.slice  |                   |   \_ man systemd.slice
 123305 root     0::/user.slice/user-0.slice  |                   |       \_ less
   1380 root     0::/user.slice/user-0.slice  |                   \_ /bin/bash
 625412 root     0::/user.slice/user-0.slice  |                   |   \_ ps xawf -eo pid,user,cgroup,args
 625413 root     0::/user.slice/user-0.slice  |                   |   \_ less
 246795 root     0::/user.slice/user-0.slice  |                   \_ /bin/bash
 625338 root     0::/user.slice/user-0.slice  |                       \_ /usr/bin/mc -P /var/tmp/mc-root/mc.pwd.246795
 625340 root     0::/user.slice/user-0.slice  |                           \_ bash -rcfile .bashrc
   1218 root     0::/user.slice/user-1000.sl  \_ sshd: dboth [priv]
   1233 dboth    0::/user.slice/user-1000.sl      \_ sshd: dboth@pts/1
   1235 dboth    0::/user.slice/user-1000.sl          \_ -bash
<删节>
   1010 root     0::/system.slice/atd.servic /usr/sbin/atd -f
   1011 root     0::/system.slice/crond.serv /usr/sbin/crond -n
   1098 root     0::/system.slice/lxdm.servi /usr/sbin/lxdm-binary
   1106 root     0::/system.slice/lxdm.servi  \_ /usr/libexec/Xorg -background none :0 vt01 -nolisten tcp -novtswitch -auth /var/run/lxdm/lxdm-:0.auth
 370621 root     0::/user.slice/user-1000.sl  \_ /usr/libexec/lxdm-session
 370631 dboth    0::/user.slice/user-1000.sl      \_ xfce4-session
 370841 dboth    0::/user.slice/user-1000.sl          \_ /usr/bin/ssh-agent /bin/sh -c exec -l bash -c "/usr/bin/startxfce4"
 370911 dboth    0::/user.slice/user-1000.sl          \_ xfwm4 --display :0.0 --sm-client-id 2dead44ab-0b4d-4101-bca4-e6771f4a8ac2
 370930 dboth    0::/user.slice/user-1000.sl          \_ xfce4-panel --display :0.0 --sm-client-id 2ce38b8ef-86fd-4189-ace5-deec1d0e0952
 370942 dboth    0::/user.slice/user-1000.sl          |   \_ /usr/lib64/xfce4/panel/wrapper-2.0 /usr/lib64/xfce4/panel/plugins/libsystray.so 6 23068680 systr
ay Notification Area Area where notification icons appear
 370943 dboth    0::/user.slice/user-1000.sl          |   \_ /usr/lib64/xfce4/panel/wrapper-2.0 /usr/lib64/xfce4/panel/plugins/libpulseaudio-plugin.so 8 2306
8681 pulseaudio PulseAudio Plugin Adjust the audio volume of the PulseAudio sound system
 370944 dboth    0::/user.slice/user-1000.sl          |   \_ /usr/lib64/xfce4/panel/wrapper-2.0 /usr/lib64/xfce4/panel/plugins/libxfce4powermanager.so 9 2306
8682 power-manager-plugin Power Manager Plugin Display the battery levels of your devices and control the brightness of your display
 370945 dboth    0::/user.slice/user-1000.sl          |   \_ /usr/lib64/xfce4/panel/wrapper-2.0 /usr/lib64/xfce4/panel/plugins/libnotification-plugin.so 10 2
3068683 notification-plugin Notification Plugin Notification plugin for the Xfce panel
 370948 dboth    0::/user.slice/user-1000.sl          |   \_ /usr/lib64/xfce4/panel/wrapper-2.0 /usr/lib64/xfce4/panel/plugins/libactions.so 14 23068684 acti
ons Action Buttons Log out, lock or other system actions
 370934 dboth    0::/user.slice/user-1000.sl          \_ Thunar --sm-client-id 2cfc809d8-4e1d-497a-a5c5-6e4fa509c3fb --daemon
 370939 dboth    0::/user.slice/user-1000.sl          \_ xfdesktop --display :0.0 --sm-client-id 299be0608-4dca-4055-b4d6-55ec6e73a324
 370962 dboth    0::/user.slice/user-1000.sl          \_ nm-applet
<删节>

你可以使用 systemd-cgls 命令查看整个层次结构，这个命令不需要任何的复杂参数，更加简单。

我也大幅缩短了这个树状结构，但是保留了足够多的输出，以便你能够了解在自己的系统上执行这个命令时应该看到的数据总量和条目类型。我在我的一个虚拟机上执行了这个命令，输出大概有 200 行；我的主要工作站的输出大概有 250 行。

[root@testvm1 ~]# systemd-cgls
Control group /:
-.slice
├─user.slice
│ ├─user-0.slice
│ │ ├─session-1.scope
│ │ │ ├─  1130 sshd: root [priv]
│ │ │ ├─  1147 sshd: root@pts/0
│ │ │ ├─  1148 -bash
│ │ │ ├─  1321 screen
│ │ │ ├─  1322 SCREEN
│ │ │ ├─  1323 /bin/bash
│ │ │ ├─  1351 /bin/bash
│ │ │ ├─  1380 /bin/bash
│ │ │ ├─123293 man systemd.slice
│ │ │ ├─123305 less
│ │ │ ├─246795 /bin/bash
│ │ │ ├─371371 man systemd-cgls
│ │ │ ├─371383 less
│ │ │ ├─371469 systemd-cgls
│ │ │ └─371470 less
│ │ └─[email protected] …
│ │   ├─dbus-broker.service
│ │   │ ├─1170 /usr/bin/dbus-broker-launch --scope user
│ │   │ └─1171 dbus-broker --log 4 --controller 12 --machine-id 3bccd1140fca488187f8a1439c832f07 --max-bytes 100000000000000 --max-fds 25000000000000 --max->
│ │   ├─gvfs-daemon.service
│ │   │ └─1173 /usr/libexec/gvfsd
│ │   └─init.scope
│ │     ├─1137 /usr/lib/systemd/systemd --user
│ │     └─1138 (sd-pam)
│ └─user-1000.slice
│   ├─[email protected] …
│   │ ├─dbus\x2d:1.2\x2dorg.xfce.Xfconf.slice
│   │ │ └─dbus-:[email protected]
│   │ │   └─370748 /usr/lib64/xfce4/xfconf/xfconfd
│   │ ├─dbus\x2d:1.2\x2dca.desrt.dconf.slice
│   │ │ └─dbus-:[email protected]
│   │ │   └─371262 /usr/libexec/dconf-service
│   │ ├─dbus-broker.service
│   │ │ ├─1260 /usr/bin/dbus-broker-launch --scope user
│   │ │ └─1261 dbus-broker --log 4 --controller 11 --machine-id
<删节>
│   │ └─gvfs-mtp-volume-monitor.service
│   │   └─370987 /usr/libexec/gvfs-mtp-volume-monitor
│   ├─session-3.scope
│   │ ├─1218 sshd: dboth [priv]
│   │ ├─1233 sshd: dboth@pts/1
│   │ └─1235 -bash
│   └─session-7.scope
│     ├─370621 /usr/libexec/lxdm-session
│     ├─370631 xfce4-session
│     ├─370805 /usr/bin/VBoxClient --clipboard
│     ├─370806 /usr/bin/VBoxClient --clipboard
│     ├─370817 /usr/bin/VBoxClient --seamless
│     ├─370818 /usr/bin/VBoxClient --seamless
│     ├─370824 /usr/bin/VBoxClient --draganddrop
│     ├─370825 /usr/bin/VBoxClient --draganddrop
│     ├─370841 /usr/bin/ssh-agent /bin/sh -c exec -l bash -c "/usr/bin/startxfce4"
│     ├─370910 /bin/gpg-agent --sh --daemon --write-env-file /home/dboth/.cache/gpg-agent-info
│     ├─370911 xfwm4 --display :0.0 --sm-client-id 2dead44ab-0b4d-4101-bca4-e6771f4a8ac2
│     ├─370923 xfsettingsd --display :0.0 --sm-client-id 261b4a437-3029-461c-9551-68c2c42f4fef
│     ├─370930 xfce4-panel --display :0.0 --sm-client-id 2ce38b8ef-86fd-4189-ace5-deec1d0e0952
│     ├─370934 Thunar --sm-client-id 2cfc809d8-4e1d-497a-a5c5-6e4fa509c3fb --daemon
│     ├─370939 xfdesktop --display :0.0 --sm-client-id 299be0608-4dca-4055-b4d6-55ec6e73a324
<删节>
└─system.slice
  ├─rngd.service
  │ └─1650 /sbin/rngd -f
  ├─irqbalance.service
  │ └─1631 /usr/sbin/irqbalance --foreground
  ├─fprintd.service
  │ └─303383 /usr/libexec/fprintd
  ├─systemd-udevd.service
  │ └─956 /usr/lib/systemd/systemd-udevd
<删节>
  ├─systemd-journald.service
  │ └─588 /usr/lib/systemd/systemd-journald
  ├─atd.service
  │ └─1010 /usr/sbin/atd -f
  ├─system-dbus\x2d:1.10\x2dorg.freedesktop.problems.slice
  │ └─dbus-:[email protected]
  │   └─371197 /usr/sbin/abrt-dbus -t133
  ├─sshd.service
  │ └─893 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
  ├─vboxservice.service
  │ └─802 /usr/sbin/VBoxService -f
  ├─crond.service
  │ └─1011 /usr/sbin/crond -n
  ├─NetworkManager.service
  │ └─765 /usr/sbin/NetworkManager --no-daemon
  ├─switcheroo-control.service
  │ └─787 /usr/libexec/switcheroo-control
 <删节>

这个树状视图显示了所有的用户和系统切片，以及每个控制组内正在运行的服务和程序。注意叫作 scope（范围）的单元，它将相关的程序组成一个管理单元，在上面列出的结果中就是 user-1000.slice。user-1000.slice/session-7.scope 控制组包含了 GUI 桌面程序层次结构，以 LXDM 显示管理器会话和其所有的子任务开始，包括像 Bash 命令行解释器和 Thunar GUI 文件管理器之类的程序。

配置文件中不定义范围单元，而是作为启动相关程序组的结果程序化生成的。范围单元不创建或启动作为控制组的组成部分运行的进程。范围内的所有进程都是平等的，没有内部的层次结构。一个范围的生命周期在第一个进程创建时开始，在最后一个进程销毁时结束。

在你的桌面打开多个窗口，比如终端模拟器、LibreOffice、或者任何你想打开的，然后切换到一个可用的虚拟控制台，启动类似 top 或 Midnight Commander 的程序。在主机运行 systemd-cgls 命令，留意整体的层次结构和范围单元。

systemd-cgls 命令提供的控制组层次结构表示（以及组成控制组单元的细节），比我见过的其他任何指令都要完整。和 ps 命令提供的输出相比，我喜欢 systemd-cgls 命令更简洁的树形表示。

来自朋友们的一点帮助

介绍完这些基础知识后，我曾计划过深入研究控制组的更多细节，以及如何使用，但是我在 Opensource.com 的姐妹网站 Enable Sysadmin 上发现了一系列四篇优秀文章，由 Red Hat 公司的 Steve Ovens 所作。与其从头重写 Steve 的文章，我觉得倒不如通过链接到这些文章，利用他的控制组专业知识：

1. 一个 Linux 系统管理员对控制组的介绍
2. 如何用 CPUShares 管理控制组
3. 用更难的方式，手动管理控制组
4. 用 systemd 管理控制组

像我一样享受这些文章并从中汲取知识吧。

其他资源

互联网上充斥着大量关于 systemd 的信息，但大部分都简短生硬、愚钝、甚至令人误解。除了本文提到的资源，下面的网页提供了关于 systemd 启动更详细可靠的信息。自从我开始这一系列的文章来反映我所做的研究以来，这个的列表已经变长了。

• Fedora 项目有一个优质实用的 systemd 指南，几乎有你使用 systemd 配置、管理、维护一个 Fedora 计算机需要知道的一切。
• Fedora 项目还有一个好用的 速查表，交叉引用了古老的 SystemV 命令和对应的 systemd 命令。
• systemd.unit(5) 手册页 包含了一个不错的单元文件中各个节的列表，以及这些节的配置选项和简洁的描述。
• Red Hat 文档包含了一个 单元文件结构 的有用描述，还有一些其他的重要信息。
• 要获取 systemd 的详细技术信息和创立的原因，查看 Freedesktop.org 的 systemd 描 述。这个使我发现过的最棒页面之一，因为其中包含了许多指向其他重要准确文档的链接。
• Linux.com 上 “systemd 的更多乐趣” 提供了更高级的 systemd 信息和提示。
• 查看 systemd.resource-control(5) 的手册页
• 查看 Linux 内核用户和管理员指南 中的 控制组 v2 条目。

还有一系列针对系统管理员的深度技术文章，由 systemd 的设计者和主要开发者 Lennart Poettering 所作。这些文章写于 2010 年 4 月到 2011 年 9 月之间，但在当下仍然像当时一样有 价值。关于 systemd 及其生态的许多其他优秀的作品都是基于这些文章的。

• Rethinking PID 1
• systemd for Administrators, Part I
• systemd for Administrators, Part II
• systemd for Administrators, Part III
• systemd for Administrators, Part IV
• systemd for Administrators, Part V
• systemd for Administrators, Part VI
• systemd for Administrators, Part VII
• systemd for Administrators, Part VIII
• systemd for Administrators, Part IX
• systemd for Administrators, Part X
• systemd for Administrators, Part XI

via: https://opensource.com/article/20/10/cgroups

作者：David Both 选题：lujun9972 译者：YungeG 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这篇文章描述并演示了 NMState，这是一个使用声明式方法配置主机的网络管理器。这意味着你可以通过 API 定义所需的配置状态，而工具则通过 提供者 provider 来应用配置。

配置方法：命令式与声明式

网络管理有时候是一项非常复杂的任务，这取决于环境的规模和多样性。在 IT 的早期，网络管理依赖于网络管理员在网络设备上手动执行命令。如今， 基础设施即代码 Infrastructure as Code （IaC）允许以不同的方式将这些任务自动化。z这基本上有两种方法：命令式或声明式。

在命令式方法中，你会定义“如何”达到所需的配置状态。而在声明式范式里则定义了“什么”是所需的配置状态，所以它不确定哪些步骤是必需的，也不确定它们必须以何种顺序执行。这种方法目前正在聚集更多的人员参与，你可以在目前使用的大多数管理和编排工具上找到它。

NMState：一个声明式的工具

NMState 是一个网络管理器，允许你按照声明式方法配置主机。这意味着你通过一个北向的声明式 API 定义所需的配置状态，这个工具通过南向的 提供者 provider 应用配置。

目前 NMState 支持的唯一的提供者是 NetworkManager，它是为 Fedora Linux 提供网络功能的主要服务。不过，NMState 的开发计划中将逐渐增加其他提供者。

关于 NMState 的进一步信息，请访问其项目 站点 或 GitHub 仓库。

安装

NMState 在 Fedora Linux 29+ 上可用，需要在系统上安装并运行 NetworkManager 1.26 或更高版本。下面是在 Fedora Linux 34 上的安装情况：

$ sudo dnf -y install nmstate
...
输出节略
...
Installed:
  NetworkManager-config-server-1:1.30.4-1.fc34.noarch      gobject-introspection-1.68.0-3.fc34.x86_64      nispor-1.0.1-2.fc34.x86_64              nmstate-1.0.3-2.fc34.noarch
  python3-gobject-base-3.40.1-1.fc34.x86_64                python3-libnmstate-1.0.3-2.fc34.noarch          python3-nispor-1.0.1-2.fc34.noarch      python3-varlink-30.3.1-2.fc34.noarch

Complete!

这样，你可以使用 nmstatectl 作为 NMState 的命令行工具。请参考 nmstatectl -help 或 man nmstatectl 以了解关于这个工具的进一步信息。

使用 NMstate

首先要检查系统中安装的 NMState 版本：

$ nmstatectl version
1.0.3

检查一个网络接口的当前配置，例如 eth0 的配置：

$ nmstatectl show eth0
2021-06-29 10:28:21,530 root         DEBUG    NetworkManager version 1.30.4
2021-06-29 10:28:21,531 root         DEBUG    Async action: Retrieve applied config: ethernet eth0 started
2021-06-29 10:28:21,531 root         DEBUG    Async action: Retrieve applied config: ethernet eth1 started
2021-06-29 10:28:21,532 root         DEBUG    Async action: Retrieve applied config: ethernet eth0 finished
2021-06-29 10:28:21,533 root         DEBUG    Async action: Retrieve applied config: ethernet eth1 finished
---
dns-resolver:
  config: {}
  running:
    search: []
    server:
    - 192.168.122.1
route-rules:
  config: []
routes:
  config: []
  running:
  - destination: fe80::/64
    metric: 100
    next-hop-address: ''
    next-hop-interface: eth0
    table-id: 254
  - destination: 0.0.0.0/0
    metric: 100
    next-hop-address: 192.168.122.1
    next-hop-interface: eth0
    table-id: 254
  - destination: 192.168.122.0/24
    metric: 100
    next-hop-address: ''
    next-hop-interface: eth0
    table-id: 254
interfaces:
- name: eth0
  type: ethernet
  state: up
  ipv4:
    enabled: true
    address:
    - ip: 192.168.122.238
      prefix-length: 24
    auto-dns: true
    auto-gateway: true
    auto-route-table-id: 0
    auto-routes: true
    dhcp: true
  ipv6:
    enabled: true
    address:
    - ip: fe80::c3c9:c4f9:75b1:a570
      prefix-length: 64
    auto-dns: true
    auto-gateway: true
    auto-route-table-id: 0
    auto-routes: true
    autoconf: true
    dhcp: true
  lldp:
    enabled: false
  mac-address: 52:54:00:91:E4:4E
  mtu: 1500

正如你在上面看到的，这个网络配置显示了四个主要部分：

• dns-resolver：这部分是这个接口的名字服务器配置。
• route-rules：它说明了路由规则。
• routes：它包括动态和静态路由。
• interfaces：这部分描述了 ipv4 和 ipv6 设置。

修改配置

你可以在两种模式下修改所需的配置状态：

• 交互式：通过 nmstatectl edit 编辑接口配置。这个命令调用环境变量 EDITOR 定义的文本编辑器，因此可以用 yaml 格式编辑网络状态。完成编辑后，NMState 将应用新的网络配置，除非有语法错误。
• 基于文件的：使用 nmstatectl apply 应用接口配置，它从先前创建的 yaml 或 json 文件中导入一个所需的配置状态。

下面几节告诉你如何使用 NMState 来改变网络配置。这些改变可能会对系统造成破坏，所以建议在测试系统或客户虚拟机上执行这些任务，直到你对 NMState 有更好的理解。

这里使用的测试系统有两个以太网接口，eth0 和 eth1：

$ ip -br -4 a
lo               UNKNOWN        127.0.0.1/8
eth0             UP             192.168.122.238/24
eth1             UP             192.168.122.108/24

互动配置模式的例子

使用 nmstatectl edit 命令将 eth0 接口的 MTU 改为 9000 字节，如下所示：

$ sudo nmstatectl edit eth0

---
dns-resolver:
  config: {}
  running:
    search: []
    server:
    - 192.168.122.1
route-rules:
  config: []
routes:
  config: []
  running:
  - destination: fe80::/64
    metric: 100
    next-hop-address: ''
    next-hop-interface: eth0
    table-id: 254
  - destination: 0.0.0.0/0
    metric: 100
    next-hop-address: 192.168.122.1
    next-hop-interface: eth0
    table-id: 254
  - destination: 192.168.122.0/24
    metric: 100
    next-hop-address: ''
    next-hop-interface: eth0
    table-id: 254
interfaces:
- name: eth0
  type: ethernet
  state: up
  ipv4:
    enabled: true
    address:
    - ip: 192.168.122.123
      prefix-length: 24
    auto-dns: true
    auto-gateway: true
    auto-route-table-id: 0
    auto-routes: true
    dhcp: true
  ipv6:
    enabled: true
    address:
    - ip: fe80::c3c9:c4f9:75b1:a570
      prefix-length: 64
    auto-dns: true
    auto-gateway: true
    auto-route-table-id: 0
    auto-routes: true
    autoconf: true
    dhcp: true
  lldp:
    enabled: false
  mac-address: 52:54:00:91:E4:4E
  mtu: 9000

在保存并退出编辑器后，NMState 应用新的网络期望状态：

2021-06-29 11:29:05,726 root         DEBUG    Nmstate version: 1.0.3
2021-06-29 11:29:05,726 root         DEBUG    Applying desire state: {'dns-resolver': {'config': {}, 'running': {'search': [], 'server': ['192.168.122.1']}}, 'route-rules': {'config': []}, 'routes': {'config': [], 'running': [{'destination': 'fe80::/64', 'metric': 102, 'next-hop-address': '', 'next-hop-interface': 'eth0', 'table-id': 254}, {'destination': '0.0.0.0/0', 'metric': 102, 'next-hop-address': '192.168.122.1', 'next-hop-interface': 'eth0', 'table-id': 254}, {'destination': '192.168.122.0/24', 'metric': 102, 'next-hop-address': '', 'next-hop-interface': 'eth0', 'table-id': 254}]}, 'interfaces': [{'name': 'eth0', 'type': 'ethernet', 'state': 'up', 'ipv4': {'enabled': True, 'address': [{'ip': '192.168.122.238', 'prefix-length': 24}], 'auto-dns': True, 'auto-gateway': True, 'auto-route-table-id': 0, 'auto-routes': True, 'dhcp': True}, 'ipv6': {'enabled': True, 'address': [{'ip': 'fe80::5054:ff:fe91:e44e', 'prefix-length': 64}], 'auto-dns': True, 'auto-gateway': True, 'auto-route-table-id': 0, 'auto-routes': True, 'autoconf': True, 'dhcp': True}, 'lldp': {'enabled': False}, 'mac-address': '52:54:00:91:E4:4E', 'mtu': 9000}]}
--- output omitted ---
2021-06-29 11:29:05,760 root         DEBUG    Async action: Update profile uuid:2bdee700-f62b-365a-bd1d-69d9c31a9f0c iface:eth0 type:ethernet started
2021-06-29 11:29:05,792 root         DEBUG    Async action: Update profile uuid:2bdee700-f62b-365a-bd1d-69d9c31a9f0c iface:eth0 type:ethernet finished

现在，使用 ip 命令和 eth0 的配置文件来检查 eth0 的 MTU 是不是 9000 字节。

$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:91:e4:4e brd ff:ff:ff:ff:ff:ff
    altname enp1s0

$ sudo cat /etc/NetworkManager/system-connections/eth0.nmconnection
[sudo] password for admin:
[connection]
id=eth0
uuid=2bdee700-f62b-365a-bd1d-69d9c31a9f0c
type=ethernet
interface-name=eth0
lldp=0
permissions=

[ethernet]
cloned-mac-address=52:54:00:91:E4:4E
mac-address-blacklist=
mtu=9000

[ipv4]
dhcp-client-id=mac
dhcp-timeout=2147483647
dns-search=
method=auto

[ipv6]
addr-gen-mode=eui64
dhcp-duid=ll
dhcp-iaid=mac
dhcp-timeout=2147483647
dns-search=
method=auto
ra-timeout=2147483647

[proxy]

基于文件的配置模式的例子

让我们使用基于文件的方法来设置一个新的配置状态。这里我们禁用 eth1 接口的 IPv6 配置。

首先，创建一个 yaml 文件来定义 eth1 接口的期望状态。使用 nmstatectl show 来保存当前设置，然后使用 nmstatectl edit 来禁用 IPv6。

$ nmstatectl show eth1 > eth1.yaml

$ vi eth1.yaml
---
dns-resolver:
  config: {}
  running:
    search: []
    server:
    - 192.168.122.1
route-rules:
  config: []
routes:
  config: []
  running:
  - destination: fe80::/64
    metric: 101
    next-hop-address: ''
    next-hop-interface: eth1
    table-id: 254
  - destination: 0.0.0.0/0
    metric: 101
    next-hop-address: 192.168.122.1
    next-hop-interface: eth1
    table-id: 254
  - destination: 192.168.122.0/24
    metric: 101
    next-hop-address: ''
    next-hop-interface: eth1
    table-id: 254
interfaces:
- name: eth1
  type: ethernet
  state: up
  ipv4:
    enabled: true
    address:
    - ip: 192.168.122.108
      prefix-length: 24
    auto-dns: true
    auto-gateway: true
    auto-route-table-id: 0
    auto-routes: true
    dhcp: true
  ipv6:
    enabled: false
    address:
    - ip: fe80::5054:ff:fe3c:9b04
      prefix-length: 64
    auto-dns: true
    auto-gateway: true
    auto-route-table-id: 0
    auto-routes: true
    autoconf: true
    dhcp: true
  lldp:
    enabled: false
  mac-address: 52:54:00:3C:9B:04
  mtu: 1500

保存新的配置后，用它来应用新的状态：

$ sudo nmstatectl apply eth1.yaml

2021-06-29 12:17:21,531 root         DEBUG    Nmstate version: 1.0.3
2021-06-29 12:17:21,531 root         DEBUG    Applying desire state: {'dns-resolver': {'config': {}, 'running': {'search': [], 'server': ['192.168.122.1']}}, 'route-rules': {'config': []}, 'routes': {'config': [], 'running': [{'destination': 'fe80::/64', 'metric': 101, 'next-hop-address': '', 'next-hop-interface': 'eth1', 'table-id': 254}, {'destination': '0.0.0.0/0', 'metric': 101, 'next-hop-address': '192.168.122.1', 'next-hop-interface': 'eth1', 'table-id': 254}, {'destination': '192.168.122.0/24', 'metric': 101, 'next-hop-address': '', 'next-hop-interface': 'eth1', 'table-id': 254}]}, 'interfaces': [{'name': 'eth1', 'type': 'ethernet', 'state': 'up', 'ipv4': {'enabled': True, 'address': [{'ip': '192.168.122.108', 'prefix-length': 24}], 'auto-dns': True, 'auto-gateway': True, 'auto-route-table-id': 0, 'auto-routes': True, 'dhcp': True}, 'ipv6': {'enabled': False}, 'lldp': {'enabled': False}, 'mac-address': '52:54:00:3C:9B:04', 'mtu': 1500}]}
--- output omitted ---
2021-06-29 12:17:21,582 root         DEBUG    Async action: Update profile uuid:5d7244cb-673d-3b88-a675-32e31fad4347 iface:eth1 type:ethernet started
2021-06-29 12:17:21,587 root         DEBUG    Async action: Update profile uuid:5d7244cb-673d-3b88-a675-32e31fad4347 iface:eth1 type:ethernet finished
--- output omitted ---
Desired state applied:
---
dns-resolver:
  config: {}
  running:
    search: []
    server:
    - 192.168.122.1
route-rules:
  config: []
routes:
  config: []
  running:
  - destination: fe80::/64
    metric: 101
    next-hop-address: ''
    next-hop-interface: eth1
    table-id: 254
  - destination: 0.0.0.0/0
    metric: 101
    next-hop-address: 192.168.122.1
    next-hop-interface: eth1
    table-id: 254
  - destination: 192.168.122.0/24
    metric: 101
    next-hop-address: ''
    next-hop-interface: eth1
    table-id: 254
interfaces:
- name: eth1
  type: ethernet
  state: up
  ipv4:
    enabled: true
    address:
    - ip: 192.168.122.108
      prefix-length: 24
    auto-dns: true
    auto-gateway: true
    auto-route-table-id: 0
    auto-routes: true
    dhcp: true
  ipv6:
    enabled: false
  lldp:
    enabled: false
  mac-address: 52:54:00:3C:9B:04
  mtu: 1500

你可以检查看到 eth1 接口没有配置任何 IPv6：

$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.238/24 fe80::5054:ff:fe91:e44e/64
eth1             UP             192.168.122.108/24

$ sudo cat /etc/NetworkManager/system-connections/eth1.nmconnection
[connection]
id=eth1
uuid=5d7244cb-673d-3b88-a675-32e31fad4347
type=ethernet
interface-name=eth1
lldp=0
permissions=

[ethernet]
cloned-mac-address=52:54:00:3C:9B:04
mac-address-blacklist=
mtu=1500

[ipv4]
dhcp-client-id=mac
dhcp-timeout=2147483647
dns-search=
method=auto

[ipv6]
addr-gen-mode=eui64
dhcp-duid=ll
dhcp-iaid=mac
dns-search=
method=disabled

[proxy]

临时应用改变

NMState 的一个有趣的功能允许你临时配置一个期望的网络状态。如果你对这个配置感到满意，你可以事后提交。否则，当超时（默认为 60 秒）过后，它将回滚。

修改前面例子中的 eth1 配置，使它有一个 IPv4 静态地址，而不是通过 DHCP 动态获得。

$ vi eth1.yaml

---
dns-resolver:
  config: {}
  running:
    search: []
    server:
    - 192.168.122.1
route-rules:
  config: []
routes:
  config: []
  running:
  - destination: fe80::/64
    metric: 101
    next-hop-address: ''
    next-hop-interface: eth1
    table-id: 254
  - destination: 0.0.0.0/0
    metric: 101
    next-hop-address: 192.168.122.1
    next-hop-interface: eth1
    table-id: 254
  - destination: 192.168.122.0/24
    metric: 101
    next-hop-address: ''
    next-hop-interface: eth1
    table-id: 254
interfaces:
- name: eth1
  type: ethernet
  state: up
  ipv4:
    enabled: true
    address:
    - ip: 192.168.122.110
      prefix-length: 24
    auto-dns: true
    auto-gateway: true
    auto-route-table-id: 0
    auto-routes: true
    dhcp: false
  ipv6:
    enabled: false
  lldp:
    enabled: false
  mac-address: 52:54:00:3C:9B:04
  mtu: 1500

现在，使用选项 no-commit 临时应用这个配置，让它只在 30 秒内有效。这可以通过添加选项 timeout 来完成。同时，我们将运行 ip -br a 命令三次，看看配置在 eth1 接口的 IPv4 地址是如何变化的，然后配置就会回滚。

$ ip -br a && sudo nmstatectl apply --no-commit --timeout 30 eth1.yaml && sleep 10 && ip -br a && sleep 25 && ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.238/24 fe80::5054:ff:fe91:e44e/64
eth1             UP             192.168.122.108/24
2021-06-29 17:29:18,266 root         DEBUG    Nmstate version: 1.0.3
2021-06-29 17:29:18,267 root         DEBUG    Applying desire state: {'dns-resolver': {'config': {}, 'running': {'search': [], 'server': ['192.168.122.1']}}, 'route-rules': {'config': []}, 'routes': {'config': [], 'running': [{'destination': 'fe80::/64', 'metric': 101, 'next-hop-address': '', 'next-hop-interface': 'eth1', 'table-id': 254}, {'destination': '0.0.0.0/0', 'metric': 101, 'next-hop-address': '192.168.122.1', 'next-hop-interface': 'eth1', 'table-id': 254}, {'destination': '192.168.122.0/24', 'metric': 101, 'next-hop-address': '', 'next-hop-interface': 'eth1', 'table-id': 254}]}, 'interfaces': [{'name': 'eth1', 'type': 'ethernet', 'state': 'up', 'ipv4': {'enabled': True, 'address': [{'ip': '192.168.122.110', 'prefix-length': 24}], 'dhcp': False}, 'ipv6': {'enabled': False}, 'lldp': {'enabled': False}, 'mac-address': '52:54:00:3C:9B:04', 'mtu': 1500}]}
--- output omitted ---
Desired state applied:
---
dns-resolver:
  config: {}
  running:
    search: []
    server:
    - 192.168.122.1
route-rules:
  config: []
routes:
  config: []
  running:
  - destination: fe80::/64
    metric: 101
    next-hop-address: ''
    next-hop-interface: eth1
    table-id: 254
  - destination: 0.0.0.0/0
    metric: 101
    next-hop-address: 192.168.122.1
    next-hop-interface: eth1
    table-id: 254
  - destination: 192.168.122.0/24
    metric: 101
    next-hop-address: ''
    next-hop-interface: eth1
    table-id: 254
interfaces:
- name: eth1
  type: ethernet
  state: up
  ipv4:
    enabled: true
    address:
    - ip: 192.168.122.110
      prefix-length: 24
    dhcp: false
  ipv6:
    enabled: false
  lldp:
    enabled: false
  mac-address: 52:54:00:3C:9B:04
  mtu: 1500
Checkpoint: NetworkManager|/org/freedesktop/NetworkManager/Checkpoint/7
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.238/24 fe80::5054:ff:fe91:e44e/64
eth1             UP             192.168.122.110/24
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.122.238/24 fe80::5054:ff:fe91:e44e/64
eth1             UP             192.168.122.108/24

从上面可以看到，eth1 的 IP 地址从 192.168.122.108 暂时变成了 192.168.122.110，然后在超时结束后又回到了 192.168.122.108。

总结

NMState 是一个声明式的网络配置工具，目前可以通过 NetworkManager API 在主机中应用所需的网络配置状态。这种状态既可以用文本编辑器交互式地定义，也可以用基于文件的方法创建一个 yaml 或 json 文件。

这种工具提供了“基础设施即代码”，它可以自动化网络任务，也减少了使用传统配置方法可能出现的潜在错误配置或不稳定的网络情况。

via: https://fedoramagazine.org/nmstate-a-declarative-networking-config-tool/

作者：Maurizio Garcia 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

昨天，Facebook 发生了由 BGP 引起的离线事故。我对学习更多关于 BGP 的知识已经隐约感兴趣了很长时间，所以我阅读了一些文章。

我感到很沮丧，因为没有一篇文章告诉我如何在我的电脑上实际查找与 BGP 有关的信息，因此我 写了一条询问有关工具的推特。

我一如既往地得到了一堆有用的回复，所以这篇博文展示了一些你可以用来查询 BGP 信息的工具。这篇文章中可能会有较多的错误，因为我对 BGP 不是很了解。

我不能发布 BGP 路由

我从来没有了解过 BGP 的原因之一是，据我所知，我没有在互联网上发布 BGP 路由的权限。

对于大多数网络协议，如果需要，你可以非常轻松地自己实现该协议。例如，你可以：

• 发行你自己的 TLS 证书
• 编写你自己的 HTTP 服务器
• 编写你自己的 TCP 实现
• 为你的域名编写你自己的权威 DNS 服务器（我现在正在为一个小项目尝试这样做）
• 建立你自己的证书机构（CA）

但是对于 BGP，我认为除非你拥有自己的 ASN，否则你不能自己发布路由（你可以在你的家庭网络上实现 BGP，但这对我来说有点无聊，当我做实验的时候，我希望它们真的在真正的互联网上）。

无论如何，尽管我不能用它做实验，但我仍然认为它超级有趣，因为我喜欢网络，所以我将向你展示我找到的一些用来学习 BGP 的工具。

首先我们来谈谈 BGP 的一些术语。我打算很快掠过，因为我对工具更感兴趣，而且网上有很多关于 BGP 的高水平解释（比如这篇 cloudflare 的文章）。

AS 是什么？

我们首先需要了解的是 AS（“ 自治系统 autonomous system ”）。每个 AS：

1. 由一个组织拥有（通常是一个大型组织，如你的 ISP、政府、大学、Facebook 等）。
2. 控制一组特定的 IP 地址（例如，我的 ISP 的 AS 包括 247,808 个 IP 地址）。
3. 有一个编号 ASN（如 1403）。

下面是我通过做一些实验对 AS 的一些观察：

• 一些相当大的科技公司并没有自己的 AS。例如，我在 BGPView 上查看了 Patreon，就我所知，他们没有自己的 AS，他们的主要网站（patreon.com，104.16.6.49）在 Cloudflare 的 AS 中。
• 一个 AS 可以包括许多国家的 IP。Facebook 的 AS（AS32934）肯定有新加坡、加拿大、尼日利亚、肯尼亚、美国和其他国家的 IP 地址。
• 似乎 IP 地址可以在一个以上的 AS 中。例如，如果我查找 209.216.230.240，它有 2 个 ASN 与之相关：AS6130 和 AS21581。显然，当这种情况发生时，更具体的路线会被优先考虑 —— 所以到该 IP 的数据包会被路由到 AS21581。

什么是 BGP 路由？

互联网上有很多的路由器。例如，我的 ISP 就有路由器。

当我给我的 ISP 发送一个数据包时（例如通过运行 ping 129.134.30.0），我的 ISP 的路由器需要弄清楚如何将我的数据包实际送到 IP 地址 129.134.30.0。

路由器计算的方法是，它有一个路由表：这是个有一堆 IP 地址范围的列表（比如 129.134.30.0/23），以及它知道的到达该子网的路由。

下面是一个 129.134.30.0/23 （Facebook 的一个子网）的真实路由的例子。这不是来自我的 ISP。

11670 32934
  206.108.35.2 from 206.108.35.254 (206.108.35.254)
    Origin IGP, metric 0, valid, external
    Community: 3856:55000
    Last update: Mon Oct  4 21:17:33 2021

我认为这是在说通往 129.134.30.0 的一条路径是通过机器 206.108.35.2，这是在它的本地网络上。所以路由器接下来可能会把我的 ping 包发送到 206.108.35.2，然后 206.108.35.2 会知道如何把它送到 Facebook。开头的两个数字（11670 32934）是 ASN。

BGP 是什么？

我对 BGP 的理解非常浅薄，它是一个公司用来公布 BGP 路由的协议。

昨天发生在 Facebook 身上的事情基本上是他们发布了一个 BGP 公告，撤销了他们所有的 BGP 路由，所以世界上的每个路由器都删除了所有与 Facebook 有关的路由，没有流量可以到达那里。

好了，现在我们已经涵盖了一些基本的术语，让我们来谈谈你可以用来查看 AS 和 BGP 的工具吧！

工具 1：用 BGPView 查看你的 ISP 的 AS

为了使 AS 这个东西不那么抽象，让我们用一个叫做 BGPView的 工具来看看一个真实的 AS。

我的 ISP（EBOX）拥有 AS 1403。这是 我的 ISP 拥有的 IP 地址。如果我查找我的计算机的公共 IPv4 地址，我可以看到它是我的 ISP 拥有的IP地址之一：它在 104.163.128.0/17 块中。

BGPView 也有这个图，显示了我的 ISP 与其他 AS 的连接情况。

工具 2：traceroute -A 和 mtr -z

好了，我们感兴趣的是 AS 。让我们看看我从哪些 AS 中穿过。

traceroute 和 mtr 都有选项可以告诉你每个 IP 的 ASN。其选项分别是 traceroute -A 和 mtr -z。

让我们看看我用 mtr 在去 facebook.com 的路上经过了哪些 AS！

$ mtr -z facebook.com
 1. AS???    LEDE.lan
 2. AS1403   104-163-190-1.qc.cable.ebox.net
 3. AS???    10.170.192.58
 4. AS1403   0.et-5-2-0.er1.mtl7.yul.ebox.ca
 5. AS1403   0.ae17.er2.mtl3.yul.ebox.ca
 6. AS1403   0.ae0.er1.151fw.yyz.ebox.ca
 7. AS???    facebook-a.ip4.torontointernetxchange.net
 8. AS32934  po103.psw01.yyz1.tfbnw.net
 9. AS32934  157.240.38.75
10. AS32934  edge-star-mini-shv-01-yyz1.facebook.com

这很有意思，看起来我们直接从我的 ISP 的 AS（1403）到 Facebook 的 AS（32934），中间有一个“互联网交换”。

我不确定 互联网交换 internet exchange （IX）是什么，但我知道它是互联网的一个极其重要的部分。不过这将是以后的事了。我猜是，它是互联网中实现“对等”的部分，就假设它是一个有巨大的交换机的机房，里面有无限的带宽，一堆不同的公司把他们的电脑放在里面，这样他们就可以互相发送数据包。

mtr 用 DNS 查找 ASN

我对 mtr 如何查找 ASN 感到好奇，所以我使用了 strace。我看到它看起来像是在使用 DNS，所以我运行了 dnspeep，然后就看到了！

$ sudo dnspeep
...
TXT   1.190.163.104.origin.asn.cymru.com 192.168.1.1          TXT: 1403 | 104.163.176.0/20 | CA | arin | 2014-08-14, TXT: 1403 | 104.163.160.0/19 | CA | arin | 2014-08-14, TXT: 1403 | 104.163.128.0/17 | CA | arin | 2014-08-14
...

所以，看起来我们可以通过查找 1.190.163.104.origin.asn.cymru.com 上的 txt 记录找到 104.163.190.1 的 ASN，像这样：

$ dig txt 1.190.163.104.origin.asn.cymru.com
1.190.163.104.origin.asn.cymru.com. 13911 IN TXT "1403 | 104.163.160.0/19 | CA | arin | 2014-08-14"
1.190.163.104.origin.asn.cymru.com. 13911 IN TXT "1403 | 104.163.128.0/17 | CA | arin | 2014-08-14"
1.190.163.104.origin.asn.cymru.com. 13911 IN TXT "1403 | 104.163.176.0/20 | CA | arin | 2014-08-14"

这很好！让我们继续前进吧。

工具 3：数据包交换所的观察镜

PCH（“ 数据包交换所 packet clearing house ”）是运行大量互联网交换点的组织。“ 观察镜 looking glass ”似乎是一个通用术语，指的是让你从另一个人的计算机上运行网络命令的 Web 表单。有一些观察镜不支持 BGP，但我只对那些能显示 BGP 路由信息的观察镜感兴趣。

这里是 PCH 的观察镜： https://www.pch.net/tools/looking_glass/ 。

在该网站的 Web 表单中，我选择了多伦多 IX（“TORIX”），因为 mtr 说我是用它来访问 facebook.com 的。

操作 1：显示 ip bgp 摘要

下面是输出结果。我修改了其中的一些内容：

IPv4 Unicast Summary:
BGP router identifier 74.80.118.4, local AS number 3856 vrf-id 0
BGP table version 33061919
RIB entries 513241, using 90 MiB of memory
Peers 147, using 3003 KiB of memory
Peer groups 8, using 512 bytes of memory

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
...
206.108.34.248  4       1403  484672  466938        0    0    0 05w3d03h           50
...
206.108.35.2    4      32934  482088  466714        0    0    0 01w6d07h           38
206.108.35.3    4      32934  482019  466475        0    0    0 01w0d06h           38
...

Total number of neighbors 147

我的理解是，多伦多 IX（“TORIX”）直接连接到我的 ISP （EBOX，AS 1403）和 Facebook（AS 32934）。

操作 2：显示 ip bgp 129.134.30.0

这是筛选自 show ip bgp 对 129.134.30.0（Facebook 的一个 IP 地址）的输出：

BGP routing table entry for 129.134.30.0/23
Paths: (4 available, best #4, table default)
  Advertised to non peer-group peers:
  206.220.231.55
  11670 32934
    206.108.35.2 from 206.108.35.254 (206.108.35.254)
      Origin IGP, metric 0, valid, external
      Community: 3856:55000
      Last update: Mon Oct  4 21:17:33 2021

  11670 32934
    206.108.35.2 from 206.108.35.253 (206.108.35.253)
      Origin IGP, metric 0, valid, external
      Community: 3856:55000
      Last update: Mon Oct  4 21:17:31 2021

  32934
    206.108.35.3 from 206.108.35.3 (157.240.58.225)
      Origin IGP, metric 0, valid, external, multipath
      Community: 3856:55000
      Last update: Mon Oct  4 21:17:27 2021

  32934
    206.108.35.2 from 206.108.35.2 (157.240.58.182)
      Origin IGP, metric 0, valid, external, multipath, best (Older Path)
      Community: 3856:55000
      Last update: Mon Oct  4 21:17:27 2021

这似乎是在说，从该 IX 到 Facebook 有 4 条路线。

魁北克 IX 似乎对 Facebook 一无所知。

我也试过从魁北克 IX（“QIX”，它可能离我更近，因为我住在蒙特利尔而不是多伦多）做同样的事情。但 QIX 似乎对 Facebook 一无所知：当我输入129.134.30.0 时，它只是说 “% 网络不在表中”。

所以我想这就是为什么我被送到多伦多 IX 而不是魁北克的 IX。

更多的 BGP 观察镜

这里还有一些带观察镜的网站，可以从其他角度给你类似的信息。它们似乎都支持相同的 show ip bgp 语法，也许是因为他们运行的是同一个软件？我不太确定。

• http://www.routeviews.org/routeviews/index.php/collectors/
• http://www.routeservers.org/
• https://lg.he.net/

似乎有很多这样的观察镜服务，远不止这 3 个列表。

这里有一个与这个列表上的一个服务器进行会话的例子：route-views.routeviews.org。这次我是通过 telnet 连接的，而不是通过 Web 表单，但输出的格式看起来是一样的。

$ telnet route-views.routeviews.org

route-views>show ip bgp 31.13.80.36

BGP routing table entry for 31.13.80.0/24, version 1053404087
Paths: (23 available, best #2, table default)
  Not advertised to any peer
  Refresh Epoch 1
  3267 1299 32934
    194.85.40.15 from 194.85.40.15 (185.141.126.1)
      Origin IGP, metric 0, localpref 100, valid, external
      path 7FE0C3340190 RPKI State valid
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  6939 32934
    64.71.137.241 from 64.71.137.241 (216.218.252.164)
      Origin IGP, localpref 100, valid, external, best
      path 7FE135DB6500 RPKI State valid
      rx pathid: 0, tx pathid: 0x0
  Refresh Epoch 1
  701 174 32934
    137.39.3.55 from 137.39.3.55 (137.39.3.55)
      Origin IGP, localpref 100, valid, external
      path 7FE1604D3AF0 RPKI State valid
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  20912 3257 1299 32934
    212.66.96.126 from 212.66.96.126 (212.66.96.126)
      Origin IGP, localpref 100, valid, external
      Community: 3257:8095 3257:30622 3257:50001 3257:53900 3257:53904 20912:65004
      path 7FE1195AF140 RPKI State valid
      rx pathid: 0, tx pathid: 0
  Refresh Epoch 1
  7660 2516 1299 32934
    203.181.248.168 from 203.181.248.168 (203.181.248.168)
      Origin IGP, localpref 100, valid, external
      Community: 2516:1030 7660:9001
      path 7FE0D195E7D0 RPKI State valid
      rx pathid: 0, tx pathid: 0

这里有几个路由的选择：

• 3267 1299 32934
• 6939 32934
• 701 174 32934
• 20912 3257 1299 32934
• 7660 2516 1299 32934

我想这些都有不止一个 AS 的原因是，31.13.80.36 是 Facebook 在多伦多的 IP 地址，所以这个服务器（可能在美国西海岸，我不确定）不能直接连接到它，它需要先到另一个 AS。所以所有的路由都有一个或多个 ASN。

最短的是 6939（“Hurricane Electric”），它是一个 “全球互联网骨干”。他们也有自己的 Hurricane Electric 观察镜 页面。

工具 4：BGPlay

到目前为止，所有其他的工具都只是向我们展示了 Facebook 路由的当前状态，其中一切正常，但这第四个工具让我们看到了这个 Facebook BGP 互联网灾难的历史。这是一个 GUI 工具，所以我将包括一堆屏幕截图。

该工具在 https://stat.ripe.net/special/bgplay。我输入了 IP 地址 129.134.30.12（Facebook 的一个 IP），如果你想一起试试。

首先，让我们看看一切出错之前的状态。我点击了在 10 月 4 日 13:11:28 的时间线，得到了这个结果：

我最初发现这很让人不知所措。发生了什么事？但后来有人在推特上指出，下一个要看的地方是点击 Facebook 灾难发生后的时间线（10 月 4 日 18 点 38 分）。

很明显，这张图有问题：所有的 BGP 路线都不见了！哦，不要！

顶部的文字显示了最后一条 Facebook BGP 路由的消失：

Type: W > withdrawal Involving: 129.134.30.0/24
Short description: The route 50869, 25091, 32934 has been withdrawn.
Date and time: 2021-10-04 16:02:33 Collected by: 20-91.206.53.12

如果我再点击“ 快进 fast forward ”按钮，我们看到 BGP 路由开始回来了。

第一个宣告的是 137409 32934。但我不认为这实际上是第一个宣布的，在同一秒内有很多路由宣告（在 2021-10-04 21:00:40），我认为 BGPlay 内部的排序是任意的。

如果我再次点击“ 快进 fast forward ”按钮，越来越多的路由开始回来，路由开始恢复正常。

我发现在 BGPlay 里看这个故障真的很有趣，尽管一开始界面很混乱。

也许了解一下 BGP 是很重要的？

我在这篇文章的开头说，你不能改变 BGP 路由，但后来我想起在 2016 年或 2017 年，有一个 Telia 路由问题，给我们的工作造成了一些小的网络问题。而当这种情况发生时，了解为什么你的客户无法到达你的网站其实是很有用的，即使它完全不受你控制。当时我不知道这些工具，但我希望能知道！

我认为对于大多数公司来说，应对由其他人的错误 BGP 路由造成的中断，你所能做的就是“什么都不做，等待它得到修复”，但能够\_自信地\_什么都不做是很好的。

一些发布 BGP 路由的方法

如果你想（作为一个业余爱好者）真正发布 BGP 路由，这里有一些评论中的链接：

• 获取你自己的 ASN 的指南
• dn42 似乎有一个 BGP 的实验场（它不在公共互联网上，但确实有其他人在上面，这似乎比自己在家里做 BGP 实验更有趣）

目前就这些了

我想还有很多 BGP 工具（比如 PCH 有一堆 路由数据的每日快照，看起来很有趣），但这篇文章已经很长了，而且我今天还有其他事情要做。

我对我作为一个普通人可以得到这么多关于 BGP 的信息感到惊讶，我一直认为它是一个“秘密的网络巫师”这样的东西，但显然有各种公共机器，任何人都可以直接 telnet 到它并用来查看路由表！没想到！

via: https://jvns.ca/blog/2021/10/05/tools-to-look-at-bgp-routes/

作者：Julia Evans 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在这篇文章中，我们将介绍 below：一个用于现代 Linux 系统的 Apache 2.0 许可的资源监视器。below 可以让你重放以前记录的数据。

背景

内核的主要职责之一是调度对资源的访问。有时这可能意味着分配物理内存，使多个进程可以共享同一主机。其他时候，它可能意味着确保 CPU 时间的公平分配。在这些场景里，内核提供了机制，而将策略留给了“别人”。近来，这个“别人”通常是 systemd 或 dockerd 这样的运行时。运行时接受来自调度器或最终用户的输入（类似于运行什么和如何运行）并在内核上转动正确的旋钮和拉动正确的杠杆，从而使工作负载能够好好工作。

在一个完美的世界里，故事就到此结束了。然而，现实情况是，资源管理是一个复杂的、相当不透明的技术混合体，在几十年里计算技术不断发展。尽管其中一些技术有各种缺陷和死角，但最终的结果是，容器运作得比较好。虽然用户通常不需要关心这些细节，但对于基础设施运营商来说，对他们的技术架构拥有可见性是至关重要的。可见性和可调试性对于检测和调查错误的配置、问题和系统性故障至关重要。

让事情变得更加复杂的是，资源中断往往难以重现。经常需要花费数周时间等待一个问题重新出现，以便调查其根本原因。规模的扩大进一步加剧了这个问题：我们不能在每台主机上运行一个自定义脚本，希望在错误再次发生时记录下关键状态的片段。因此，需要更复杂的工具。这就出现了 below。

动机

历史上，Facebook 一直是 atop 的忠实用户。atop 是一个用于 Linux 的性能监视器，能够报告所有进程的活动以及各种系统级活动。与 htop 等工具相比，atop 最引人注目的功能之一是能够作为一个守护程序记录历史数据。这听起来是一个简单的功能，但在实践中，这使得调试无数的生产问题成为可能。有了足够长的数据保留，就有可能在时间上回溯，查看在问题或故障发生之前、期间和之后的主机状态。

不幸的是，随着时间的推移，人们发现atop 有某些不足之处。首先， 控制组 cgroup 已经成为控制和监视 Linux 机器上资源的实际方式。atop 仍然缺乏对这一基本构建模块的支持。第二，atop 用自定义的 delta 压缩方法在磁盘上存储数据。这在正常情况下运行良好，但在沉重的资源压力下，主机很可能会丢失数据点。由于使用了 delta 压缩，在数据最重要的时间段内，数据可能会大面积丢失。第三，用户体验有一个陡峭的学习曲线。我们经常听到 atop 的资深用户说，他们喜欢密集的布局和众多的键盘绑定。然而，这也是一把双刃剑。当一个刚进入这个领域的人想要调试一个生产问题时，他们现在要同时解决两个问题：手头的问题和如何使用 atop。

below 是由 Facebook 的资源控制团队为其设计和开发的，并得到了 atop 生产环境用户的支持。顾名思义，资源控制团队负责的是规模化的资源管理。该团队由内核开发人员、容器运行时开发人员和硬件人员组成。认识到下一代系统监控器的机会，我们在设计 below 时考虑到以下几点：

• 易用性：below 必须既能为新用户提供直观的体验，又能为日常用户提供强大的功能。 *有意义的统计数据：below 显示准确和有用的统计数据。即便可以，但我们尽量避免收集和倾倒统计数字。
• 灵活性：当默认设置不合适时，我们允许用户自定义他们的体验。例如包括可配置的键绑定、可配置的默认视图，以及脚本界面（默认为终端用户接口）。

安装

安装该软件包：

# dnf install -y below

打开记录守护进程：

# systemctl enable --now below

快速介绍

below 最常用的模式是重放模式。顾名思义，重放模式是重放以前记录的数据。假设你已经启动了记录守护程序，那么通过运行以下程序启动一个会话：

$ below replay --time "5 minutes ago"

然后你会看到控制组视图：

如果你不知道该怎么操作，或者忘记了一个键位，按 ? 可以进入帮助菜单。

屏幕的最上方是状态栏。状态栏显示关于当前样本的信息。你可以通过按 t 和 T 分别向前和向后移动样本。中间的部分是系统概览。系统概览包含了关于整个系统的统计数据，一般来说，这些数据总是很有用的。第三部分也是最下面的部分是多用途视图。上面的图片显示了控制组视图。此外，还有进程和系统视图，分别通过按 p 和s 来访问。

按 ↑ 和 ↓ 来移动列表选择。按回车键来折叠和展开控制组。假设你发现了一个感兴趣的控制组，你想看看它里面有哪些进程在运行。要放大进程视图，选择控制组并按 z：

再按 z 返回到控制组视图。这个视图有时会有点长。如果你对你要找的东西有一个模糊的概念，你可以通过按 / 并输入一个过滤器来过滤控制组名称。

在这一点上，你可能已经注意到了一个我们还没有探索过的标签系统。要在标签中向前和向后循环，可以分别按 Tab 和 Shift + Tab。我们把这个问题留给读者去做练习。

其他功能

在底层，below 有一个强大的设计和架构。Facebook 正在不断升级到更新的内核，所以我们从不假设数据源是可用的。这种默契的假设使得内核和 below版本之间能够完全向前和向后兼容。此外，每个数据点都用 zstd 压缩并完整地存储。这解决了我们看到的 atop 在大规模时的 delta 压缩问题。根据我们的测试，我们的每个样本压缩可以达到平均 5 倍的压缩率。

below 也使用 eBPF 来收集关于短暂进程（生存时间短于数据收集间隔的进程）的信息。相比之下，atop 使用 BSD 进程核算来实现这一功能，这是一个已知缓慢且容易发生优先级转换的内核接口。

对于用户来说，below 还支持实时模式和一个转储接口。实时模式将记录守护程序和 TUI 会话合并到一个进程中。这对于浏览系统状态是很方便的，不需要为数据存储投入长期运行的守护程序或磁盘空间。转储接口是一个可编写脚本的接口，用于所有的 below 数据存储。转储既强大又灵活，详细的数据以 CSV、JSON 和人类可读格式提供。

总结

below 是一个 Apache 2.0 许可的开源项目，我们（below 的开发者）认为它比资源监控领域的现有工具具有引人注目的优势。我们已经花了大量的精力来准备 below，以提供开源使用，所以我们希望读者和社区有机会尝试 below，并报告错误和功能要求。

via: https://fedoramagazine.org/below-a-time-traveling-resource-monitor/

作者：Daniel Xu 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

GitHub Actions 是一项为快速建立持续集成和交付（CI/CD）工作流程而提供的服务。这些工作流程在被称为“ 运行器 runner ”的主机上运行。GitHub 提供的 托管运行器 的操作系统的选择是有限的（Windows Server、Ubuntu、MacOS）。

另一个选择是使用 自托管 的运行器，这让仓库管理员对运行器有更多控制。自托管的运行程序是专门为某个存储库或组织服务的。下面的文章介绍了使用 Fedora CoreOS 配置自托管运行程序的步骤。

入门

Fedora CoreOS 是一个精简的操作系统，旨在便于大规模的部署和维护。该操作系统会自动更新，并默认提供运行容器所需的工具。由于这些原因，Fedora CoreOS 是运行 CI/CD 工作流程的一个极佳选择。

配置和配备 Fedora CoreOS 机器的第一步是生成一个 Ignition 文件。Butane 允许你使用更友好的格式（YAML）生成 Ignition 文件。

配置一个 Fedora CoreOS 运行器

要在 Fedora CoreOS 上执行 GitHub Actions，托管主机需要用于注册和运行该运行器的二进制文件和脚本。从 Actions 运行器项目 下载二进制文件和脚本，并部署在 /usr/local/sbin/actions-runner 下。

version: "1.3.0"
variant: fcos
storage:
  directories:
    - path: /usr/local/sbin/actions-runner
      mode: 0755
      user:
        name: core
      group:
        name: core
  files:
    - path: /usr/local/sbin/actions-runner/actions-runner-linux.tar.gz
      overwrite: true
      contents:
        source: https://github.com/actions/runner/releases/download/v2.278.0/actions-runner-linux-x64-2.278.0.tar.gz
      mode: 0755
      user:
        name: core
      group:
        name: core

注册和删除令牌

为一个项目配置运行器需要一个“ 令牌 token ”。这可以防止在没有正确权限的情况下从项目中注册或删除自托管的运行器。GitHub 提供的令牌有一个小时的过期时间。如果运行器在这个时间之后重新启动，它将需要一个新的注册令牌。

该令牌可能出问题，特别是在 Fedora CoreOS 自动更新时。更新过程希望托管主机在收到新数据后至少每隔几周重启一次。

幸运的是，可以使用 GitHub REST API 来获取这些令牌，并在托管主机每次重启时自动配置运行器。下面的 manage-runner.sh 脚本使用 API 来获取令牌，删除任何已经配置好的运行器，并用新的令牌注册运行器。

#!/bin/bash
# Handles the Github Action runner configuration.
# Remove and Registration token expires after 1 hour, if we want our runner
# to work after a reboot (auto update) we need to refresh the tokens.

# First remove the runner with a fresh remove token
REMOVE_TOKEN=$(curl -u ${GITHUB_USER}:${GITHUB_TOKEN} -X POST -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/${GITHUB_USER}/${GITHUB_REPO}/actions/runners/remove-token | jq -r '.token')
/usr/local/sbin/actions-runner/config.sh remove --token ${REMOVE_TOKEN}


# Then register the runner with a fresh registration token
REGISTRATION_TOKEN=$(curl -u ${GITHUB_USER}:${GITHUB_TOKEN} -X POST -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/${GITHUB_USER}/${GITHUB_REPO}/actions/runners/registration-token | jq -r '.token')
/usr/local/sbin/actions-runner/config.sh --url https://github.com/cverna/fcos-actions-runner --token ${REGISTRATION_TOKEN} --labels fcos --unattended

上面的脚本使用了一些环境变量，包含 GitHub 用户名和用于验证 REST API 请求的 个人访问令牌 Personal Access Token 。个人访问令牌需要存储库权限，以便成功检索运行器的注册和移除令牌。该令牌是安全敏感信息，所以最好将其存储在一个具有更严格权限的不同文件中。在这个例子中，这个文件是 actions-runner。

GITHUB_USER=<user>
GITHUB_REPO=<repo>
GITHUB_TOKEN=<personal_access_token>

以下是创建这两个文件 manage-runner.sh 和 actions-runner 的 Butane 片段。

- path: /usr/local/sbin/actions-runner/manage-runner.sh
      contents:
        local: manage-runner.sh
      mode: 0755
      user:
        name: core
      group:
        name: core
    - path: /etc/actions-runner
      contents:
        local: actions-runner
      mode: 0700
      user:
        name: core
      group:
        name: core

在 Fedora CoreOS 上运行 Actions

最后，创建用于配置和启动运行器的 systemd 服务。在 Butane 配置文件中定义这些服务。

systemd:
  units:
    - name: github-runner-configure.service
      enabled: true
      contents: |
        [Unit]
        Description=Configure the github action runner for a repository
        After=network-online.target boot-complete.target
        Requires=boot-complete.target
        [Service]
        EnvironmentFile=/etc/actions-runner
        Type=oneshot
        RemainAfterExit=yes
        User=core
        WorkingDirectory=/usr/local/sbin/actions-runner
        ExecStartPre=tar xvf actions-runner-linux.tar.gz --no-same-owner
        ExecStart=/usr/local/sbin/actions-runner/manage-runner.sh
        [Install]
        WantedBy=multi-user.target
    - name: github-runner.service
      enabled: true
      contents: |
        [Unit]
        Description=Run the github action runner
        After=github-runner-configure.service
        [Service]
        WorkingDirectory=/usr/local/sbin/actions-runner
        User=core
        ExecStart=/usr/local/sbin/actions-runner/run.sh
        [Install]
        WantedBy=multi-user.target

这将创建两个服务：github-runner-configure.service（在主机启动完成后运行一次）和 github-runner.service（运行 Actions 运行器二进制文件并等待新的 CI/CD 作业）。

现在 Butane 配置已经完成，从中生成一个 Ignition 文件并配备一个 Fedora CoreOS Actions 运行器。

$ podman run -i --rm -v $PWD:/code:z --workdir /code quay.io/coreos/butane:release --pretty --strict --files-dir /code config.yaml -o config.ignition

一旦 Ignition 文件生成，它就可以用来在 支持 Fedora CoreOS 的平台上配备一个运行器。

配置一个 Action 来使用一个自托管的运行器

下面的测试 Action 工作流程将测试 FCOS 的自托管的运行器。在你的 git 存储库中创建以下文件 .github/workflows/main.yml。

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run.
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: fcos

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: podman run --rm fedora-minimal:34 echo Hello World !

请注意，runs-on 的配置被设置为使用标签为 fcos 的运行器。

本文介绍的代码可以在 这里 中找到。

via: https://fedoramagazine.org/run-github-actions-on-fedora-coreos/

作者：Clément Verna 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出