一、Playbook 基本结构

Ansible Playbook 由一个或多个 Play 组成，每个 Play 定义：

• 目标主机
• 是否提权
• 要执行的任务列表

---
- name: Example play
  hosts: web
  become: true
  tasks:
    - name: Example task
      module_name:
        option: value

常见字段说明

字段	说明
name	描述信息，仅用于可读性
hosts	目标主机或主机组
become	是否使用 sudo/root
tasks	任务列表，按顺序执行

---

二、dnf 模块：安装软件包

用于在 RHEL 系列系统上安装或升级软件。

- name: Install httpd
  ansible.builtin.dnf:
    name: httpd
    state: present

常用 state

state	含义
present	确保已安装
latest	安装或升级到最新版本

---

三、service 模块：管理系统服务

用于启动、停止服务以及设置开机自启。

- name: Ensure httpd running
  ansible.builtin.service:
    name: httpd
    state: started
    enabled: true

参数说明

参数	作用
state	控制当前状态
enabled	控制是否开机自启

记忆点：

state 管现在，enabled 管将来

---

四、copy 模块：部署文件

拷贝文件

- name: Deploy index.html
  ansible.builtin.copy:
    src: files/index.html
    dest: /var/www/html/index.html

直接写入内容（常用于测试）

- name: Create test page
  ansible.builtin.copy:
    content: "Welcome to intranet\n"
    dest: /var/www/html/index.html

---

五、firewalld 模块：防火墙配置

- name: Open http service
  ansible.posix.firewalld:
    service: http
    state: enabled
    permanent: true
    immediate: yes

参数说明

参数	含义
service	firewalld 服务名
permanent	是否写入永久规则
immediate	是否立即生效

注意区分：

• http：防火墙服务名（端口 80）
• httpd：Apache 服务名

---

六、http / httpd / PHP 的关系

基本区分

名称	作用
http	HTTP 协议 / firewalld 服务
httpd	Apache Web 服务进程
PHP	服务器端脚本语言

请求处理流程

浏览器
  ↓ HTTP 请求
Apache(httpd)
  ↓ 发现 .php 文件
PHP 解释执行
  ↓
生成 HTML
  ↓ HTTP 响应
浏览器

---

七、部署 PHP 页面

- name: Test php page is installed
  ansible.builtin.copy:
    src: index.php
    dest: /var/www/html/index.php

说明：

• index.php 位于控制节点
• 放在 Apache 文档目录
• 用于验证 PHP 是否被正确解析

---

八、uri 模块：验证 Web 服务

基本验证

- name: Connect to web server
  ansible.builtin.uri:
    url: http://servera.lab.example.com
    status_code: 200

含义：

• Web 服务可访问
• HTTP 返回码必须为 200

---

return_content 的含义

return_content: yes

• 将 HTTP 响应正文保存到任务结果中
• 不会自动输出到终端

---

显示页面内容的方法

- name: Connect to web server
  ansible.builtin.uri:
    url: http://servera.lab.example.com
    return_content: yes
  register: web

- name: Show page content
  ansible.builtin.debug:
    msg: "{{ web.content }}"

---

九、为什么 Playbook 成功但没显示网页？

• uri 模块主要用于验证
• 默认不负责输出内容
• debug 才用于打印结果

理解要点：

uri 用来判断是否成功
debug 用来显示具体内容

---

十、部署 + 验证的推荐结构

- name: Deploy web service
  hosts: servera
  become: true
  tasks:
    - 安装软件
    - 启动服务
    - 配置防火墙

- name: Test web service
  hosts: localhost
  become: false
  tasks:
    - 使用 uri 验证服务

---

核心分层逻辑（基础结构）

一个健壮的 “部署 + 验证” 流程应分为 4 个核心逻辑层，按执行顺序排列：

• 前置检查层：部署前先验证目标环境（如依赖、权限、磁盘空间），提前规避无效部署；
  部署执行层：核心的部署操作（如拷贝文件、安装包、启动服务）； 结果验证层：部署后立即验证核心功能（如端口监听、服务状态、接口可用性）；
  异常补救层：验证失败时执行回滚 / 告警，确保系统不处于 “半部署” 的异常状态。
• 基于 block 的结构化封装（核心推荐）
  利用block/rescue/always实现分层管控，推荐结构如下：
  （1）外层 block：封装完整的 “部署 + 验证” 流程
  block段：包含 “前置检查 + 部署执行 + 结果验证” 全流程（验证失败视为 block 整体失败）；
  rescue段：验证失败 / 部署失败时的补救操作（如回滚版本、重启旧服务、发送告警）；
  always段：无论成功 / 失败，都执行的收尾操作（如记录日志、清理临时文件）。
  （2）内层细分：验证任务独立封装
  验证环节建议单独嵌套block，并为验证任务设置failed_when（自定义失败判定规则），避免因单个验证点误判导致流程终止；同时验证任务需设置超时机制（如wait_for的timeout），防止无限等待。

- 关键设计原则

验证要 “精准且全面”：
验证维度需覆盖核心指标（服务进程存在、端口监听、业务接口返回 200、日志无错误）；
避免 “假验证”（如仅检查进程名，不检查端口；仅检查端口，不检查业务可用性）；
验证任务需设置合理超时（如网络验证超时 10-30 秒），并明确失败判定条件。
失败判定要 “显式化”：
验证任务通过failed_when自定义失败规则（如接口返回非 200 则判定失败），而非依赖模块默认状态；
部署 / 验证任务不滥用ignore_errors，仅在非核心步骤使用，确保核心失败能触发 rescue。
状态可追溯：
在always段记录部署 / 验证的完整状态（如成功 / 失败、执行时间、目标主机）；
利用ansible_failed_task/ansible_failed_result在 rescue 段记录失败详情，便于问题定位。
幂等性保障：
部署和验证任务都需保证幂等（重复执行不破坏系统状态），比如用service模块而非command启动服务，用wait_for而非shell检查端口。

• 执行优先级与容错逻辑
  前置检查失败 → 直接触发 rescue（无需执行部署）；
  部署执行失败 → 跳过后续验证，直接触发 rescue；
  部署成功但验证失败 → 触发 rescue（核心逻辑：验证失败 = 部署失败）；
  所有步骤成功 → 跳过 rescue，执行 always 收尾；
  rescue 内的补救操作需保证 “最小影响”（如回滚仅恢复到上一个可用版本，而非全量重装）。
  - 进阶优化
  验证任务并行化：非依赖的验证项（如端口检查 + 日志检查）可通过async/poll异步执行，缩短验证耗时；
  多级验证：分 “基础验证”（服务启动）和 “业务验证”（接口调用），基础验证失败直接回滚，业务验证失败可尝试重试；
  告警集成：rescue 段中加入邮件 / 钉钉 / 企业微信告警，及时通知运维人员；
  版本记录：部署前记录当前版本，便于 rescue 段精准回滚。

总结

• 分层封装：用block将 “前置检查 - 部署 - 验证” 封装为核心逻辑，rescue处理异常，always做收尾；
  精准验证：验证任务覆盖核心指标，自定义失败规则，设置超时，避免假验证和误判；
  容错兜底：验证 / 部署失败时触发回滚 /
  告警，确保系统不处于异常状态，同时保留完整的执行日志。

十一、总结

• Playbook 描述的是系统的期望状态
• 模块具备幂等性
• 验证步骤同样属于自动化的一部分
• Ansible 更接近状态管理工具，而不是脚本工具