Ansible Roles

核心定义 Ansible Roles 是 Ansible 对任务、变量、模板、文件、处理器和依赖关系的标准化封装方式。它通过固定目录结构实现“约定大于配置”，让自动化部署逻辑可复用、可协作、可维护。

1. 为什么需要 Roles

普通 Playbook 适合临时任务或小规模自动化。当部署逻辑变复杂后，所有内容堆在一个 YAML 文件里会出现明显问题：

1. 任务过长：安装、配置、启动、校验都写在同一个文件中，阅读成本高。
2. 复用困难：不同项目需要 Nginx、MySQL、Redis 时，只能复制粘贴任务。
3. 协作混乱：不同成员的目录组织方式不同，维护成本高。
4. 变量分散：默认值、环境变量、敏感变量混在一起，容易误改。
5. 模板和文件难管理：配置模板、静态文件、handler 与任务之间缺少清晰边界。

Roles 的目标是将一个可复用能力封装成标准模块。例如：

nginx role：负责安装、配置、启动、重载 Nginx
mysql role：负责安装、初始化、配置、启动 MySQL
redis role：负责安装、配置、启动 Redis

主 Playbook 只需要声明使用哪些角色，而不需要关心每个角色内部的完整细节。

2. Roles 解决的核心问题

可以将 Role 理解为自动化运维中的“功能包”：一个 Role 负责完成一个清晰边界的部署或配置能力。

3. Roles 标准目录结构

使用以下命令可以创建一个标准 Role：

ansible-galaxy init nginx

生成的典型结构如下：

roles/
└── nginx/
    ├── defaults/
    │   └── main.yml
    ├── files/
    ├── handlers/
    │   └── main.yml
    ├── meta/
    │   └── main.yml
    ├── tasks/
    │   └── main.yml
    ├── templates/
    ├── tests/
    └── vars/
        └── main.yml

常用目录说明：

目录约定 Ansible 会按目录约定自动加载 tasks/main.yml、handlers/main.yml、defaults/main.yml 等文件，因此 Role 调用方通常只需要写角色名。

4. Roles 的自动加载机制

4.1. tasks/main.yml 是默认任务入口

当 Playbook 调用某个 Role 时，Ansible 会默认执行该 Role 的 tasks/main.yml。

- name: 安装 Nginx
  ansible.builtin.yum:
    name: nginx
    state: present

- name: 启动 Nginx
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: true

调用方不需要显式写出 roles/nginx/tasks/main.yml，只需要声明：

- name: 部署 Web 服务
  hosts: web
  roles:
    - nginx

4.2. handlers 按 notify 触发

handlers 用于处理“只有配置变化时才执行”的操作，例如重启或重载服务。

tasks/main.yml：

- name: 渲染 Nginx 配置
  ansible.builtin.template:
    src: nginx.conf.j2
    dest: /etc/nginx/nginx.conf
  notify: Reload nginx

handlers/main.yml：

- name: Reload nginx
  ansible.builtin.service:
    name: nginx
    state: reloaded

只有模板内容发生变化时，Reload nginx 才会在合适阶段被触发，避免每次执行 Playbook 都重启服务。

4.3. templates 自动配合 Jinja2 渲染

templates/ 目录用于保存 .j2 模板。模板可以引用变量：

server {
    listen {{ nginx_port }};
    server_name {{ nginx_server_name }};
}

任务中使用 template 模块渲染：

- name: 渲染站点配置
  ansible.builtin.template:
    src: site.conf.j2
    dest: /etc/nginx/conf.d/site.conf

Ansible 会自动从当前 Role 的 templates/ 目录寻找 site.conf.j2。

5. 变量管理与优先级

5.1. defaults 与 vars 的区别

Role 中最常见的两个变量目录是 defaults/ 和 vars/。

示例 defaults/main.yml：

nginx_port: 80
nginx_worker_processes: auto
nginx_server_name: localhost

调用方可以在 inventory、group_vars、host_vars 或 Playbook 中覆盖这些默认值。

5.2. 推荐变量分层

生产环境推荐将变量按职责分层：

敏感变量不要明文放入 Role 密码、Token、私钥等敏感信息不应直接写入 defaults/、vars/ 或模板文件，应使用 Ansible Vault 或外部密钥系统管理。

6. Role 的调用方式

6.1. 使用 roles 字段调用

最常见方式：

- name: 部署 Web 服务
  hosts: web
  become: true
  roles:
    - nginx

如果需要传入变量：

- name: 部署 Web 服务
  hosts: web
  become: true
  roles:
    - role: nginx
      nginx_port: 8080
      nginx_server_name: example.com

6.2. 使用 import_role 静态导入

import_role 是静态导入，Playbook 解析阶段就会展开 Role。

- name: 静态导入 nginx role
  ansible.builtin.import_role:
    name: nginx

适合结构固定、希望提前解析和校验的场景。

6.3. 使用 include_role 动态包含

