Ansible 中前置与后置任务必须定义在 playbook 的 play 级别，pre_tasks 在所有角色执行前运行，post_tasks 在所有角色及 tasks 完成后运行；二者均不可置于角色内部，且执行顺序严格固定。
在 Linux 中为 Ansible 角色配置前置（pre_tasks）与后置（post_tasks）任务，核心是通过 playbook 的结构控制执行时序，而不是在角色内部定义它们。角色本身只负责封装复用逻辑，而顺序调度由调用它的 playbook 主动管理。
前置任务：在所有角色运行前执行
使用 pre_tasks 可以完成环境准备、权限校验、变量初始化等依赖性操作。这些任务会在任何角色加载和执行之前运行，且其触发的 handlers 也优先于角色任务执行。
- 必须写在 playbook 的 play 级别下，与
roles同级 - 支持完整任务语法（
debug、set_fact、command等） - 若其中某个任务
notify了 handler，该 handler 会在所有角色任务开始前运行
后置任务：在角色和普通任务全部完成后执行
post_tasks 适合做收尾验证、日志归档、清理临时文件或通知外部系统。它严格位于 roles 和 tasks 之后，且不受其内部 handlers 影响。
- 同样属于 play 级关键字，不能嵌套在 roles 内部
- 执行时机：所有角色任务 → 所有 tasks 任务 → 它们各自触发的 handlers → 最后才是 post_tasks
- 常用于部署后检查服务端口、生成报告或发送 Slack 通知
实际 playbook 示例结构
一个清晰的执行顺序示意如下：
---
- hosts: web_servers
become: true
pre_tasks:
- name: Ensure time is synced before config
command: chronyc tracking
changed_when: false
<p>roles:</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill8828" title="Obsidian (Linux)"><img
src="https://img.php.cn/upload/skill/000/000/081/179228531040284.jpg" alt="Obsidian (Linux)" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill8828" title="Obsidian (Linux)" class="overflowclass">Obsidian (Linux)</a>
<p class="overflowclass">操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。</p>
</div>
<a rel="nofollow" href="/xiazai/skill8828" title="Obsidian (Linux)" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- role: nginx nginx_port: 8080
- role: firewall firewall_allowed_ports: [8080]
tasks:
- name: Verify nginx config syntax command: nginx -t changed_when: false
post_tasks:
- name: Notify deployment completion debug: msg: "Nginx + firewall deployed successfully on {{ inventory_hostname }}"
注意事项与常见误区
不要试图在角色目录里写 pre_tasks 或 post_tasks —— 它们不是角色的一部分，也不被 meta/main.yml 或 tasks/main.yml 支持。角色只提供可复用的 tasks、handlers、defaults 等；顺序控制权始终在调用方 playbook 手中。
如果多个角色之间存在强依赖（比如必须先跑 A 再跑 B），靠 playbook 中 roles 列表的书写顺序即可保证，无需额外加 pre/post 逻辑。
