分类 系统运维 下的文章

定时器提供了比 cron 作业更为细粒度的事件控制。

 title=

我正在致力于将我的 cron 作业迁移到 systemd 定时器上。我已经使用定时器多年了,但通常来说,我的学识只足以支撑我当前的工作。但在我研究 systemd 系列 的过程中,我发现 systemd 定时器有一些非常有意思的能力。

与 cron 作业类似,systemd 定时器可以在特定的时间间隔触发事件(shell 脚本和程序),例如每天一次或在一个月中的特定某一天(或许只有在周一生效),或在从上午 8 点到下午 6 点的工作时间内每隔 15 分钟一次。定时器也可以做到 cron 作业无法做到的一些事情。举个例子,定时器可以在特定事件发生后的一段时间后触发一段脚本或者程序去执行,例如开机、启动、上个任务完成,甚至于定时器调用的上个服务单元的完成的时刻。

操作系统维护的计时器

当在一个新系统上安装 Fedora 或者是任意一个基于 systemd 的发行版时,作为系统维护过程的一部分,它会在 Linux 宿主机的后台中创建多个定时器。这些定时器会触发事件来执行必要的日常维护任务,比如更新系统数据库、清理临时目录、轮换日志文件,以及更多其他事件。

作为示例,我会查看一些我的主要工作站上的定时器,通过执行 systemctl status *timer 命令来展示主机上的所有定时器。星号的作用与文件通配相同,所以这个命令会列出所有的 systemd 定时器单元。

