一、为什么这个 NFS 案例很有代表性

相比简单的文件分发和软件安装，这个案例更接近真实运维场景，因为它同时涉及：

  • 不同角色主机
  • 不同主机组执行不同任务
  • 服务端和客户端联动

原始笔记里把它定义为“案例 03”，本质上是在演示：

  • 如何用一个 Playbook 同时完成服务端和客户端的自动化部署

二、先明确需求和步骤

原始笔记中给出的需求是：

  • NFS 服务端：在 nfs 主机组上部署 NFS 服务，共享 /backup-nfs 目录，使用 all_squash，匿名用户为 nfsnobody
  • NFS 客户端：在 web 主机组上挂载 /ans-upload 到 NFS 服务端共享的 /backup-nfs，并实现永久挂载

2.1 服务端步骤

原始笔记将服务端流程拆成：

1、部署 nfs-utils 2、修改 /etc/exports 3、创建共享目录并修改所有者 4、启动 rpcbind 和 nfs

2.2 客户端步骤

客户端流程拆成：

1、安装 nfs-utils 2、挂载并实现永久挂载

这正是 Ansible 特别擅长的场景：把角色不同的操作，统一编排在一个剧本里。

三、Playbook 示例

原始笔记中的剧本如下：

# NFS服务端部署
- hosts: nfs
  tasks:
    - name: 01. 部署nfs-utils, rpcbind
      yum:
        name: nfs-utils,rpcbind
        state: present
    - name: 02. 修改配置文件
      lineinfile:
        path: /etc/exports
        line: "/backup-nfs 192.168.1.0/24(rw,all_squash)"
        create: true
    - name: 03. 创建共享目录并更改所有者
      file:
        path: /backup-nfs
        owner: nfsnobody
        group: nfsnobody
        state: directory
    - name: 04-1. 启动服务rpcbind, nfs(注意顺序)
      systemd:
        name: rpcbind
        enabled: yes
        state: started
    - name: 04-2. 启动服务rpcbind, nfs(注意顺序)
      systemd:
        name: nfs
        enabled: yes
        state: started

# NFS客户端部署
- hosts: web
  tasks:
    - name: 01. 部署nfs-utils
      yum:
        name: nfs-utils
        state: present
    - name: 02. 挂载nfs
      mount:
        src: 192.168.1.22:/backup-nfs
        path: /ans-upload
        fstype: nfs
        state: mounted

四、这个剧本体现了哪些关键能力

4.1 按主机组分别执行不同任务

这个案例最关键的点之一就是：

  • hosts: nfs 负责服务端部署
  • hosts: web 负责客户端挂载

这说明一个 Playbook 可以包含多个 Play，每个 Play 对应不同主机组和不同任务。

4.2 使用 lineinfile 修改配置文件

服务端通过：

lineinfile:
  path: /etc/exports
  line: "/backup-nfs 192.168.1.0/24(rw,all_squash)"
  create: true

实现自动写入共享配置。

这类用法非常适合：

  • 配置文件中追加固定行
  • 文件不存在时自动创建

4.3 使用 file 模块创建目录并修改属主

file:
  path: /backup-nfs
  owner: nfsnobody
  group: nfsnobody
  state: directory

这一步同时保证了：

  • 目录存在
  • 权限归属正确

4.4 使用 systemd 管理服务顺序

原始笔记特别提醒：

  • 启动 rpcbind 和 nfs 时要注意顺序

先起 rpcbind，再起 nfs，这是 NFS 服务部署中的常见要求。

4.5 使用 mount 模块完成挂载

客户端通过：

mount:
  src: 192.168.1.22:/backup-nfs
  path: /ans-upload
  fstype: nfs
  state: mounted

完成远端共享目录挂载。

mount 模块的优势在于：

  • 比直接写 shell 命令更规范
  • 更容易表达目标状态

五、如何执行剧本

ansible-playbook 04.deploy-nfs.yml

执行完成后，需要分别在服务端和客户端验证结果。

六、如何验证 NFS 自动化部署是否成功

6.1 在 NFS 服务端验证

检查 /etc/exports：

cat /etc/exports

期望看到：

/backup-nfs 192.168.1.0/24(rw,all_squash)

再检查 nfs 服务状态：

systemctl status nfs

只要服务为激活状态，说明服务端部分基本成功。

6.2 在 Web 客户端验证

进入挂载目录创建文件：

cd /ans-upload/
touch 1.txt

然后去 NFS 服务端查看共享目录：

ll /backup-nfs/

如果能看到：

  • 1.txt
  • 属主为 nfsnobody

就说明挂载和共享权限都已经生效。

七、为什么这个案例非常适合练习 Ansible

这个案例比单主机操作更有代表性，因为它同时锻炼了下面几项能力：

  • 多主机组编排
  • 服务端和客户端分角色处理
  • 配置文件自动写入
  • 目录权限自动修正
  • 服务启动顺序控制
  • 挂载结果联动验证

也就是说，它已经很接近“真实批量部署”的雏形。

八、小结

这个 NFS 自动化部署案例最值得掌握的不是某一个模块，而是整体编排思路：

  • 先按角色拆分步骤
  • 再按主机组写不同 Play
  • 用模块表达目标状态
  • 最后通过联动验证确认整条链路生效

当这套思路真正掌握后，后面再去做更复杂的服务部署剧本，就会轻松很多。