include_role 是动态包含，运行到该任务时才加载 Role。

- name: 按条件动态加载 nginx role
  ansible.builtin.include_role:
    name: nginx
  when: install_nginx | bool

适合需要配合条件、循环或运行时决策的场景。

6.4. 三种调用方式对比

7. Role 依赖与 meta

meta/main.yml 可以声明当前 Role 依赖的其他 Role。

dependencies:
  - role: common
  - role: firewall

当执行当前 Role 时，Ansible 会先处理依赖角色。

适用场景：

1. 所有服务部署前都需要基础初始化 Role。
2. 应用 Role 依赖 JDK、Node.js、Python 等运行时 Role。
3. 中间件 Role 依赖通用用户、目录、内核参数配置。

依赖关系不宜过度复杂，否则会让执行顺序难以排查。大型项目中更推荐在主 Playbook 中显式编排关键 Role 顺序。

8. Role 设计最佳实践

8.1. 单一职责

一个 Role 应只负责一个清晰的能力边界。

单一职责可以让 Role 更容易复用、测试和排查。

8.2. 保持幂等性

Ansible 任务应尽量做到重复执行不会产生副作用。

- name: 确保 Nginx 已安装
  ansible.builtin.yum:
    name: nginx
    state: present

避免使用没有判断条件的裸命令：

- name: 不推荐：每次都执行编译安装
  ansible.builtin.shell: ./install.sh

如果必须使用 shell 或 command，应结合 creates、removes、changed_when 等控制幂等性。

8.3. 使用 handlers 控制重启

服务重启、重载等操作应通过 handler 触发，而不是每次任务执行都直接重启。

- name: 更新配置文件
  ansible.builtin.template:
    src: app.conf.j2
    dest: /etc/app/app.conf
  notify: Restart app

这样只有配置确实变化时才会重启服务。

8.4. 模板与变量分离

模板中只保留结构，差异通过变量注入。

listen_port={{ app_port }}
log_level={{ app_log_level }}

不同环境通过 group_vars/prod.yml、group_vars/test.yml 等文件维护变量，避免为每个环境复制一份模板。

9. 常见项目结构

生产项目通常会将 inventory、group_vars、playbook 和 roles 分开管理。

ansible-project/
├── inventories/
│   ├── prod/
│   │   └── hosts.ini
│   └── test/
│       └── hosts.ini
├── group_vars/
│   ├── prod.yml
│   └── test.yml
├── roles/
│   ├── common/
│   ├── nginx/
│   ├── mysql/
│   └── redis/
└── site.yml

site.yml 示例：

- name: 基础初始化
  hosts: all
  become: true
  roles:
    - common

- name: 部署 Web 层
  hosts: web
  become: true
  roles:
    - nginx

- name: 部署数据库层
  hosts: db
  become: true
  roles:
    - mysql

10. Ansible Galaxy

Ansible Galaxy 是 Role 和 Collection 的共享平台，可以安装社区已有角色。

ansible-galaxy role install geerlingguy.nginx

也可以使用 requirements.yml 固定依赖：

roles:
  - name: geerlingguy.nginx
    version: 3.2.0
  - name: geerlingguy.mysql
    version: 4.3.4

安装：

ansible-galaxy role install -r requirements.yml

第三方 Role 使用注意 生产环境使用第三方 Role 前，应审查任务内容、变量默认值、权限操作、服务重启逻辑和版本固定方式，避免引入不可控变更。

11. 普通 Playbook 与 Roles 对比

12. 常见误区

12.1. 一个 Role 做太多事情

Role 过大会变成新的“大 Playbook”。应按职责拆分，例如 common、nginx、mysql、redis、docker。

12.2. 把所有变量都放进 vars

vars/main.yml 优先级较高，不适合放需要被环境覆盖的配置。可配置项优先放入 defaults/main.yml。

12.3. 不使用 handlers

配置文件变化后直接在任务中重启服务，会导致每次执行 Playbook 都重启。应使用 notify + handlers。

12.4. 第三方 Role 不固定版本

直接安装 latest 版本可能导致后续执行结果变化。生产环境应使用 requirements.yml 固定版本。

13. 面试回答模板

标准回答 Ansible Roles 是 Ansible 对自动化任务的标准化封装方式，用固定目录结构组织 tasks、handlers、templates、files、defaults、vars、meta 等内容。调用 Role 时，Ansible 会自动加载 tasks/main.yml、defaults/main.yml、handlers/main.yml 等约定入口。Roles 解决了普通 Playbook 在复杂场景下结构混乱、复用困难、团队协作不统一的问题。生产环境设计 Role 时应遵循单一职责、变量分层、幂等性、handlers 按需触发和版本固定等原则。

关联文档

• Ansible：Ansible 自动化工具的整体入口。
• 容器技术：理解 Roles 在容器化部署、环境初始化中的应用场景。
• CI-CD：理解 Roles 与流水线自动化部署的关系。