ansible角色是大型自动化项目的必备结构，通过标准化目录（如tasks/main.yml、handlers/main.yml）、单一职责划分（如roles/nginx只配nginx）、分层变量管理（加前缀、vault加密）和playbook中roles列表调用，实现可复用、易维护、环境隔离的自动化部署。
用 Ansible 角色（Roles）组织大型自动化项目，核心是把“功能”拆成独立、可复用的单元，再按需组合。它不是锦上添花的技巧，而是项目规模一旦超过 3–5 类服务（比如同时要配 Nginx、MySQL、Redis、监控代理），就必须采用的结构方式——否则 Playbook 很快会变成难以定位、不敢修改的“巨石文件”。
角色目录结构必须标准化
每个 Role 必须放在 roles/ 目录下，子目录名即角色名（如 roles/nginx）。其内部结构是 Ansible 约定俗成的，不能随意改名或省略关键部分：
-
tasks/main.yml：必有，定义该角色的核心任务；其他 .yml 文件可被它 include 进来 -
handlers/main.yml：必有，存放 notify 触发的重启、重载等动作 -
templates/：放 Jinja2 模板文件（如nginx.conf.j2），供template模块使用 -
files/：放静态文件（如证书、脚本），供copy或script模块直接分发 -
vars/main.yml：定义该角色专用变量，优先级高于default/main.yml -
defaults/main.yml：放兜底变量，优先级最低，适合设安全默认值（如nginx_port: 80） -
meta/main.yml：声明依赖关系（如 “本角色需先运行common角色”），也用于 Galaxy 发布
角色之间要明确职责边界
一个角色只做一件事，并且这件事要完整闭环。例如：
-
roles/users：只管创建用户、设 sudo 权限、分发 SSH 公钥，不碰服务或软件包 -
roles/firewall：只配置 iptables 或 firewalld 规则，不改内核参数或启动服务 -
roles/java：只装 JDK、设环境变量、验证java -version，不部署任何 Java 应用
避免出现“roles/lamp”这种大而全的角色——它违反了单一职责，导致复用困难、测试成本高、升级时牵一发而动全身。
在 Playbook 中按逻辑顺序调用角色
Playbook 不再写具体任务，而是用 roles: 列表声明需要哪些角色，并控制执行顺序和条件：
---
- name: 部署 Web 应用集群
hosts: webservers
become: true
vars:
app_version: "2.4.1"
roles:
- common # 基础加固、时区、日志轮转
- users # 创建部署用户和组
- nginx # 安装+配置反向代理
- app-deploy # 拉取代码、渲染配置、授权
- prometheus-node-exporter # 监控探针
也可以用 include_role 实现动态调用或加条件：
include_role: name: mysql when: inventory_hostname in groups['dbservers']include_role: name: redis with_items: "{{ redis_clusters }}"
变量管理要分层清晰
大型项目中变量来源多（inventory、group_vars、host_vars、role defaults、role vars、playbook vars），必须靠层级和命名规范避免冲突：
- 所有角色变量统一加前缀，如
mysql_root_password、nginx_worker_processes - 敏感变量（密码、密钥）不写进 role 的
vars/，统一放在group_vars/all/vault.yml并用 ansible-vault 加密 - 环境差异化配置通过
group_vars/production/和group_vars/staging/分离，角色内只引用变量名
这样，同一套角色代码，只需切换 inventory 分组或变量文件，就能适配开发、测试、生产三套环境。
