Ansible 进阶 – Roles 与 Inventory 的高效组织

如果说 Playbook 是一份完整的“菜谱”，那么 Role (角色) 就可以被看作是制作这道菜（或一桌菜）所需的标准化“备料包”或“半成品组件”。例如，我们可以有一个“Nginx Web 服务器安装配置 Role”、“MySQL 数据库基础设置 Role”、“通用安全加固 Role”等。每个 Role 封装了实现特定功能所需的所有任务、变量、配置文件模板、处理器等，可以被多个 Playbook 方便地调用和复用。

Ansible Roles：代码的组织与复用

什么是 Role？

Role 是 Ansible 中一种预定义的、标准化的目录结构，用于组织与特定功能或服务相关的所有自动化内容。它包含了：

Tasks (任务)：实现该角色功能的主要任务列表。
Handlers (处理器)：当特定任务状态改变时被触发的动作。
Variables (变量)：与该角色相关的变量。
Defaults (默认变量)：为角色提供的默认变量值，优先级最低，很容易被覆盖。
Files (静态文件)：角色执行时需要拷贝到目标节点的静态文件。
Templates (模板文件)：角色执行时需要渲染并拷贝到目标节点的 Jinja2 模板文件。
Meta (元数据)：描述角色的信息，如作者、依赖关系等。

使用 Roles 的核心好处是模块化、可复用性、以及促进项目结构的标准化，使得复杂的 Playbook 更易于理解和维护。

Role 目录结构

一个标准的 Ansible Role 通常具有以下目录结构：

rolename/
├── tasks/             # 存放此角色要执行的主要任务文件 (核心是 main.yml)
│   └── main.yml
├── handlers/          # 存放此角色定义的处理器 (核心是 main.yml)
│   └── main.yml
├── defaults/          # 存放此角色的默认变量 (核心是 main.yml) - 优先级最低
│   └── main.yml
├── vars/              # 存放此角色特定的变量 (核心是 main.yml) - 比 defaults 优先级高
│   └── main.yml
├── files/             # 存放此角色需要分发的静态文件 (如脚本、二进制文件)
│   └── some_script.sh
├── templates/         # 存放此角色需要渲染的 Jinja2 模板文件 (如配置文件模板)
│   └── config_file.conf.j2
├── meta/              # 存放此角色的元数据 (核心是 main.yml)
│   └── main.yml       # 例如，可以定义角色依赖 (dependencies)
└── README.md          # (可选) 角色的说明文档

每个目录下的 main.yml (或 main.yaml) 文件是该目录的默认入口文件。

如何创建 Role

手动创建目录结构：按照上述结构手动创建文件夹和 main.yml 文件。
使用 ansible-galaxy init 命令 (推荐)：Ansible 提供了一个命令行工具 ansible-galaxy 来帮助管理 Roles，包括初始化一个新的 Role 骨架。

命令 (输入):

ansible-galaxy init my_nginx_role

效果 (输出): 这会在当前目录下创建一个名为 my_nginx_role 的文件夹，并包含所有标准的子目录和空的 main.yml 文件，非常方便。

如何在 Playbook 中使用 Role

在 Playbook 中调用一个或多个 Roles 非常简单，通过 roles: 关键字即可。

Playbook 示例 (输入 – YAML):

---
- name: Configure web servers using multiple roles
  hosts: webservers
  become: true
  # roles_path: ["./roles", "/etc/ansible/roles"] # (可选) Ansible 查找 Roles 的路径

  roles: # Play 级别的 roles 列表
    - common_base_setup # 直接写 Role 名称 (Ansible 会在 roles_path 中查找)

    - role: nginx_server # 使用 role 关键字，更清晰，且可以传递参数
      vars: # 传递给 nginx_server Role 的变量
        nginx_listen_port: 8080
        nginx_document_root: /var/www/custom_app

    - {
               role: php_fpm, php_version: "8.1", when: install_php | default(true) } # 另一种写法，并可加条件

解释:

Ansible 会按照 roles: 列表中定义的顺序依次执行每个 Role。
你可以在调用 Role 时通过 vars: (或直接在 - { role: ..., var1: value1 } 中) 传递参数，这些参数会覆盖 Role 内部 defaults/main.yml 中定义的同名变量，甚至可能覆盖 vars/main.yml 中的变量（取决于变量优先级）。
when: 条件也可以用于 Role 的调用。

Ansible Galaxy

