使用服务模块执行常见系统管理任务

即使不需要完整的playbook，Ansible也非常有用。如果某个服务在几台主机上宕机，或者需要在维护窗口前禁用某个嘈杂的服务，ad-hoc命令可能是合适的工具。它提供了相同的清单定位和权限提升模型，而无需为一次性操作创建YAML文件。

内置的service模块是系统管理员工具包中最常用的工具之一。它提供了一个标准化、幂等的接口，用于管理跨不同Linux发行版的服务，抽象了Systemd、SysVinit和Upstart等初始化系统之间的差异。本指南详细介绍了如何仅通过ad-hoc命令利用service模块来执行基本的、常见的系统管理操作。

理解Ad-Hoc命令和`service`模块

Ad-hoc命令是使用/usr/bin/ansible命令的单行执行，指定目标组（-i）、模块（-m）和参数（-a）。它们是非持久性的，不依赖于playbook YAML文件。

service模块主要需要两个参数：

name：要管理的服务名称（例如，httpd、nginx、sshd）。
state：期望的操作状态（started、stopped、restarted、reloaded）。
enabled（可选）：服务是否应在系统启动时启动（yes或no）。

基本Ad-Hoc命令语法

以下所有示例都使用ansible命令。由于管理服务通常需要root权限，因此-b（become/sudo）标志几乎总是必需的。

ansible <host_pattern> -m service -a "name=<service_name> state=<action> enabled=<yes/no>" -b

注意： 将<host_pattern>替换为目标主机或组（例如，webservers、all）。

1. 确保服务正在运行（启动服务）

最常见的任务之一是确保关键服务当前处于活动状态。state=started参数确保如果服务已停止，Ansible会启动它。如果它已经在运行，Ansible不会执行任何操作（幂等性）。

示例：确保Nginx Web服务器在所有Web服务器上运行

ansible webservers -m service -a "name=nginx state=started" -b

如果Ansible返回changed: true消息，则表示服务已停止并已启动。如果返回changed: false，则表示服务已在运行。

2. 停止服务

要立即停止活动服务，请使用state=stopped。这对于维护、依赖清理或紧急安全补丁非常有用。

示例：停止所有数据库服务器上的PostgreSQL数据库

ansible db_servers -m service -a "name=postgresql state=stopped" -b

提示： 停止关键服务时，请确保之后使用其他模块（例如command模块）运行验证命令以确认状态（例如，ansible db_servers -a 'systemctl status postgresql'）。

3. 重启和重载服务

当配置文件被修改时，服务通常需要优雅地重载或强制重启。service模块处理这两种操作。

重启（`state=restarted`）

重启涉及完全停止然后启动服务。这对于影响底层守护程序行为的更改是必需的。

示例：重启所有主机上的SSH守护程序

ansible all -m service -a "name=sshd state=restarted" -b

重载（`state=reloaded`）

在服务支持的情况下（如Nginx或Apache），重载会在不中断现有连接的情况下应用配置更改。这是高可用性环境中的首选方法。

示例：优雅地重载Nginx配置

ansible webservers -m service -a "name=nginx state=reloaded" -b

重要： 如果服务不支持reload，结果取决于服务管理器和单元定义。某些单元会失败重载请求，某些会将重载映射到其他操作，而某些则不会执行任何有用的操作。在依赖重载进行生产更改之前，请检查服务自己的文档。

4. 管理服务持久性（启用和禁用）

state参数控制当前运行时状态。单独的enabled参数控制服务是否会在操作系统启动时自动启动。

确保服务在启动时启动（`enabled=yes`）

这对于必须在主机重启后仍然存在的关键任务服务至关重要。

示例：确保Docker服务已启用并正在运行

ansible dockernodes -m service -a "name=docker state=started enabled=yes" -b

阻止服务在启动时启动（`enabled=no`）

这通常用于保护系统或禁用不必要的默认服务（例如，如果使用基于云的防火墙，则禁用内置防火墙）。

示例：禁用默认的Firewalld服务

ansible all -m service -a "name=firewalld state=stopped enabled=no" -b

安全最佳实践： 始终确保未使用的服务既stopped又enabled=no，以防止在系统更新或重启期间意外启动。

5. 处理高级服务类型和错误

虽然通用service模块旨在跨所有主要初始化系统工作，但在某些情况下，显式处理是有用或必要的。

当通用模块失败时

在极少数情况下，尤其是在较旧的系统或高度自定义的环境中，通用service模块可能无法检测到正确的初始化系统。Ansible为此类情况提供了特定于系统的模块：

systemd：适用于所有现代发行版（CentOS 7+、Ubuntu 15+、Debian 8+）。
sysvinit：适用于较旧的系统或专门的发行版。

如果您知道目标使用Systemd，则可以显式使用systemd模块，尽管其语法对于基本操作与通用service模块相同：

# 显式使用systemd模块（功能与'service'相同）
ansible servers -m systemd -a "name=chronyd state=started enabled=yes" -b

使用自定义脚本管理服务

如果您需要执行初始化系统本身不支持的服务命令（例如，启动期间的自定义环境变量），则可能需要将service模块与完整playbook中的其他任务结合使用，或者使用shell模块进行ad-hoc干预，但这会降低幂等性。

# 使用'shell'进行复杂服务任务的Ad-hoc命令示例（谨慎使用）
ansible webservers -a "/usr/bin/my_custom_service_script restart" -b