[root@testvm1 ~]# systemctl status *timer
● mlocate-updatedb.timer - Updates mlocate database every day
     Loaded: loaded (/usr/lib/systemd/system/mlocate-updatedb.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● mlocate-updatedb.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Updates mlocate database every day.

● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily rotation of log files.

● sysstat-summary.timer - Generate summary of yesterday's process accounting
     Loaded: loaded (/usr/lib/systemd/system/sysstat-summary.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:07:00 EDT; 15h left
   Triggers: ● sysstat-summary.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Generate summary of yesterday's process accounting.

● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Mon 2020-06-08 00:00:00 EDT; 3 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Discard unused blocks once a week.

● sysstat-collect.timer - Run system activity accounting tool every 10 minutes
     Loaded: loaded (/usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:50:00 EDT; 41s left
   Triggers: ● sysstat-collect.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Run system activity accounting tool every 10 minutes.

● dnf-makecache.timer - dnf makecache --timer
     Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:51:00 EDT; 1min 41s left
   Triggers: ● dnf-makecache.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started dnf makecache –timer.

● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
     Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 08:19:00 EDT; 23h left
   Triggers: ● systemd-tmpfiles-clean.service
       Docs: man:tmpfiles.d(5)
             man:systemd-tmpfiles(8)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily Cleanup of Temporary Directories.

每个定时器至少有六行相关信息:

  • 定时器的第一行有定时器名字和定时器目的的简短介绍
  • 第二行展示了定时器的状态,是否已加载,定时器单元文件的完整路径以及预设信息。
  • 第三行指明了其活动状态,包括该定时器激活的日期和时间。
  • 第四行包括了该定时器下次被触发的日期和时间和距离触发的大概时间。
  • 第五行展示了被定时器触发的事件或服务名称。
  • 部分(不是全部)systemd 单元文件有相关文档的指引。我虚拟机上输出中有三个定时器有文档指引。这是一个很好(但非必要)的信息。
  • 最后一行是计时器最近触发的服务实例的日志条目。

你也许有一些不一样的定时器,取决于你的主机。

创建一个定时器

尽管我们可以解构一个或多个现有的计时器来了解其工作原理,但让我们创建我们自己的 服务单元 和一个定时器去触发它。为了保持简单,我们将使用一个相当简单的例子。当我们完成这个实验之后,就能更容易理解其他定时器的工作原理以及发现它们正在做什么。

首先,创建一个运行基础东西的简单的服务,例如 free 命令。举个例子,你可能想定时监控空余内存。在 /etc/systemd/system 目录下创建如下的 myMonitor.server 单元文件。它不需要是可执行文件:

# This service unit is for testing timer units
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs system statistics to the systemd journal
Wants=myMonitor.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/free

[Install]
WantedBy=multi-user.target

这大概是你能创建的最简单的服务单元了。现在我们查看一下服务状态同时测试一下服务单元确保它和我们预期一样可用。

[root@testvm1 system]# systemctl status myMonitor.service
● myMonitor.service - Logs system statistics to the systemd journal
     Loaded: loaded (/etc/systemd/system/myMonitor.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
[root@testvm1 system]# systemctl start myMonitor.service
[root@testvm1 system]#

输出在哪里呢?默认情况下,systemd 服务单元执行程序的标准输出(STDOUT)会被发送到系统日志中,它保留了记录供现在或者之后(直到某个时间点)查看。(在本系列的后续文章中,我将介绍系统日志的记录和保留策略)。专门查看你的服务单元的日志,而且只针对今天。-S 选项,即 --since 的缩写,允许你指定 journalctl 工具搜索条目的时间段。这并不代表你不关心过往结果 —— 在这个案例中,不会有过往记录 —— 如果你的机器以及运行了很长时间且堆积了大量的日志,它可以缩短搜索时间。

[root@testvm1 system]# journalctl -S today -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Thu 2020-06-11 09:40:47 EDT. --
Jun 11 09:12:09 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 09:12:09 testvm1.both.org free[377966]:               total        used        free      shared  buff/cache   available
Jun 11 09:12:09 testvm1.both.org free[377966]: Mem:       12635740      522868    11032860        8016     1080012    11821508
Jun 11 09:12:09 testvm1.both.org free[377966]: Swap:       8388604           0     8388604
Jun 11 09:12:09 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
[root@testvm1 system]#

由服务触发的任务可以是单个程序、一组程序或者是一个脚本语言写的脚本。通过在 myMonitor.service 单元文件里的 [Service] 块末尾中添加如下行可以为服务添加另一个任务:

ExecStart=/usr/bin/lsblk

再次启动服务,查看日志检查结果,结果应该看上去像这样。你应该在日志中看到两条命令的结果输出:

Jun 11 15:42:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 15:42:18 testvm1.both.org free[379961]:               total        used        free      shared  buff/cache   available
Jun 11 15:42:18 testvm1.both.org free[379961]: Mem:       12635740      531788    11019540        8024     1084412    11812272
Jun 11 15:42:18 testvm1.both.org free[379961]: Swap:       8388604           0     8388604
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sda             8:0    0  120G  0 disk
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─sda1          8:1    0    4G  0 part /boot
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: └─sda2          8:2    0  116G  0 part
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sr0            11:0    1 1024M  0 rom
Jun 11 15:42:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 11 15:42:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.

现在你知道了你的服务可以按预期工作了,在 /etc/systemd/system 目录下创建 myMonitor.timer 定时器单元文件,添加如下代码:

# This timer unit is for testing
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs some system statistics to the systemd journal
Requires=myMonitor.service

[Timer]
Unit=myMonitor.service
OnCalendar=*-*-* *:*:00

[Install]
WantedBy=timers.target

myMonitor.timer 文件中的 OnCalendar 时间格式,*-*-* *:*:00,应该会每分钟触发一次定时器去执行 myMonitor.service 单元。我会在文章的后面进一步探索 OnCalendar 设置。

到目前为止,在服务被计时器触发运行时观察与之有关的日志记录。你也可以跟踪计时器,跟踪服务可以让你接近实时的看到结果。执行 journalctl 时带上 -f 选项:

[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --

执行但是不启用该定时器,看看它运行一段时间后发生了什么:

[root@testvm1 ~]# systemctl start myMonitor.service
[root@testvm1 ~]#

一条结果立即就显示出来了,下一条大概在一分钟后出来。观察几分钟日志,看看你有没有跟我发现同样的事情:

[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Jun 13 08:39:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:39:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:39:19 testvm1.both.org free[630566]:               total        used        free      shared  buff/cache   available
Jun 13 08:39:19 testvm1.both.org free[630566]: Mem:       12635740      556604    10965516        8036     1113620    11785628
Jun 13 08:39:19 testvm1.both.org free[630566]: Swap:       8388604           0     8388604
Jun 13 08:39:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sda             8:0    0  120G  0 disk
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: └─sda2          8:2    0  116G  0 part
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:40:46 testvm1.both.org free[630572]:               total        used        free      shared  buff/cache   available
Jun 13 08:40:46 testvm1.both.org free[630572]: Mem:       12635740      555228    10966836        8036     1113676    11786996
Jun 13 08:40:46 testvm1.both.org free[630572]: Swap:       8388604           0     8388604
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sda             8:0    0  120G  0 disk
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: └─sda2          8:2    0  116G  0 part
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:40:46 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:41:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:41:46 testvm1.both.org free[630580]:               total        used        free      shared  buff/cache   available
Jun 13 08:41:46 testvm1.both.org free[630580]: Mem:       12635740      553488    10968564        8036     1113688    11788744
Jun 13 08:41:46 testvm1.both.org free[630580]: Swap:       8388604           0     8388604
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sda             8:0    0  120G  0 disk
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: └─sda2          8:2    0  116G  0 part
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sr0            11:0    1 1024M  0 rom
Jun 13 08:41:47 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:41:47 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.

别忘了检查下计时器和服务的状态。

你在日志里大概至少注意到两件事。第一,你不需要特地做什么来让 myMonitor.service 单元中 ExecStart 触发器产生的 STDOUT 存储到日志里。这都是用 systemd 来运行服务的一部分功能。然而,它确实意味着你需要小心对待服务单元里面执行的脚本和它们能产生多少 STDOUT

第二,定时器并不是精确在每分钟的 :00 秒执行的,甚至每次执行的时间间隔都不是刚好一分钟。这是特意的设计,但是有必要的话可以改变这种行为(如果只是它挑战了你的系统管理员的敏感神经)。

这样设计的初衷是为了防止多个服务在完全相同的时刻被触发。举个例子,你可以用例如 Weekly,Daily 等时间格式。这些快捷写法都被定义为在某一天的 00:00:00 执行。当多个定时器都这样定义的话,有很大可能它们会同时执行。

systemd 定时器被故意设计成在规定时间附近随机波动的时间点触发,以避免同一时间触发。它们在一个时间窗口内半随机触发,时间窗口开始于预设的触发时间,结束于预设时间后一分钟。根据 systemd.timer 的手册页,这个触发时间相对于其他已经定义的定时器单元保持在稳定的位置。你可以在日志条目中看到,定时器在启动后立即触发,然后在每分钟后的 46 或 47 秒触发。

大部分情况下,这种概率抖动的定时器是没事的。当调度类似执行备份的任务,只需要它们在下班时间运行,这样是没问题的。系统管理员可以选择确定的开始时间来确保不和其他任务冲突,例如 01:05:00 这样典型的 cron 作业时间,但是有很大范围的时间值可以满足这一点。在开始时间上的一个分钟级别的随机往往是无关紧要的。

然而,对某些任务来说,精确的触发时间是个硬性要求。对于这类任务,你可以向单元文件的 Timer 块中添加如下声明来指定更高的触发时间跨度精确度(精确到微秒以内):

AccuracySec=1us

时间跨度可用于指定所需的精度,以及定义重复事件或一次性事件的时间跨度。它能识别以下单位:

  • usecusµs
  • msecms
  • secondssecondsecs
  • minutesminuteminm
  • hourshourhrh
  • daysdayd
  • weeksweekw
  • monthsmonthM(定义为 30.44 天)
  • yearsyeary(定义为 365.25 天)

所有 /usr/lib/systemd/system 中的定时器都指定了一个更宽松的时间精度,因为精准时间没那么重要。看看这些系统创建的定时器的时间格式:

[root@testvm1 system]# grep Accur /usr/lib/systemd/system/*timer
/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h
/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h
/usr/lib/systemd/system/logwatch.timer:AccuracySec=12h
/usr/lib/systemd/system/mlocate-updatedb.timer:AccuracySec=24h
/usr/lib/systemd/system/raid-check.timer:AccuracySec=24h
/usr/lib/systemd/system/unbound-anchor.timer:AccuracySec=24h
[root@testvm1 system]#

看下 /usr/lib/systemd/system 目录下部分定时器单元文件的完整内容,看看它们是如何构建的。

在本实验中不必让这个定时器在启动时激活,但下面这个命令可以设置开机自启:

[root@testvm1 system]# systemctl enable myMonitor.timer

你创建的单元文件不需要是可执行的。你同样不需要启用服务,因为它是被定时器触发的。如果你需要的话,你仍然可以在命令行里手动触发该服务单元。尝试一下,然后观察日志。

关于定时器精度、事件时间规格和触发事件的详细信息,请参见 systemd.timer 和 systemd.time 的手册页。

定时器类型

systemd 定时器还有一些在 cron 中找不到的功能,cron 只在确定的、重复的、具体的日期和时间触发。systemd 定时器可以被配置成根据其他 systemd 单元状态发生改变时触发。举个例子,定时器可以配置成在系统开机、启动后,或是某个确定的服务单元激活之后的一段时间被触发。这些被称为单调计时器。“单调”指的是一个持续增长的计数器或序列。这些定时器不是持久的,因为它们在每次启动后都会重置。

表格 1 列出了一些单调定时器以及每个定时器的简短定义,同时有 OnCalendar 定时器,这些不是单调的,它们被用于指定未来有可能重复的某个确定时间。这个信息来自于 systemd.timer 的手册页,有一些不重要的修改。

定时器单调性定义
OnActiveSec=X定义了一个与定时器被激活的那一刻相关的定时器。
OnBootSec=X定义了一个与机器启动时间相关的计时器。
OnStartupSec=X定义了一个与服务管理器首次启动相关的计时器。对于系统定时器来说,这个定时器与 OnBootSec= 类似,因为系统服务管理器在机器启动后很短的时间后就会启动。当以在每个用户服务管理器中运行的单元进行配置时,它尤其有用,因为用户的服务管理器通常在首次登录后启动,而不是机器启动后。
OnUnitActiveSec=X定义了一个与将要激活的定时器上次激活时间相关的定时器。
OnUnitInactiveSec=X定义了一个与将要激活的定时器上次停用时间相关的定时器。
OnCalendar= 定义了一个有日期事件表达式语法的实时(即时钟)定时器。查看 systemd.time(7) 的手册页获取更多与日历事件表达式相关的语法信息。除此以外,它的语义和 OnActiveSec= 类似。

Table 1: systemd 定时器定义

单调计时器可使用同样的简写名作为它们的时间跨度,即我们之前提到的 AccuracySec 表达式,但是 systemd 将这些名字统一转换成了秒。举个例子,比如你想规定某个定时器在系统启动后五天触发一次事件;它可能看起来像 OnBootSec=5d。如果机器启动于 2020-06-15 09:45:27,这个定时器会在 2020-06-20 09:45:27 或在这之后的一分钟内触发。

日历事件格式

日历事件格式是定时器在所需的重复时间触发的关键。我们开始看下一些 OnCalendar 设置一起使用的格式。

与 crontab 中的格式相比,systemd 及其计时器使用的时间和日历格式风格不同。它比 crontab 更为灵活,而且可以使用类似 at 命令的方式允许模糊的日期和时间。它还应该足够熟悉使其易于理解。

systemd 定时器使用 OnCalendar= 的基础格式是 DOW YYYY-MM-DD HH:MM:SS。DOW(星期几)是选填的,其他字段可以用一个星号(*)来匹配此位置的任意值。所有的日历时间格式会被转换成标准格式。如果时间没有指定,它会被设置为 00:00:00。如果日期没有指定但是时间指定了,那么下次匹配的时间可能是今天或者明天,取决于当前的时间。月份和星期可以使用名称或数字。每个单元都可以使用逗号分隔的列表。单元范围可以在开始值和结束值之间用 .. 指定。

指定日期有一些有趣的选项,波浪号(~)可以指定月份的最后一天或者最后一天之前的某几天。/ 可以用来指定星期几作为修饰符。

这里有几个在 OnCalendar 表达式中使用的典型时间格式例子。

日期事件格式描述
DOW YYYY-MM-DD HH:MM:SS
*-*-* 00:15:30每年每月每天的 0 点 15 分 30 秒
Weekly每个周一的 00:00:00
Mon *-*-* 00:00:00同上
Mon同上
Wed 2020-*-*2020 年每个周三的 00:00:00
Mon..Fri 2021-*-*2021 年的每个工作日(周一到周五)的 00:00:00
2022-6,7,8-1,15 01:15:002022 年 6、7、8 月的 1 到 15 号的 01:15:00
Mon *-05~03每年五月份的下个周一同时也是月末的倒数第三天
Mon..Fri *-08~04任何年份 8 月末的倒数第四天,同时也须是工作日
*-05~03/2五月末的倒数第三天,然后 2 天后再来一次。每年重复一次。注意这个表达式使用了波浪号(~)。
*-05-03/2五月的第三天,然后每两天重复一次直到 5 月底。注意这个表达式使用了破折号(-)。

Table 2: OnCalendar 事件时间格式例子

测试日历格式

systemd 提供了一个绝佳的工具用于检测和测试定时器中日历时间事件的格式。systemd-analyze calendar 工具解析一个时间事件格式,提供标准格式和其他有趣的信息,例如下次“经过”(即匹配)的日期和时间,以及距离下次触发之前大概时间。

首先,看看未来没有时间的日(注意 Next elapseUTC 的时间会根据你当地时区改变):

[student@studentvm1 ~]$ systemd-analyze calendar 2030-06-17
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

现在添加一个时间,在这个例子中,日期和时间是当作无关的部分分开解析的:

[root@testvm1 system]# systemd-analyze calendar 2030-06-17 15:21:16
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    

  Original form: 15:21:16                  
Normalized form: *-*-* 15:21:16            
    Next elapse: Mon 2020-06-15 15:21:16 EDT
       (in UTC): Mon 2020-06-15 19:21:16 UTC
       From now: 3h 55min left              
[root@testvm1 system]#

为了把日期和时间当作一个单元来分析,可以把它们包在引号里。你在定时器单元里 OnCalendar= 时间格式中使用的时候记得把引号去掉,否则会报错:

[root@testvm1 system]# systemd-analyze calendar "2030-06-17 15:21:16"
Normalized form: 2030-06-17 15:21:16        
    Next elapse: Mon 2030-06-17 15:21:16 EDT
       (in UTC): Mon 2030-06-17 19:21:16 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

现在我们测试下 Table2 里的例子。我尤其喜欢最后一个:

[root@testvm1 system]# systemd-analyze calendar "2022-6,7,8-1,15 01:15:00"
  Original form: 2022-6,7,8-1,15 01:15:00
Normalized form: 2022-06,07,08-01,15 01:15:00
    Next elapse: Wed 2022-06-01 01:15:00 EDT
       (in UTC): Wed 2022-06-01 05:15:00 UTC
       From now: 1 years 11 months left
[root@testvm1 system]#

让我们看一个例子,这个例子里我们列出了时间表达式的五个经过时间。

[root@testvm1 ~]# systemd-analyze calendar --iterations=5 "Mon *-05~3"
  Original form: Mon *-05~3                
Normalized form: Mon *-05~03 00:00:00      
    Next elapse: Mon 2023-05-29 00:00:00 EDT
       (in UTC): Mon 2023-05-29 04:00:00 UTC
       From now: 2 years 11 months left    
       Iter. #2: Mon 2028-05-29 00:00:00 EDT
       (in UTC): Mon 2028-05-29 04:00:00 UTC
       From now: 7 years 11 months left    
       Iter. #3: Mon 2034-05-29 00:00:00 EDT
       (in UTC): Mon 2034-05-29 04:00:00 UTC
       From now: 13 years 11 months left    
       Iter. #4: Mon 2045-05-29 00:00:00 EDT
       (in UTC): Mon 2045-05-29 04:00:00 UTC
       From now: 24 years 11 months left    
       Iter. #5: Mon 2051-05-29 00:00:00 EDT
       (in UTC): Mon 2051-05-29 04:00:00 UTC
       From now: 30 years 11 months left    
[root@testvm1 ~]#

这些应该为你提供了足够的信息去开始测试你的 OnCalendar 时间格式。systemd-analyze 工具可用于其他有趣的分析,我会在这个系列的下一篇文章来探索这些。

总结

systemd 定时器可以用于执行和 cron 工具相同的任务,但是通过按照日历和单调时间格式去触发事件的方法提供了更多的灵活性。

虽然你为此次实验创建的服务单元通常是由定时器调用的,你也可以随时使用 systemctl start myMonitor.service 命令去触发它。可以在一个定时器中编写多个维护任务的脚本;它们可以是 Bash 脚本或者其他 Linux 程序。你可以通过触发定时器来运行所有的脚本来运行服务,也可以按照需要执行单独的脚本。

我会在下篇文章中更加深入的探索 systemd 时间格式的用处。

我还没有看到任何迹象表明 cron 和 at 将被废弃。我希望这种情况不会发生,因为至少 at 在执行一次性调度任务的时候要比 systemd 定时器容易的多。

参考资料

网上有大量的关于 systemd 的参考资料,但是大部分都有点简略、晦涩甚至有误导性。除了本文中提到的资料,下列的网页提供了跟多可靠且详细的 systemd 入门信息。

  • Fedora 项目有一篇切实好用的 systemd 入门,它囊括了几乎所有你需要知道的关于如何使用 systemd 配置、管理和维护 Fedora 计算机的信息。
  • Fedora 项目也有一个不错的 备忘录,交叉引用了过去 SystemV 命令和 systemd 命令做对比。
  • 关于 systemd 的技术细节和创建这个项目的原因,请查看 Freedesktop.org 上的 systemd 描述
  • Linux.com 的“更多 systemd 的乐趣”栏目提供了更多高级的 systemd 信息和技巧

此外,还有一系列深度的技术文章,是由 systemd 的设计者和主要实现者 Lennart Poettering 为 Linux 系统管理员撰写的。这些文章写于 2010 年 4 月至 2011 年 9 月间,但它们现在和当时一样具有现实意义。关于 systemd 及其生态的许多其他好文章都是基于这些文章:


via: https://opensource.com/article/20/7/systemd-timers

作者:David Both 选题:lujun9972 译者:tt67wq 校对:wxy

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

使用开源工具来保护你的 Linux 环境不被入侵。

 title=

如今我们的许多个人和专业数据都可以在网上获得,因此无论是专业人士还是普通互联网用户,学习安全和隐私的基本知识是非常重要的。作为一名学生,我通过学校的 CyberPatriot 活动获得了这方面的经验,在那里我有机会与行业专家交流,了解网络漏洞和建立系统安全的基本步骤。

本文基于我作为初学者迄今所学的知识,详细介绍了六个简单的步骤,以提高个人使用的 Linux 环境的安全性。在我的整个旅程中,我利用开源工具来加速我的学习过程,并熟悉了与提升 Linux 服务器安全有关的更高层次的概念。

我使用我最熟悉的 Ubuntu 18.04 版本测试了这些步骤,但这些步骤也适用于其他 Linux 发行版。

1、运行更新

开发者们不断地寻找方法,通过修补已知的漏洞,使服务器更加稳定、快速、安全。定期运行更新是一个好习惯,可以最大限度地提高安全性。运行它们:

sudo apt-get update && apt-get upgrade

2、启用防火墙保护

启用防火墙 可以更容易地控制服务器上的进站和出站流量。在 Linux 上有许多防火墙应用程序可以使用,包括 firewall-cmd 简单防火墙 Uncomplicated Firewall UFW)。我使用 UFW,所以我的例子是专门针对它的,但这些原则适用于你选择的任何防火墙。

安装 UFW:

sudo apt-get install ufw

如果你想进一步保护你的服务器,你可以拒绝传入和传出的连接。请注意,这将切断你的服务器与世界的联系,所以一旦你封锁了所有的流量,你必须指定哪些出站连接是允许从你的系统中发出的:

sudo ufw default deny incoming
sudo ufw default allow outgoing

你也可以编写规则来允许你个人使用所需要的传入连接:

ufw allow <service>

例如,允许 SSH 连接:

ufw allow ssh

最后,启用你的防火墙:

sudo ufw enable

3、加强密码保护

实施强有力的密码政策是保持服务器安全、防止网络攻击和数据泄露的一个重要方面。密码策略的一些最佳实践包括强制要求最小长度和指定密码年龄。我使用 libpam-cracklib 软件包来完成这些任务。

安装 libpam-cracklib 软件包:

sudo apt-get install libpam-cracklib

强制要求密码的长度:

  • 打开 /etc/pam.d/common-password 文件。
  • minlen=12 行改为你需要的任意字符数,从而改变所有密码的最小字符长度要求。

为防止密码重复使用:

  • 在同一个文件(/etc/pam.d/common-password)中,添加 remember=x 行。
  • 例如,如果你想防止用户重复使用他们最后 5 个密码中的一个,使用 remember=5

要强制要求密码年龄:

  • /etc/login.defs 文件中找到以下几行,并用你喜欢的时间(天数)替换。例如:
PASS_MIN_AGE: 3
PASS_MAX_AGE: 90
PASS_WARN_AGE: 14 

强制要求字符规格:

  • 在密码中强制要求字符规格的四个参数是 lcredit(小写)、ucredit(大写)、dcredit(数字)和 ocredit(其他字符)。
  • 在同一个文件(/etc/pam.d/common-password)中,找到包含 pam_cracklib.so 的行。

    • 在该行末尾添加以下内容:lcredit=-a ucredit=-b dcredit=-c ocredit=-d
    • 例如,下面这行要求密码必须至少包含一个每种字符。你可以根据你喜欢的密码安全级别来改变数字。lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1

4、停用容易被利用的非必要服务。

停用不必要的服务是一种最好的做法。这样可以减少开放的端口,以便被利用。

安装 systemd 软件包:

sudo apt-get install systemd

查看哪些服务正在运行:

systemctl list-units

识别 哪些服务可能会导致你的系统出现潜在的漏洞。对于每个服务可以:

  • 停止当前正在运行的服务:systemctl stop <service>
  • 禁止服务在系统启动时启动:systemctl disable <service>
  • 运行这些命令后,检查服务的状态:systemctl status <service>

5、检查监听端口

开放的端口可能会带来安全风险,所以检查服务器上的监听端口很重要。我使用 netstat 命令来显示所有的网络连接:

netstat -tulpn

查看 “address” 列,确定 端口号。一旦你找到了开放的端口,检查它们是否都是必要的。如果不是,调整你正在运行的服务,或者调整你的防火墙设置。

6、扫描恶意软件

杀毒扫描软件可以有用的防止病毒进入你的系统。使用它们是一种简单的方法,可以让你的服务器免受恶意软件的侵害。我首选的工具是开源软件 ClamAV

安装 ClamAV:

sudo apt-get install clamav

更新病毒签名:

sudo freshclam

扫描所有文件,并打印出被感染的文件,发现一个就会响铃:

sudo clamscan -r --bell -i /

你可以而且应该设置为自动扫描,这样你就不必记住或花时间手动进行扫描。对于这样简单的自动化,你可以使用 systemd 定时器 或者你的 喜欢的 cron 来做到。

保证你的服务器安全

我们不能把保护服务器安全的责任只交给一个人或一个组织。随着威胁环境的不断迅速扩大,我们每个人都应该意识到服务器安全的重要性,并采用一些简单、有效的安全最佳实践。

这些只是你提升 Linux 服务器的安全可以采取的众多步骤中的一部分。当然,预防只是解决方案的一部分。这些策略应该与严格监控拒绝服务攻击、用 Lynis 做系统分析以及创建频繁的备份相结合。

你使用哪些开源工具来保证服务器的安全?在评论中告诉我们它们的情况。


via: https://opensource.com/article/21/4/securing-linux-servers

作者:Sahana Sreeram 选题:lujun9972 译者:wxy 校对:wxy

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

与其手动执行重复性的任务,不如让 Linux 为你做。

 title=

在 2021 年,人们有更多的理由喜欢 Linux。在这个系列中,我将分享使用 Linux 的 21 个不同理由。自动化是使用 Linux 的最佳理由之一。

我最喜欢 Linux 的一个原因是它愿意为我做工作。我不想执行重复性的任务,这些任务会占用我的时间,或者容易出错,或者我可能会忘记,我安排 Linux 为我做这些工作。

为自动化做准备

“自动化”这个词既让人望而生畏,又让人心动。我发现用模块化的方式来处理它是有帮助的。

1、你想实现什么?

首先,要知道你想产生什么结果。你是要给图片加水印吗?从杂乱的目录中删除文件?执行重要数据的备份?为自己明确定义任务,这样你就知道自己的目标是什么。如果有什么任务是你发现自己每天都在做的,甚至一天一次以上,那么它可能是自动化的候选者。

2、学习你需要的应用

将大的任务分解成小的组件,并学习如何手动但以可重复和可预测的方式产生每个结果。在 Linux 上可以做的很多事情都可以用脚本来完成,但重要的是要认识到你当前的局限性。学习如何自动调整几张图片的大小,以便可以方便地通过电子邮件发送,与使用机器学习为你的每周通讯生成精心制作的艺术品之间有天壤之别。有的事你可以在一个下午学会,而另一件事可能要花上几年时间。然而,我们都必须从某个地方开始,所以只要从小做起,并时刻注意改进的方法。

3、自动化

在 Linux 上使用一个自动化工具来定期实现它。这就是本文介绍的步骤!

要想自动化一些东西,你需要一个脚本来自动化一个任务。在测试时,最好保持简单,所以本文自动化的任务是在 /tmp 目录下创建一个名为 hello 的文件。

#!/bin/sh

touch /tmp/hello

将这个简单的脚本复制并粘贴到一个文本文件中,并将其命名为 example

Cron

每个安装好的 Linux 系统都会有的内置自动化解决方案就是 cron 系统。Linux 用户往往把 cron 笼统地称为你用来安排任务的方法(通常称为 “cron 作业”),但有多个应用程序可以提供 cron 的功能。最通用的是 cronie;它的优点是,它不会像历史上为系统管理员设计的 cron 应用程序那样,假设你的计算机总是开着。

验证你的 Linux 发行版提供的是哪个 cron 系统。如果不是 cronie,你可以从发行版的软件仓库中安装 cronie。如果你的发行版没有 cronie 的软件包,你可以使用旧的 anacron 软件包来代替。anacron 命令是包含在 cronie 中的,所以不管你是如何获得它的,你都要确保在你的系统上有 anacron 命令,然后再继续。anacron 可能需要管理员 root 权限,这取决于你的设置。

$ which anacron
/usr/sbin/anacron

anacron 的工作是确保你的自动化作业定期执行。为了做到这一点,anacron 会检查找出最后一次运行作业的时间,然后检查你告诉它运行作业的频率。

假设你将 anacron 设置为每五天运行一次脚本。每次你打开电脑或从睡眠中唤醒电脑时,anacron都会扫描其日志以确定是否需要运行作业。如果一个作业在五天或更久之前运行,那么 anacron 就会运行该作业。

Cron 作业

许多 Linux 系统都捆绑了一些维护工作,让 cron 来执行。我喜欢把我的工作与系统工作分开,所以我在我的主目录中创建了一个目录。具体来说,有一个叫做 ~/.local 的隐藏文件夹(“local” 的意思是它是为你的用户账户定制的,而不是为你的“全局”计算机系统定制的),所以我创建了子目录 etc/cron.daily 来作为 cron 在我的系统上的家目录。你还必须创建一个 spool 目录来跟踪上次运行作业的时间。

$ mkdir -p ~/.local/etc/cron.daily ~/.var/spool/anacron

你可以把任何你想定期运行的脚本放到 ~/.local/etc/cron.daily 目录中。现在把 example 脚本复制到目录中,然后 用 chmod 命令使其可执行

$ cp example ~/.local/etc/cron.daily
# chmod +x ~/.local/etc/cron.daily/example

接下来,设置 anacron 来运行位于 ~/.local/etc/cron.daily 目录下的任何脚本。

anacron

默认情况下,cron 系统的大部分内容都被认为是系统管理员的领域,因为它通常用于重要的底层任务,如轮换日志文件和更新证书。本文演示的配置是为普通用户设置个人自动化任务而设计的。

要配置 anacron 来运行你的 cron 作业,请在 /.local/etc/anacrontab 创建一个配置文件:

SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
1  0  cron.mine    run-parts /home/tux/.local/etc/cron.daily/

这个文件告诉 anacron 每到新的一天(也就是每日),延迟 0 分钟后,就运行(run-parts)所有在 ~/.local/etc/cron.daily 中找到的可执行脚本。有时,会使用几分钟的延迟,这样你的计算机就不会在你登录后就被所有可能的任务冲击。不过这个设置适合测试。

cron.mine 值是进程的一个任意名称。我称它为 cron.mine,但你也可以称它为 cron.personalpenguin 或任何你想要的名字。

验证你的 anacrontab 文件的语法:

$ anacron -T -t ~/.local/etc/anacrontab \
  -S /home/tux/.var/spool/anacron

沉默意味着成功。

在 .profile 中添加 anacron

最后,你必须确保 anacron 以你的本地配置运行。因为你是以普通用户而不是 root 用户的身份运行 anacron,所以你必须将它引导到你的本地配置:告诉 anacron 要做什么的 anacrontab 文件,以及帮助 anacron 跟踪每一个作业最后一次执行是多少天的 spool 目录:

anacron -fn -t /home/tux/.local/etc/anacrontab \
  -S /home/tux/.var/spool/anacron

-fn 选项告诉 anacron 忽略 时间戳,这意味着你强迫它无论如何都要运行你的 cron 作业。这完全是为了测试的目的。

测试你的 cron 作业

现在一切都设置好了,你可以测试作业了。从技术上讲,你可以在不重启的情况下进行测试,但重启是最有意义的,因为这就是设计用来处理中断和不规则的登录会话的。花点时间重启电脑、登录,然后寻找测试文件:

$ ls /tmp/hello
/tmp/hello

假设文件存在,那么你的示例脚本已经成功执行。现在你可以从 ~/.profile 中删除测试选项,留下这个作为你的最终配置。

anacron -t /home/tux/.local/etc/anacrontab \
  -S /home/tux/.var/spool/anacron

使用 anacron

你已经配置好了你的个人自动化基础设施,所以你可以把任何你想让你的计算机替你管理的脚本放到 ~/.local/etc/cron.daily 目录下,它就会按计划运行。

这取决于你希望作业运行的频率。示例脚本是每天执行一次。很明显,这取决于你的计算机在任何一天是否开机和醒着。如果你在周五使用电脑,但把它设置在周末,脚本就不会在周六和周日运行。然而,在周一,脚本会执行,因为 anacron 会知道至少有一天已经过去了。你可以在 ~/.local/etc 中添加每周、每两周、甚至每月的目录,以安排各种各样的间隔。

要添加一个新的时间间隔:

  1. ~/.local/etc 中添加一个目录(例如 cron.weekly)。
  2. ~/.local/etc/anacrontab 中添加一行,以便在新目录下运行脚本。对于每周一次的间隔,其配置如下。7 0 cron.mine run-parts /home/tux/.local/etc/cron.weekly/0 的值可以选择一些分钟数,以适当地延迟脚本的启动)。
  3. 把你的脚本放在 cron.weekly 目录下。

欢迎来到自动化的生活方式。它不会让人感觉到,但你将会变得更有效率。


via: https://opensource.com/article/21/2/linux-automation

作者:Seth Kenlon 选题:lujun9972 译者:wxy 校对:wxy

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

通过使用 Ansible 自动执行可重复的日常任务,提高工作效率并避免错误。

 title=

如果你讨厌执行重复性的任务,那么我有一个提议给你,去学习 Ansible!

Ansible 是一个工具,它可以帮助你更轻松、更快速地完成日常任务,这样你就可以更有效地利用时间,比如学习重要的新技术。对于系统管理员来说,它是一个很好的工具,因为它可以帮助你实现标准化,并在日常活动中进行协作,包括:

  1. 安装、配置和调配服务器和应用程序;
  2. 定期更新和升级系统;
  3. 监测、减轻和排除问题。

通常,许多这些基本的日常任务都需要手动步骤,而根据个人的技能的不同,可能会造成不一致并导致配置发生漂移。这在小规模的实施中可能是可以接受的,因为你管理一台服务器,并且知道自己在做什么。但当你管理数百或数千台服务器时会发生什么?

如果不小心,这些手动的、可重复的任务可能会因为人为的错误而造成延误和问题,而这些错误可能会影响你及你的组织的声誉。

这就是自动化的价值所在。而 Ansible 是自动化这些可重复的日常任务的完美工具。

自动化的一些原因是:

  1. 你想要一个一致和稳定的环境。
  2. 你想要促进标准化。
  3. 你希望减少停机时间,减少严重事故案例,以便可以享受生活。
  4. 你想喝杯啤酒,而不是排除故障问题!

本文提供了一些系统管理员可以使用 Ansible 自动化的日常任务的例子。我把本文中的剧本和角色放到了 GitHub 上的 系统管理员任务仓库 中,以方便你使用它们。

这些剧本的结构是这样的(我的注释前面有 ==>)。

[root@homebase 6_sysadmin_tasks]# tree -L 2
.
├── ansible.cfg ==> 负责控制 Ansible 行为的配置文件
├── ansible.log
├── inventory
│   ├── group_vars
│   ├── hosts  ==> 包含我的目标服务器列表的清单文件
│   └── host_vars
├── LICENSE
├── playbooks  ==> 包含我们将在本文中使用的剧本的目录
│   ├── c_logs.yml
│   ├── c_stats.yml
│   ├── c_uptime.yml
│   ├── inventory
│   ├── r_cron.yml
│   ├── r_install.yml
│   └── r_script.yml
├── README.md
├── roles    ==> 包含我们将在本文中使用的角色的目录
│   ├── check_logs
│   ├── check_stats
│   ├── check_uptime
│   ├── install_cron
│   ├── install_tool
│   └── run_scr
└── templates ==> 包含 jinja 模板的目录
    ├── cron_output.txt.j2
    ├── sar.txt.j2
    └── scr_output.txt.j2

清单类似这样的:

[root@homebase 6_sysadmin_tasks]# cat inventory/hosts
[rhel8]
master ansible_ssh_host=192.168.1.12
workernode1 ansible_ssh_host=192.168.1.15

[rhel8:vars]
ansible_user=ansible ==> 请用你的 ansible 用户名更新它

这里有五个你可以用 Ansible 自动完成的日常系统管理任务。

1、检查服务器的正常运行时间

你需要确保你的服务器一直处于正常运行状态。机构会拥有企业监控工具来监控服务器和应用程序的正常运行时间,但自动监控工具时常会出现故障,你需要登录进去验证一台服务器的状态。手动验证每台服务器的正常运行时间需要花费大量的时间。你的服务器越多,你需要花费的时间就越长。但如果有了自动化,这种验证可以在几分钟内完成。

使用 check\_uptime 角色和 c_uptime.yml 剧本:

[root@homebase 6_sysadmin_tasks]# ansible-playbook -i inventory/hosts  playbooks/c_uptime.yml -k
SSH password:
PLAY [Check Uptime for Servers] ****************************************************************************************************************************************
TASK [check_uptime : Capture timestamp] *************************************************************************************************
.
截断...
.
PLAY RECAP *************************************************************************************************************************************************************
master                     : ok=6    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  
workernode1                : ok=6    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  
[root@homebase 6_sysadmin_tasks]#

剧本的输出是这样的:

[root@homebase 6_sysadmin_tasks]# cat /var/tmp/uptime-master-20210221004417.txt
-----------------------------------------------------
 Uptime for  master
-----------------------------------------------------
 00:44:17 up 44 min,  2 users,  load average: 0.01, 0.09, 0.09
-----------------------------------------------------
[root@homebase 6_sysadmin_tasks]# cat /var/tmp/uptime-workernode1-20210221184525.txt
-----------------------------------------------------
 Uptime for  workernode1
-----------------------------------------------------
 18:45:26 up 44 min,  2 users,  load average: 0.01, 0.01, 0.00
-----------------------------------------------------

使用 Ansible,你可以用较少的努力以人类可读的格式获得多个服务器的状态,Jinja 模板 允许你根据自己的需要调整输出。通过更多的自动化,你可以按计划运行,并通过电子邮件发送输出,以达到报告的目的。

2、配置额外的 cron 作业

你需要根据基础设施和应用需求定期更新服务器的计划作业。这似乎是一项微不足道的工作,但必须正确且持续地完成。想象一下,如果你对数百台生产服务器进行手动操作,这需要花费多少时间。如果做错了,就会影响生产应用程序,如果计划的作业重叠,就会导致应用程序停机或影响服务器性能。

使用 install\_cron 角色和 r_cron.yml 剧本:

[root@homebase 6_sysadmin_tasks]# ansible-playbook -i inventory/hosts playbooks/r_cron.yml -k
SSH password:
PLAY [Install additional cron jobs for root] ***************************************************************************************************************************
.
截断...
.
PLAY RECAP *************************************************************************************************************************************************************
master                     : ok=10   changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  
workernode1                : ok=10   changed=7    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

验证剧本的结果:

[root@homebase 6_sysadmin_tasks]# ansible -i inventory/hosts all -m shell -a "crontab -l" -k
SSH password:
master | CHANGED | rc=0 >>
1 2 3 4 5 /usr/bin/ls /tmp
#Ansible: Iotop Monitoring
0 5,2 * * * /usr/sbin/iotop -b -n 1 >> /var/tmp/iotop.log 2>> /var/tmp/iotop.err
workernode1 | CHANGED | rc=0 >>
1 2 3 4 5 /usr/bin/ls /tmp
#Ansible: Iotop Monitoring
0 5,2 * * * /usr/sbin/iotop -b -n 1 >> /var/tmp/iotop.log 2>> /var/tmp/iotop.err

使用 Ansible,你可以以快速和一致的方式更新所有服务器上的 crontab 条目。你还可以使用一个简单的点对点 Ansible 命令来报告更新后的 crontab 的状态,以验证最近应用的变化。

3、收集服务器统计和 sars

在常规的故障排除过程中,为了诊断服务器性能或应用程序问题,你需要收集 系统活动报告 system activity reports (sars)和服务器统计。在大多数情况下,服务器日志包含非常重要的信息,开发人员或运维团队需要这些信息来帮助解决影响整个环境的具体问题。

安全团队在进行调查时非常特别,大多数时候,他们希望查看多个服务器的日志。你需要找到一种简单的方法来收集这些文档。如果你能把收集任务委托给他们就更好了。

通过 check\_stats 角色和 c_stats.yml 剧本来完成这个任务:

$ ansible-playbook -i inventory/hosts  playbooks/c_stats.yml

PLAY [Check Stats/sar for Servers] ***********************************************************************************************************************************

TASK [check_stats : Get current date time] ***************************************************************************************************************************
changed: [master]
changed: [workernode1]
.
截断...
.
PLAY RECAP ***********************************************************************************************************************************************************
master                     : ok=5    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  
workernode1                : ok=5    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

输出看起来像这样:

$ cat /tmp/sar-workernode1-20210221214056.txt
-----------------------------------------------------
 sar output for workernode1
-----------------------------------------------------
Linux 4.18.0-193.el8.x86_64 (node1)     21/02/21        _x86_64_        (2 CPU)
21:39:30     LINUX RESTART      (2 CPU)
-----------------------------------------------------

4、收集服务器日志

除了收集服务器统计和 sars 信息,你还需要不时地收集日志,尤其是当你需要帮助调查问题时。

通过 check\_logs 角色和 r_cron.yml 剧本来实现:

$ ansible-playbook -i inventory/hosts  playbooks/c_logs.yml -k
SSH password:

PLAY [Check Logs for Servers] ****************************************************************************************************************************************
.
截断...
.
TASK [check_logs : Capture Timestamp] ********************************************************************************************************************************
changed: [master]
changed: [workernode1]
PLAY RECAP ***********************************************************************************************************************************************************
master                     : ok=6    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  
workernode1                : ok=6    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

为了确认输出,打开转储位置生成的文件。日志应该是这样的:

$ cat /tmp/logs-workernode1-20210221214758.txt | more
-----------------------------------------------------
 Logs gathered: /var/log/messages for workernode1
-----------------------------------------------------

Feb 21 18:00:27 node1 kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-4.18.0-193.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel
-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet
Feb 21 18:00:27 node1 kernel: Disabled fast string operations
Feb 21 18:00:27 node1 kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Feb 21 18:00:27 node1 kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Feb 21 18:00:27 node1 kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Feb 21 18:00:27 node1 kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Feb 21 18:00:27 node1 kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.

5、安装或删除软件包和软件

你需要能够持续快速地在系统上安装和更新软件和软件包。缩短安装或更新软件包和软件所需的时间,可以避免服务器和应用程序不必要的停机时间。

通过 install\_tool 角色和 r_install.yml 剧本来实现这一点:

$ ansible-playbook -i inventory/hosts playbooks/r_install.yml -k
SSH password:
PLAY [Install additional tools/packages] ***********************************************************************************

TASK [install_tool : Install specified tools in the role vars] *************************************************************
ok: [master] => (item=iotop)
ok: [workernode1] => (item=iotop)
ok: [workernode1] => (item=traceroute)
ok: [master] => (item=traceroute)

PLAY RECAP *****************************************************************************************************************
master                     : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  
workernode1                : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

这个例子安装了在 vars 文件中定义的两个特定包和版本。使用 Ansible 自动化,你可以比手动安装更快地安装多个软件包或软件。你也可以使用 vars 文件来定义你要安装的软件包的版本。

$ cat roles/install_tool/vars/main.yml
---
# vars file for install_tool
ins_action: absent
package_list:
  - iotop-0.6-16.el8.noarch
  - traceroute

拥抱自动化

要成为一名有效率的系统管理员,你需要接受自动化来鼓励团队内部的标准化和协作。Ansible 使你能够在更少的时间内做更多的事情,这样你就可以将时间花在更令人兴奋的项目上,而不是做重复的任务,如管理你的事件和问题管理流程。

有了更多的空闲时间,你可以学习更多的知识,让自己可以迎接下一个职业机会的到来。


via: https://opensource.com/article/21/3/ansible-sysadmin

作者:Mike Calizo 选题:lujun9972 译者:wxy 校对:wxy

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

我们已经写了两篇关于 Ansible 的文章,这是第三篇。

如果你是 Ansible 新手,我建议你阅读下面这两篇文章,它会教你一些 Ansible 的基础以及它是什么。

如果你已经阅读过了,那么在阅读本文时你才不会感到突兀。

什么是 Ansible 剧本?

剧本 playbook 比点对点命令模式更强大,而且完全不同。

它使用了 /usr/bin/ansible-playbook 二进制文件,并且提供丰富的特性使得复杂的任务变得更容易。

如果你想经常运行一个任务,剧本是非常有用的。此外,如果你想在服务器组上执行多个任务,它也是非常有用的。

剧本是由 YAML 语言编写。YAML 代表一种标记语言,它比其它常见的数据格式(如 XML 或 JSON)更容易读写。

下面这张 Ansible 剧本流程图将告诉你它的详细结构。

理解 Ansible 剧本的术语

  • 控制节点 Control node :Ansible 安装的机器,它负责管理客户端节点。
  • 受控节点 Managed node :控制节点管理的主机列表。
  • 剧本 playbook :一个剧本文件包含一组自动化任务。
  • 主机清单 Inventory :这个文件包含有关管理的服务器的信息。
  • 任务 Task :每个剧本都有大量的任务。任务在指定机器上依次执行(一个主机或多个主机)。
  • 模块 Module : 模块是一个代码单元,用于从客户端节点收集信息。
  • 角色 Role :角色是根据已知文件结构自动加载一些变量文件、任务和处理程序的方法。
  • 动作 Play :每个剧本含有大量的动作,一个动作从头到尾执行一个特定的自动化。
  • 处理程序 Handler : 它可以帮助你减少在剧本中的重启任务。处理程序任务列表实际上与常规任务没有什么不同,更改由通知程序通知。如果处理程序没有收到任何通知,它将不起作用。

基本的剧本是怎样的?

下面是一个剧本的模板:

---                                [YAML 文件应该以三个破折号开头]
- name:                            [脚本描述]
  hosts: group                     [添加主机或主机组]
  become: true                     [如果你想以 root 身份运行任务,则标记它]
  tasks:                           [你想在任务下执行什么动作]
    - name:                        [输入模块选项]
      module:                      [输入要执行的模块]
        module_options-1: value    [输入模块选项]
        module_options-2: value
        .
        module_options-N: value

如何理解 Ansible 的输出

Ansible 剧本的输出有四种颜色,下面是具体含义:

  • 绿色ok 代表成功,关联的任务数据已经存在,并且已经根据需要进行了配置。
  • 黄色changed 指定的数据已经根据任务的需要更新或修改。
  • 红色FAILED 如果在执行任务时出现任何问题,它将返回一个失败消息,它可能是任何东西,你需要相应地修复它。
  • 白色:表示有多个参数。

为此,创建一个剧本目录,将它们都放在同一个地方。

$ sudo mkdir /etc/ansible/playbooks

剧本-1:在 RHEL 系统上安装 Apache Web 服务器

这个示例剧本允许你在指定的目标机器上安装 Apache Web 服务器:

$ sudo nano /etc/ansible/playbooks/apache.yml

---
- hosts: web
  become: yes
  name: "Install and Configure Apache Web server"
  tasks:
    - name: "Install Apache Web Server"
      yum:
        name: httpd
        state: latest
    - name: "Ensure Apache Web Server is Running"
      service:
        name: httpd
        state: started
$ ansible-playbook apache1.yml

如何理解 Ansible 中剧本的执行

使用以下命令来查看语法错误。如果没有发现错误,它只显示剧本文件名。如果它检测到任何错误,你将得到一个如下所示的错误,但内容可能根据你的输入文件而有所不同。

$ ansible-playbook apache1.yml --syntax-check

ERROR! Syntax Error while loading YAML.
  found a tab character that violate indentation
The error appears to be in '/etc/ansible/playbooks/apache1.yml': line 10, column 1, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
        state: latest
^ here
There appears to be a tab character at the start of the line.

YAML does not use tabs for formatting. Tabs should be replaced with spaces.
For example:
    - name: update tooling
      vars:
        version: 1.2.3
# ^--- there is a tab there.
Should be written as:
    - name: update tooling
      vars:
        version: 1.2.3
# ^--- all spaces here.

或者,你可以使用这个 URL YAML Lint 在线检查 Ansible 剧本内容。

执行以下命令进行“演练”。当你运行带有 --check 选项的剧本时,它不会对远程机器进行任何修改。相反,它会告诉你它将要做什么改变但不是真的执行。

$ ansible-playbook apache.yml --check

PLAY [Install and Configure Apache Webserver] ********************************************************************

TASK [Gathering Facts] *******************************************************************************************
ok: [node2.2g.lab]
ok: [node1.2g.lab]

TASK [Install Apache Web Server] *********************************************************************************
changed: [node2.2g.lab]
changed: [node1.2g.lab]

TASK [Ensure Apache Web Server is Running] ***********************************************************************
changed: [node1.2g.lab]
changed: [node2.2g.lab]

PLAY RECAP *******************************************************************************************************
node1.2g.lab               : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
node2.2g.lab               : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

如果你想要知道 ansible 剧本实现的详细信息,使用 -vv 选项,它会展示如何收集这些信息。

$ ansible-playbook apache.yml --check -vv

ansible-playbook 2.9.2
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/daygeek/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.8/site-packages/ansible
  executable location = /usr/bin/ansible-playbook
  python version = 3.8.1 (default, Jan  8 2020, 23:09:20) [GCC 9.2.0]
Using /etc/ansible/ansible.cfg as config file

PLAYBOOK: apache.yml *****************************************************************************************************
1 plays in apache.yml

PLAY [Install and Configure Apache Webserver] ****************************************************************************

TASK [Gathering Facts] ***************************************************************************************************
task path: /etc/ansible/playbooks/apache.yml:2
ok: [node2.2g.lab]
ok: [node1.2g.lab]
META: ran handlers

TASK [Install Apache Web Server] *****************************************************************************************
task path: /etc/ansible/playbooks/apache.yml:6
changed: [node2.2g.lab] => {"changed": true, "msg": "Check mode: No changes made, but would have if not in check mod
e", "rc": 0, "results": ["Installed: httpd"]}
changed: [node1.2g.lab] => {"changed": true, "changes": {"installed": ["httpd"], "updated": []}, "msg": "", "obsolet
es": {"urw-fonts": {"dist": "noarch", "repo": "@anaconda", "version": "2.4-16.el7"}}, "rc": 0, "results": []}

TASK [Ensure Apache Web Server is Running] *******************************************************************************
task path: /etc/ansible/playbooks/apache.yml:10
changed: [node1.2g.lab] => {"changed": true, "msg": "Service httpd not found on host, assuming it will exist on full run"}
changed: [node2.2g.lab] => {"changed": true, "msg": "Service httpd not found on host, assuming it will exist on full run"}
META: ran handlers
META: ran handlers

PLAY RECAP ***************************************************************************************************************
node1.2g.lab               : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
node2.2g.lab               : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

剧本-2:在 Ubuntu 系统上安装 Apache Web 服务器

这个示例剧本允许你在指定的目标节点上安装 Apache Web 服务器。

$ sudo nano /etc/ansible/playbooks/apache-ubuntu.yml

---
- hosts: web
  become: yes
  name: "Install and Configure Apache Web Server"
  tasks:
    - name: "Install Apache Web Server"
      yum:
        name: apache2
        state: latest

    - name: "Start the Apache Web Server"
      service:
        name: apaceh2
        state: started

    - name: "Enable mod_rewrite module"
      apache2_module:
        name: rewrite
        state: present

      notify:
      - start apache

  handlers:
    - name: "Ensure Apache Web Server is Running"
      service:
        name: apache2
        state: restarted
        enabled: yes

剧本-3:在 Red Hat 系统上安装软件包列表

这个示例剧本允许你在指定的目标节点上安装软件包。

方法-1:

$ sudo nano /etc/ansible/playbooks/packages-redhat.yml

---
- hosts: web
  become: yes
  name: "Install a List of Packages on Red Hat Based System"
  tasks:
    - name: "Installing a list of packages"
      yum:
        name:
          - curl
          - httpd
          - nano
          - htop

方法-2:

$ sudo nano /etc/ansible/playbooks/packages-redhat-1.yml

---
- hosts: web
  become: yes
  name: "Install a List of Packages on Red Hat Based System"
  tasks:
    - name: "Installing a list of packages"
      yum: name={{ item }} state=latest
      with_items:
        - curl
        - httpd
        - nano
        - htop

方法-3:使用数组变量

$ sudo nano /etc/ansible/playbooks/packages-redhat-2.yml

---
- hosts: web
  become: yes
  name: "Install a List of Packages on Red Hat Based System"
  vars:
     packages: [ 'curl', 'git', 'htop' ]
  tasks:
     - name: Install a list of packages
       yum: name={{ item }} state=latest
       with_items: "{{ packages }}"

剧本-4:在 Linux 系统上安装更新

这个示例剧本允许你在基于 Red Hat 或 Debian 的 Linux 系统上安装更新。

$ sudo nano /etc/ansible/playbooks/security-update.yml

---
- hosts: web
  become: yes
  name: "Install Security Update"
  tasks:
    - name: "Installing Security Update on Red Hat Based System"
      yum: name=* update_cache=yes security=yes state=latest
      when: ansible_facts['distribution'] == "CentOS"

    - name: "Installing Security Update on Ubuntu Based System"
      apt: upgrade=dist update_cache=yes
      when: ansible_facts['distribution'] == "Ubuntu"

via: https://www.2daygeek.com/ansible-playbooks-quick-start-guide-with-examples/

作者:Magesh Maruthamuthu 选题:lujun9972 译者:MjSeven 校对:wxy

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

之前,我们写了一篇有关 Ansible 安装和配置 的文章。在那个教程中只包含了一些使用方法的示例。如果你是 Ansible 新手,建议你阅读上篇文章。一旦你熟悉了,就可以继续阅读本文了。

默认情况下,Ansible 仅使用 5 个并行进程。如果要在多个主机上执行任务,需要通过添加 -f [进程数] 选项来手动设置进程数。

什么是 点对点 ad-hoc 命令?

点对点命令用于在一个或多个受控节点上自动执行任务。它非常简单,但是不可重用。它使用 /usr/bin/ansible 二进制文件执行所有操作。

点对点命令最适合运行一次的任务。例如,如果要检查指定用户是否可用,你可以使用一行命令而无需编写剧本。

为什么你要了解点对点命令?

点对点命令证明了 Ansible 的简单性和强大功能。从 2.9 版本开始,它支持 3389 个模块,因此你需要了解和学习要定期使用的 Ansible 模块列表。

如果你是一个 Ansible 新手,可以借助点对点命令轻松地练习这些模块及参数。

你在这里学习到的概念将直接移植到剧本中。

点对点命令的一般语法:

ansible [模式] -m [模块] -a "[模块选项]"

点对点命令包含四个部分,详细信息如下:

部分描述
ansible命令
模式输入清单或指定组
模块运行指定的模块名称
模块选项指定模块参数

如何使用 Ansible 清单文件

如果使用 Ansible 的默认清单文件 /etc/ansible/hosts,你可以直接调用它。否则你可以使用 -i 选项指定 Ansible 清单文件的路径。

什么是模式以及如何使用它?

Ansible 模式可以代指某个主机、IP 地址、清单组、一组主机或者清单中的所有主机。它允许你对它们运行命令和剧本。模式非常灵活,你可以根据需要使用它们。

例如,你可以排除主机、使用通配符或正则表达式等等。

下表描述了常见的模式以及用法。但是,如果它不能满足你的需求,你可以在 ansible-playbook 中使用带有 -e 参数的模式中的变量。

描述模式目标
所有主机all(或 *对清单中的所有服务器运行 Ansible
一台主机host1只针对给定主机运行 Ansible
多台主机host1:host2(或 host1,host2对上述多台主机运行 Ansible
一组webserverswebservers 群组中运行 Ansible
多组webservers:dbserverswebservers 中的所有主机加上 dbservers 中的所有主机
排除组webservers:!atlantawebservers 中除 atlanta 以外的所有主机
组之间的交集webservers:&stagingwebservers 中也在 staging 的任何主机

什么是 Ansible 模块,它干了什么?

模块,也称为“任务插件”或“库插件”,它是一组代码单元,可以直接或通过剧本在远程主机上执行指定任务。

Ansible 在远程目标节点上执行指定模块并收集其返回值。

每个模块都支持多个参数,可以满足用户的需求。除少数模块外,几乎所有模块都采用 key=value 参数。你可以一次添加带有空格的多个参数,而 commandshell 模块会直接运行你输入的字符串。

我们将添加一个包含最常用的“模块选项”参数的表。

列出所有可用的模块,运行以下命令:

$ ansible-doc -l

运行以下命令来阅读指定模块的文档:

$ ansible-doc [模块]

1)如何在 Linux 上使用 Ansible 列出目录的内容

可以使用 Ansible command 模块来完成这项操作,如下所示。我们列出了 node1.2g.labnod2.2g.lab* 远程服务器上 daygeek 用户主目录的内容。

$ ansible web -m command -a "ls -lh /home/daygeek"

node1.2g.lab | CHANGED | rc=0 >>
total 12K
drwxr-xr-x. 2 daygeek daygeek   6 Feb 15  2019 Desktop
drwxr-xr-x. 2 daygeek daygeek   6 Feb 15  2019 Documents
drwxr-xr-x. 2 daygeek daygeek   6 Feb 15  2019 Downloads
drwxr-xr-x. 2 daygeek daygeek   6 Feb 15  2019 Music
-rwxr-xr-x. 1 daygeek daygeek 159 Mar  4  2019 passwd-up.sh
drwxr-xr-x. 2 daygeek daygeek   6 Feb 15  2019 Pictures
drwxr-xr-x. 2 daygeek daygeek   6 Feb 15  2019 Public
drwxr-xr-x. 2 daygeek daygeek   6 Feb 15  2019 Templates
-rwxrwxr-x. 1 daygeek daygeek 138 Mar 10  2019 user-add.sh
-rw-rw-r--. 1 daygeek daygeek  18 Mar 10  2019 user-list1.txt
drwxr-xr-x. 2 daygeek daygeek   6 Feb 15  2019 Videos

node2.2g.lab | CHANGED | rc=0 >>
total 0
drwxr-xr-x. 2 daygeek daygeek 6 Nov  9 09:55 Desktop
drwxr-xr-x. 2 daygeek daygeek 6 Nov  9 09:55 Documents
drwxr-xr-x. 2 daygeek daygeek 6 Nov  9 09:55 Downloads
drwxr-xr-x. 2 daygeek daygeek 6 Nov  9 09:55 Music
drwxr-xr-x. 2 daygeek daygeek 6 Nov  9 09:55 Pictures
drwxr-xr-x. 2 daygeek daygeek 6 Nov  9 09:55 Public
drwxr-xr-x. 2 daygeek daygeek 6 Nov  9 09:55 Templates
drwxr-xr-x. 2 daygeek daygeek 6 Nov  9 09:55 Videos

2)如何在 Linux 使用 Ansible 管理文件

Ansible 的 copy 模块将文件从本地系统复制到远程系统。使用 Ansible command 模块将文件移动或复制到远程计算机。

$ ansible web -m copy -a "src=/home/daygeek/backup/CentOS7.2daygeek.com-20191025.tar dest=/home/u1" --become

node1.2g.lab | CHANGED => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": true,
    "checksum": "ad8aadc0542028676b5fe34c94347829f0485a8c",
    "dest": "/home/u1/CentOS7.2daygeek.com-20191025.tar",
    "gid": 0,
    "group": "root",
    "md5sum": "ee8e778646e00456a4cedd5fd6458cf5",
    "mode": "0644",
    "owner": "root",
    "secontext": "unconfined_u:object_r:user_home_t:s0",
    "size": 30720,
    "src": "/home/daygeek/.ansible/tmp/ansible-tmp-1579726582.474042-118186643704900/source",
    "state": "file",
    "uid": 0
}

node2.2g.lab | CHANGED => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/libexec/platform-python"
    },
    "changed": true,
    "checksum": "ad8aadc0542028676b5fe34c94347829f0485a8c",
    "dest": "/home/u1/CentOS7.2daygeek.com-20191025.tar",
    "gid": 0,
    "group": "root",
    "md5sum": "ee8e778646e00456a4cedd5fd6458cf5",
    "mode": "0644",
    "owner": "root",
    "secontext": "unconfined_u:object_r:user_home_t:s0",
    "size": 30720,
    "src": "/home/daygeek/.ansible/tmp/ansible-tmp-1579726582.4793239-237229399335623/source",
    "state": "file",
    "uid": 0
}

我们可以运行以下命令进行验证:

$ ansible web -m command -a "ls -lh /home/u1" --become

node1.2g.lab | CHANGED | rc=0 >>
total 36K
-rw-r--r--. 1 root root 30K Jan 22 14:56 CentOS7.2daygeek.com-20191025.tar
-rw-r--r--. 1 root root  25 Dec  9 03:31 user-add.sh

node2.2g.lab | CHANGED | rc=0 >>
total 36K
-rw-r--r--. 1 root root 30K Jan 23 02:26 CentOS7.2daygeek.com-20191025.tar
-rw-rw-r--. 1 u1   u1    18 Jan 23 02:21 magi.txt

要将文件从一个位置复制到远程计算机上的另一个位置,使用以下命令:

$ ansible web -m command -a "cp /home/u2/magi/ansible-1.txt /home/u2/magi/2g" --become

移动文件,使用以下命令:

$ ansible web -m command -a "mv /home/u2/magi/ansible.txt /home/u2/magi/2g" --become

u1 用户目录下创建一个名为 ansible.txt 的新文件,运行以下命令:

$ ansible web -m file -a "dest=/home/u1/ansible.txt owner=u1 group=u1 state=touch" --become

u1 用户目录下创建一个名为 magi 的新目录,运行以下命令:

$ ansible web -m file -a "dest=/home/u1/magi mode=755 owner=u2 group=u2 state=directory" --become

u1 用户目录下的 ansible.txt* 文件权限更改为 777,运行以下命令:

$ ansible web -m file -a "dest=/home/u1/ansible.txt mode=777" --become

删除 u1 用户目录下的 ansible.txt 文件,运行以下命令:

$ ansible web -m file -a "dest=/home/u2/magi/ansible-1.txt state=absent" --become

使用以下命令删除目录,它将递归删除指定目录:

$ ansible web -m file -a "dest=/home/u2/magi/2g state=absent" --become

3)用户管理

你可以使用 Ansible 轻松执行用户管理活动。例如创建、删除用户以及向一个组添加用户。

$ ansible all -m user -a "name=foo password=[crypted password here]"

运行以下命令删除用户:

$ ansible all -m user -a "name=foo state=absent"

4)管理包

使用合适的 Ansible 包管理器模块可以轻松地管理安装包。例如,我们将使用 yum 模块来管理 CentOS 系统上的软件包。

安装最新的 Apache(httpd):

$ ansible web -m yum -a "name=httpd state=latest"

卸载 Apache(httpd) 包:

$ ansible web -m yum -a "name=httpd state=absent"

5)管理服务

使用以下 Ansible 模块命令可以在 Linux 上管理任何服务。

停止 httpd 服务:

$ ansible web -m service -a "name=httpd state=stopped"

启动 httpd 服务:

$ ansible web -m service -a "name=httpd state=started"

重启 httpd 服务:

$ ansible web -m service -a "name=httpd state=restarted"

via: https://www.2daygeek.com/ansible-ad-hoc-command-quick-start-guide-with-examples/

作者:Magesh Maruthamuthu 选题:lujun9972 译者:MjSeven 校对:wxy

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