一、为什么大剧本需要拆分¶
原始笔记把 include 文件包含放在 Jinja2 之后介绍，但它本质上解决的是另一个问题：
- 剧本越来越大，不容易阅读
- 一个剧本中混杂多个主机组和多个步骤，可读性变差
- 调试和维护成本越来越高
这在真实环境里非常常见。尤其当同一个服务既有服务端任务，又有客户端任务时，剧本很容易膨胀。
二、include_tasks 想解决什么问题¶
原始笔记中明确给出的思路是：
- 把一个大的剧本拆成多个小剧本
- 再通过
include_tasks把这些小剧本组合起来使用
这带来的好处主要有：
- 阅读更清晰
- 调试更方便
- 后续修改某一部分时影响范围更小
三、这个案例为什么选择 NFS¶
原始笔记仍然沿用了前面 NFS 部署案例，因为它天然包含两类任务：
- NFS 服务端部署
- NFS 客户端部署
这正好适合演示“拆分为多个任务文件”的效果。
四、拆分后的剧本结构长什么样¶
原始笔记把整个 NFS 部署剧本拆成了三部分：
18-1.deploy-nfs-server.yml：服务端任务18-2.deploy-nfs-client.yml：客户端任务18-3.deploy-nfs-all.yml：总剧本，负责引入前两个文件
这是一种非常典型的组织方式：
- 任务逻辑分开
- 编排入口保留一个总文件
五、服务端任务文件怎么写¶
原始笔记中的服务端子剧本如下：
- name: 01. 部署nfs-utils, rpcbind
yum:
name: nfs-utils,rpcbind
state: present
tags:
- 01.install
- name: 02. 修改配置文件
lineinfile:
path: /etc/exports
line: "/backup-nfs 192.168.1.0/24(rw,all_squash)"
create: true
tags:
- 02.conf
- name: 03. 创建共享目录并更改所有者
file:
path: /backup-nfs
owner: nfsnobody
group: nfsnobody
state: directory
tags:
- 03.dir
- name: 04. 启动服务rpcbind, nfs(注意顺序)
systemd:
name: "{{ item }}"
enabled: yes
state: started
loop:
- rpcbind
- nfs
tags:
- 04.start_service
注意这里的内容是“任务列表”，而不是完整 Play，因为它后面会被总剧本包含进来。
六、客户端任务文件怎么写¶
原始笔记中的客户端子剧本如下：
- 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
和服务端文件一样，它也是纯任务片段，准备被上层剧本引用。
七、总剧本如何组合多个子文件¶
原始笔记中的总剧本如下：
- hosts: nfs
tasks:
- include_tasks: 18-1.deploy-nfs-server.yml
- hosts: web
tasks:
- include_tasks: 18-2.deploy-nfs-client.yml
这里的关键点在于：
- 总剧本仍然负责定义
hosts - 具体任务则拆分到独立文件中
这样剧本结构就从“一个大文件”变成了“一个入口 + 多个子任务文件”。
八、这种拆分方式的实际价值是什么¶
通过这个案例，可以明显看出 include_tasks 的几个优点：
8.1 可读性提升¶
服务端和客户端逻辑彻底分开后，阅读时不会互相干扰。
8.2 维护更清晰¶
如果以后只改 NFS 服务端逻辑，只需要修改：
18-1.deploy-nfs-server.yml
而不会影响客户端部分。
8.3 更适合团队协作¶
当剧本规模变大时，不同人可以分别维护不同文件，比所有人都改同一个大文件更安全。
九、如何验证拆分后的剧本¶
原始笔记中使用了模拟执行：
ansible-playbook -C 18-3.deploy-nfs-all.yml
这说明拆分后仍然推荐：
- 先用检查模式验证整体组合是否正确
如果总剧本能够顺利加载并显示对应任务，说明 include_tasks 的组织方式已经生效。
十、小结¶
include_tasks 的价值，不在于“语法本身有多复杂”，而在于它能帮你把越来越大的剧本拆成更容易维护的结构。
可以把它的使用场景总结成一句话：
- 当一个服务的部署任务越来越多、主机角色越来越复杂时，就该考虑拆分。
对于中大型 Ansible 项目来说，这种“总剧本 + 子任务文件”的组织方式几乎是走向规范化维护的必经之路。