服务模块Ad-Hoc命令速查表

任务	参数	示例命令
确保运行	`state=started`	`ansible all -m service -a "name=apache2 state=started" -b`
停止服务	`state=stopped`	`ansible all -m service -a "name=fail2ban state=stopped" -b`
强制重启	`state=restarted`	`ansible servers -m service -a "name=postfix state=restarted" -b`
优雅重载	`state=reloaded`	`ansible webservers -m service -a "name=httpd state=reloaded" -b`
设置自动启动	`enabled=yes`	`ansible all -m service -a "name=firewalld enabled=yes" -b`
禁用自动启动	`enabled=no`	`ansible all -m service -a "name=cups enabled=no" -b`
确保运行并启用	`state=started enabled=yes`	`ansible control -m service -a "name=ansible_api state=started enabled=yes" -b`

实际事件的安全工作流程

在事件期间使用Ansible服务模块时，命令本身通常是容易的部分。更难的部分是确保您定位到正确的主机并理解服务管理器将执行的操作。

从清单检查开始。如果您即将在webservers上重启Nginx，请检查该组包含的内容：

ansible-inventory -i inventory.ini --graph webservers

如果您的清单是动态的，请针对动态源运行相同的检查。云标签包含您未预期的主机是很常见的，尤其是在迁移或临时扩展事件之后。在五个应用程序节点上安全的服务重启可能对区域中的每个节点都有风险。

接下来，针对同一目标运行只读命令：

ansible webservers -m command -a "systemctl is-active nginx" -b

这会在您进行更改之前确认连接用户、权限提升、主机模式和服务名称。在Debian和Ubuntu上，Web服务通常是nginx或apache2；在许多Red Hat系列系统上，Apache通常是httpd。Ansible模块无法为您猜测包命名约定。

对于高风险服务，首先使用--limit：

ansible webservers --limit web01.example.com -m service -a "name=nginx state=reloaded" -b

如果有效，则扩展到一个小型组，然后扩展到完整组。Ad-hoc命令没有playbook内置的serial推出结构，因此您需要谨慎。对于大型集群，一个简短的playbook可能比一个巨大的ad-hoc命令更安全，因为您可以设置serial、添加健康检查并在失败时停止。

小心使用state=restarted。它总是请求重启，因此即使没有其他更改，它也会报告changed并中断服务。当您确实想要重启时，这没问题。当您将其用作“确保一切正常”的懒惰方式时，这是浪费的。对于常规检查，首选state=started；它会启动已停止的服务，但不会干扰正在运行的服务。

enabled=yes和enabled=no同样需要小心。它们会更改启动行为，而不仅仅是当前运行时行为。如果您在故障排除期间运行此命令：

ansible all -m service -a "name=firewalld state=stopped enabled=no" -b

您不仅现在停止了防火墙；您还告诉系统在重启后不要启动它。在故意禁用主机防火墙的云环境中，这可能是正确的，或者可能违反您的安全基线。在共享运营团队中，请留下工单注释或提交playbook更改，以便持久性决策可见。

对于由systemd管理的服务，ansible.builtin.systemd_service模块为您提供systemd特定的选项，例如daemon_reload、masked和用户范围的服务。通用service模块对于可移植的基本操作仍然很方便，但是一旦您需要systemd特定的行为，请直接使用systemd模块：

ansible appservers -m ansible.builtin.systemd_service -a "name=myapp state=restarted daemon_reload=true" -b

最后，始终读取结果。changed=true意味着Ansible要求模块更改某些内容，并不意味着应用程序之后是健康的。服务可以干净地重启，但仍然在两秒后失败其自身的健康检查。使用与应用程序匹配的检查来跟进服务更改：

ansible webservers -m uri -a "url=http://127.0.0.1/health status_code=200"

或者，如果HTTP不可用：

ansible webservers -m command -a "systemctl is-active nginx" -b

最好的ad-hoc服务命令是无聊的：狭窄的目标、清晰的状态、包含权限提升以及紧随其后的验证命令。这种习惯可以防止大多数因快速管理服务而导致的错误。

何时Ad-Hoc命令应变为Playbook

Ad-hoc命令非常适合快速、低上下文的工作。它们不能替代可重复的操作。如果您发现自己将相同的服务命令粘贴到聊天中，添加手动验证步骤，并告诉某人“在前两台主机上运行此命令，等待，然后在其余主机上运行”，那么这已经是一个试图存在的playbook。

Playbook为您提供可审查的意图：

- name: 安全地重载nginx
  hosts: webservers
  become: true
  serial: 5
  tasks:
    - name: 验证nginx配置
      ansible.builtin.command: nginx -t
      changed_when: false

    - name: 重载nginx
      ansible.builtin.service:
        name: nginx
        state: reloaded

    - name: 检查本地健康端点
      ansible.builtin.uri:
        url: http://127.0.0.1/health
        status_code: 200

相同的操作仍然很简单，但现在有了批处理、验证和健康检查。它可以存在于Git中。有人可以在下一个维护窗口之前审查它。您还可以添加any_errors_fatal: true或调整失败行为，而不是盯着终端并在压力下做出判断。

继续使用ad-hoc service命令进行快速启动、停止和检查。当操作影响客户可见的可用性、需要推出顺序或需要由其他人重复时，请使用playbook。这条线不是关于仪式；而是关于使风险部分可见。