简要提一下，Ansible Galaxy (https://galaxy.ansible.com/) 是一个官方的、社区驱动的 Roles 中心仓库。你可以在上面找到大量由社区贡献的、可直接使用的 Roles，也可以分享你自己编写的 Roles。可以使用 ansible-galaxy install <author.rolename> 命令来下载和安装 Galaxy 上的 Roles。

对 SRE 的意义：Roles 是构建可维护、可扩展、可共享的自动化代码库的基石。SRE 经常会创建或使用 Roles 来标准化常见的系统配置（如安全加固、日志收集代理部署）、应用程序的部署流程、中间件的安装配置等。

Inventory 进阶：动态管理与变量优先级

高效管理 Inventory (主机清单) 对于在复杂或动态环境中成功运用 Ansible 至关重要。

静态 Inventory 回顾

我们之前已经见过简单的静态 Inventory 文件格式（INI 或 YAML），它允许我们定义主机、主机组，并为它们分配变量。

# inventory.ini
[webservers]
web01.example.com ansible_user=app_user http_port=80
web02.example.com ansible_user=app_user http_port=81

[dbservers]
db01.example.com use_replica=true

[all:vars] # 应用于所有主机的变量
ntp_server=ntp.internal.com

动态 Inventory (Dynamic Inventory)

问题: 在主机数量频繁变化的环境中（例如，公有云上的虚拟机、自动伸缩组、容器平台），手动维护静态 Inventory 文件变得不切实际。
解决方案: Ansible 支持动态 Inventory。这意味着 Ansible 可以执行一个外部脚本（任何能输出特定 JSON 格式的脚本语言都可以，如 Python, Bash, Go）或使用Inventory 插件来实时地从外部数据源（如 AWS EC2, GCP Compute Engine, Azure VM, VMware vCenter, OpenStack, Cobbler, 自定义 CMDB 等）获取主机列表和相关变量。
工作方式: 当你运行 ansible 或 ansible-playbook 命令并指定一个动态 Inventory 脚本/插件作为 -i 参数时，Ansible 会执行它，并解析其 JSON 输出作为当前的 Inventory 信息。
对 SRE 的意义: 对于管理云基础设施或大规模、动态变化的部署环境，动态 Inventory 是必不可少的，它确保了 Ansible 总能针对最新的主机状态进行操作。

Inventory 变量与优先级

我们可以在 Inventory 中定义变量，以针对不同的主机或主机组应用不同的配置。

定义位置:

主机变量 (Host Variables): 定义在 Inventory 文件中主机名旁边，或者在 host_vars/<hostname_or_ip>.yml 文件中。
组变量 (Group Variables): 定义在 Inventory 文件中组名下方（如 [groupname:vars]），或者在 group_vars/<groupname>.yml 或 group_vars/all.yml 文件中。all 组的变量适用于所有主机。

变量优先级 (Variable Precedence): Ansible 在运行时会从多个来源加载变量（命令行 -e、Playbook vars、Role defaults 和 vars、Inventory 变量、Ansible Facts 等）。这些变量来源有一个明确的优先级顺序，决定了当同一个变量名在不同地方被定义时，哪个值会最终生效。

大致规则: 通常，作用范围越小、越具体的变量定义，优先级越高。例如：

命令行变量 (-e) 优先级最高。
Playbook 中 vars: 定义的变量。
Inventory 主机变量 (host_vars)。
Inventory 组变量 (group_vars，更具体的组优先于 all 组)。
Role 变量 (vars/main.yml)。
Role 默认变量 (defaults/main.yml) 优先级最低。
(Ansible Facts 优先级也比较高，介于 Inventory 变量和 Playbook 变量之间)

重要性: 理解变量优先级对于排查“为什么我的变量没有生效”或“为什么变量的值不是我期望的那个”这类问题至关重要。建议查阅 Ansible 官方文档以获取完整的优先级列表。

对 SRE 的意义: 通过 Inventory 结合变量优先级，SRE 可以用一套 Playbook 和 Roles，灵活地适配不同的环境（开发、测试、生产）、不同的主机角色或不同的客户部署，而无需大量复制和修改核心自动化逻辑。

Playbook 组织最佳实践 (简述)

使用 Git 进行版本控制: 将你所有的 Ansible 代码（Playbooks, Roles, Inventory, 变量文件等）都纳入 Git 管理。
标准项目布局: 遵循推荐的项目目录结构，例如：

ansible_project/
├── inventory/
│   ├── production.ini
│   └── staging.ini
├── group_vars/
│   ├── all.yml
│   └── webservers.yml
├── host_vars/
│   └── specific_host.yml
├── roles/
│   ├── common/
│   └── nginx/
│       └── ... (role structure)
├── playbooks/
│   └── deploy_webapp.yml
└── ansible.cfg (项目级别的 Ansible 配置文件)

保持 Playbook 简洁: 将复杂的、可复用的逻辑抽象到 Roles 中。Playbook 主要负责定义执行目标、调用 Roles 并传递参数。
使用描述性名称: 为 Play, Task, Role, 变量使用清晰、易懂的名称。
编写注释: 解释复杂的逻辑或“为什么”这么做。