📚 课程目录第2章 Ansible基础回顾

Ansible 基础回顾：架构、核心组件与无代理优势

在深入配置环境一致性检查与发布健康度之前，有必要重新梳理 Ansible 的核心设计理念。Ansible 之所以能在配置管理、应用部署与任务编排领域占据主流地位，根本原因在于其无代理（Agentless）架构与声明式自动化模型。本节将聚焦架构分层、三大核心组件以及无代理模式带来的运维红利。

1. Ansible 整体架构分层

Ansible 采用典型的控制节点（Control Node）到受管节点（Managed Node）的星型拓扑。控制节点安装 Ansible 引擎，通过 SSH（Linux/Unix）或 WinRM（Windows）与受管节点通信，无需在受管节点上预装任何代理软件。

  架构要点： 控制节点是唯一需要安装 Ansible 的主机；受管节点只需 Python 2.7+/3.5+（Windows 需 PowerShell 3.0+）即可被管理。

2. 三大核心组件详解

Ansible 的功能由 Inventory、Playbook 和 Module 三大组件协同完成。理解它们的分工是编写可靠自动化脚本的前提。

组件	作用	关键特征	示例
Inventory	定义受管节点列表及分组	支持静态 INI/YAML 文件或动态云脚本	`webservers: [host1, host2]`
Playbook	声明式编排任务序列	YAML 格式，幂等执行，支持变量/条件/循环	`tasks: - name: Install nginx`
Module	执行具体操作（系统/网络/云）	内置 1000+ 模块，可自定义	`ansible.builtin.copy`

3. Inventory：受管节点清单

Inventory 是 Ansible 的“通讯录”，定义哪些主机受管以及如何连接。生产环境中通常使用静态文件或动态 Inventory 脚本（如 AWS EC2、OpenStack）。

# 静态 Inventory 示例（INI 格式）
[web_servers]
web01 ansible_host=192.168.1.10
web02 ansible_host=192.168.1.11

[db_servers]
db01 ansible_host=192.168.1.20

[all:vars]
ansible_user=deploy
ansible_ssh_private_key_file=/home/deploy/.ssh/id_rsa

最佳实践： 将 Inventory 纳入版本控制，并使用 ansible-inventory --graph 命令可视化主机分组关系，便于审计环境一致性。

4. Playbook：自动化剧本

Playbook 是 Ansible 的核心编排文件，采用 YAML 语法描述“期望状态”。每个 Playbook 由一个或多个 Play 组成，每个 Play 针对特定主机组执行一系列 Tasks。

---
- name: 确保 Web 服务器配置一致
  hosts: web_servers
  become: yes
  vars:
    nginx_port: 8080
  tasks:
    - name: 安装 Nginx
      ansible.builtin.apt:
        name: nginx
        state: present

    - name: 配置 Nginx 端口
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: restart nginx

  handlers:
    - name: restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

幂等性陷阱： 并非所有模块天然幂等。使用 command 或 shell 模块时，需配合 creates、changed_when 等参数确保重复执行不产生副作用。

5. Module：原子操作单元

Module 是 Ansible 实际执行工作的“螺丝刀”。每个模块独立完成一项操作（如复制文件、安装包、启动服务），并返回 JSON 格式的执行结果。Ansible 内置 1000+ 模块，覆盖系统、网络、云、数据库等领域。

模块类别	常用模块	典型用途
文件操作	`copy`, `template`, `file`	分发配置文件、创建目录、设置权限
包管理	`apt`, `yum`, `pip`	安装/卸载软件包
系统服务	`service`, `systemd`	启动/停止/重启服务
命令执行	`command`, `shell`	执行自定义命令或脚本
云资源	`ec2`, `gcp_compute`	创建/销毁云主机

6. 无代理架构的核心优势

与 Puppet、Chef、SaltStack 等传统配置管理工具相比，Ansible 的无代理（Agentless）设计带来了显著的运维收益。以下从五个维度进行对比：

维度	Ansible（无代理）	传统工具（有代理）
部署复杂度	零部署：仅控制节点安装，受管节点无需额外软件	需在每台受管节点安装/注册代理，版本管理复杂
安全攻击面	仅依赖 SSH/WinRM，无额外端口或守护进程	代理进程常监听端口，增加暴露风险
资源占用	受管节点零常驻进程，仅在任务执行时消耗资源	代理持续占用 CPU/内存，影响业务负载
升级维护	仅升级控制节点，受管节点无版本兼容问题	需逐台升级代理，版本不一致易导致功能异常
网络要求	控制节点出站 SSH/WinRM，无需入站端口	代理需与控制节点双向通信，防火墙规则复杂

  运维启示： 在配置环境一致性检查场景中，无代理架构意味着你可以直接对现有服务器集群执行“健康度扫描”，无需提前安装任何软件，极大降低了审计门槛和风险。

7. 小结：架构选择对配置一致性的影响

Ansible 的无代理架构使其在配置环境一致性检查场景中具备天然优势：

快速接入： 无需在现有服务器上安装任何软件，直接通过 SSH 执行检查任务。
低风险审计： 只读操作（如 setup 模块收集 Facts）不会影响生产环境。
版本统一： 控制节点单一版本，避免因受管节点代理版本差异导致检查结果不一致。
易于集成： 可嵌入 CI/CD 流水线，在发布前自动执行环境健康度扫描。