ansible的assert模块用于部署前环境基线校验，通过布尔表达式结合ansible_facts动态断言核心条件，失败即中止；需覆盖硬件资源、系统版本、服务状态、权限等硬性要求，任务应含清晰说明、fail_msg提示及合理生命周期嵌入。
Ansible 的 assert 模块是部署前做环境基线校验最直接、最轻量的方式——它不改配置，只做判断；断言失败即中止，避免后续操作在不合规环境中执行。关键在于把“应该满足什么条件”转化为可执行的布尔表达式，并结合 Ansible 事实（ansible_facts）动态取值。
明确要断言的基线项
不是所有检查都适合用 assert，优先覆盖影响部署成败或安全合规的核心硬性条件：
- 硬件资源：内存不足、交换空间过小、磁盘容量不够会导致 Oracle、K8s 或中间件安装直接失败
- 系统版本与发行版：如必须为 Rocky Linux 8.9+，而非 CentOS 7；避免因内核模块或 PAM 行为差异导致加固失败
- 基础服务状态：SSH 必须运行且监听 22 端口，Python 3.6+ 必须可用（Ansible 运行依赖）
-
关键目录/用户权限：如
/u01目录需存在且属主为oracle，/etc/shadow权限必须为000或600
编写可读、可追溯的 assert 任务
每个 assert 任务应包含清晰的条款说明、具体检查逻辑和明确的失败提示，便于审计与排障：
- 用
that:列出全部布尔条件，每行一个，避免长表达式嵌套 - 通过
ansible_distribution、ansible_distribution_version、ansible_memtotal_mb等内置变量获取实时信息 - 用
fail_msg写明违反哪条基线要求（例如“等保2.0 8.1.2.1：操作系统应启用日志审计功能”），而不是泛泛说“检查失败” - 可选加
success_msg做正向确认，增强可观测性
示例（验证 Oracle 部署前置条件）：
- name: Validate OS and resource baseline for Oracle 19c
assert:
that:
- ansible_distribution == "Rocky"
- ansible_distribution_version | version_compare('8.9', '>=')
- ansible_memtotal_mb >= 4096
- ansible_swaptotal_mb >= 6144
- (ansible_mounts | selectattr('mount', 'equalto', '/u01') | list | length) == 1
fail_msg: "Failed baseline check: Requires Rocky Linux 8.9+, 4GB RAM, 6GB swap, and mounted /u01"
success_msg: "OS and resource baseline OK"
与 Playbook 生命周期协同使用
assert 不是孤立任务，需嵌入合理位置才能发挥最大效用：
- 放在整个 Play 的
pre_tasks区域，确保所有主机在执行任何配置前先过统一门槛 - 若某角色（role）有专属依赖（如 PostgreSQL 角色要求
hugepages已配置），可在该 role 的tasks/main.yml开头加局部 assert - 配合
--check模式运行时，assert 仍会执行并报错，因此可安全用于预检流程 - 生产环境建议搭配
--limit先单台验证，再全量执行
进阶：组合 facts + shell + assert 做复杂判断
当内置变量不够用时，可用 command 或 shell 模块采集自定义指标，注册结果后在 assert 中引用：
- 例如检查 auditd 是否启用：
command: systemctl is-active auditd→ 注册为auditd_status→ 在 assert 中写auditd_status.stdout == "active" - 检查特定端口是否被占用：
command: ss -tln | grep ':22'→ 验证 SSH 端口监听状态 - 注意：shell 类任务需设
changed_when: false，避免误标为变更，干扰幂等性
