Ansible03-变量、事实、Roles 与模板
Ansible 变量、事实、Roles 与模板
目录
- 为什么变量和复用如此重要
- 变量的定义方式
- 变量插值与引用
- 事实变量（Facts）
- 魔法变量（Magic Variables）
- 自定义事实（facts.d）
- 变量优先级
- Jinja2 模板与 template 模块
- 变量在条件与遍历中的运用
- Roles 角色：目录结构与复用
- 集合（Collections）与 ansible-galaxy
- 总结
- 参考资料
0. 为什么变量和复用如此重要
自动化中真正让 Ansible 强大的不是「能跑一条命令」，而是一份配置能在不同机器上产生不同结果——一台装 A、一台装 B，一台用 8080 端口、一台用 9090。这一切依靠变量。
第二篇中已出现 {{ item }}、when: ansible_os_family 这类「会变的值」，但其来源、种类与优先级尚未系统说明。本篇前半完整讲解这套变量体系（定义方式、插值、事实、魔法变量、优先级），并补上第二篇预告的 Jinja2 模板。
而当 Playbook 变长，「安装 nginx」这类逻辑会在多个剧本中重复出现，此时需要 Roles（角色） 将其抽象为可复用模块。本篇后半讲解 Roles 与集合，使自动化升级为「模块化、可复用」。
一、变量的定义方式
变量可以有多种定义方式，各有适用场景。这一章逐一介绍，先建立整体认识。
1.1 在 Playbook 顶部 vars 定义
最简单直接的方式，写在 play 的 vars 下：
---
- name: 使用变量
hosts: webservers
vars:
app_port: 8080
app_name: myapp
tasks:
- name: 打印变量
debug:
msg: '应用 {{ app_name }} 运行在端口 {{ app_port }}'
1.2 用 vars_files 从外部文件加载
当变量很多时，从外部文件加载更清爽：
vars_files:
- vars/common.yml
vars/common.yml 里就是普通的键值对（YAML）。适合把配置与 Playbook 分离，不同环境（开发/生产）各自维护一份变量文件。
1.3 在 Inventory 中定义（group_vars / host_vars）
在 Inventory 同目录下建 group_vars/、host_vars/ 目录，文件名对应组名/主机名：
inventory/
├── inventory.ini
├── group_vars/
│ └── webservers.yml # webservers 组的变量
└── host_vars/
└── web1.yml # web1 主机的变量
group_vars/webservers.yml：
app_port: 8080
nginx_docroot: /usr/share/nginx/html
这是生产里最常见的变量组织方式：公共配置放
group_vars（按组），单机差异放host_vars（按主机），Playbook 保持简洁。
1.4 在清单里直接写（INI / YAML 两种）
INI 格式（主机行后跟变量、组用 [组名:vars]）：
node1 MYSQL_VERSION=9.3 MYSQL_MASTER=true
[web]
node1
node2
[web:vars]
HTTPD_VERSION=2.4
[all:vars]
SYSTEM_TYPE=RHEL
YAML 格式（更结构化）：
all:
children:
web:
hosts:
node1:
MYSQL_VERSION: 9.3
node2: {}
vars:
HTTPD_VERSION: 2.4
vars:
SYSTEM_TYPE: RHEL
清单里写变量适合「随主机走」的连接参数（如
ansible_user）或按组分的少量配置。复杂配置建议用group_vars/host_vars目录，更清晰。
1.5 命令行 -e / --extra-vars 临时覆盖
ansible-playbook -i inventory.ini playbook.yml -e 'app_port=9090'
ansible-playbook -i inventory.ini playbook.yml -e '{"app_port": 9090, "app_env": "prod"}'
-e是最「临时」的传参方式，优先级也最高（见第 6 章），适合灰度、演练时临时改参数。
1.6 set_fact：运行时动态生成变量
前面讲的变量大多在写 Playbook 时就确定了。实战中经常要根据运行结果现场算出新变量——用 set_fact：
- name: 读取某配置文件里的端口号
command: grep -oP 'port=\K[0-9]+' /etc/app.conf
register: port_raw
- name: 把解析出的端口存成变量，供后续任务使用
set_fact:
app_port: "{{ port_raw.stdout }}"
app_env: prod
- name: 用这个变量部署
copy:
dest: /etc/app.conf
content: "port={{ app_port }}"
set_fact 关键特性：
- 运行时计算：可引用
register的结果、facts、其它变量做加工，也可直接赋固定值； - 主机级作用域：设置后只在当前主机的后续任务可见（配合
hostvars[某主机].变量可在别的主机读到，见第 4 章）； - 与
register的区别：register只是临时保存某条任务的返回结果，set_fact是显式定义一个真正的变量，语义更清晰、便于跨任务复用。二者常配合用。
register复习：register: result把某个任务（如command）的输出保存为变量，之后可用result.stdout、result.rc等引用。
二、变量插值与引用
定义好变量后，怎么把它「用」到任务参数、模板、条件里？这一章讲插值与引用语法。
2.1 基本插值 {{ 变量 }}
在任务参数、模板、when、loop 中都能用 {{ 变量名 }}：
- name: 用变量作为 copy 参数
copy:
dest: '/etc/nginx/conf.d/{{ app_name }}.conf'
content: 'port={{ app_port }}'
参数值建议用引号包住（如
'{{ app_port }}'），避免类型歧义。以{{开头的值必须加双引号，否则 YAML 会把它当字典/列表解析报错。
2.2 字典和列表的引用
YAML 字典/列表的引用，用点号 . 或方括号 []：
# 假设变量
# db:
# host: 10.0.0.1
# port: 3306
msg: "db is {{ db.host }}:{{ db.port }}"
# 列表按下标
# backends: [web1, web2, web3]
first: "{{ backends[0] }}"
2.3 方括号 [] 动态键
当键名本身是变量时，用方括号（键会被当作变量求值）：
- name: 测试
hosts: localhost
vars:
netcard: ens18
tasks:
- name: 用动态键
debug:
msg: "{{ ansible_facts[netcard].ipv4.address }}"
这里 [netcard] 里的 netcard 会被当成变量求值（得到 ens18），实际取的是 ansible_facts.ens18.ipv4.address。
注意：
{{ ansible_facts['ens18'] }}里的'ens18'带了引号，是字面量，不会被当变量。想「先求值变量再当键」就用不带引号的[netcard]。
2.4 双引号与转义
在 YAML 里用 {{ }} 时，若值以 {{ 开头，必须用双引号包住整个值；若值中间夹杂其它字符串则更灵活。遇到 {{ 或 {% 开头的段落，统一用双引号最省心。
三、事实变量（Facts）
3.1 什么是 Facts
事实（facts） 是 Ansible 自动从被管端收集的系统信息（操作系统、IP、内存、CPU 等），以 ansible_ 开头的变量形式存在。Playbook 默认会自动收集（gather_facts）。
用 setup 模块查看（filter 过滤）：
# 查看所有 facts
ansible -i inventory.ini web1 -m setup
# 只查看系统族
ansible -i inventory.ini web1 -m setup -a 'filter=ansible_os_family'
# 查看发行版和主版本
ansible -i inventory.ini web1 -m setup -a 'filter=ansible_distribution_major_version'
3.2 常用 Facts
| fact 变量 | 含义 |
|---|---|
ansible_os_family |
系统族：RedHat 或 Debian |
ansible_distribution |
发行版：Rocky/Ubuntu/Debian 等 |
ansible_distribution_major_version |
主版本号 |
ansible_default_ipv4.address |
默认 IPv4 地址 |
ansible_hostname |
主机名 |
ansible_memtotal_mb |
总内存（MB） |
ansible_processor_cores |
CPU 核心数 |
ansible_date_time |
当前时间（字典） |
3.3 在 Playbook 中使用 Facts
- name: 按系统类型执行
debug:
msg: '这是 {{ ansible_distribution }} {{ ansible_distribution_major_version }}，属于 {{ ansible_os_family }} 系'
- name: 仅 RedHat 系装 epel
dnf:
name: epel-release
state: present
when: ansible_os_family == 'RedHat'
RHEL/Debian 差异在 Playbook 中的落地：用
when: ansible_os_family == 'RedHat'/== 'Debian'即可让同一 Playbook 自动适配两系（yum vs apt）。这是 Ansible 处理跨发行版的标准方式。
3.4 关闭/开启 facts 收集
默认每个 play 会自动收集 facts（较慢）。不需要时可关闭提升性能：
- name: 快速任务，不需要 facts
hosts: all
gather_facts: false # 关闭自动收集，加快执行
tasks:
- name: 执行
command: uptime
注意：关了
gather_facts后，ansible_os_family这类事实变量就不可用了（除非手动setup或gather_subset）。需要 facts 做条件判断时就别关。
四、魔法变量（Magic Variables）
4.1 什么是魔法变量
魔法变量（magic variables，官方叫 Special Variables） 是 Ansible 自动提供的一组变量，反映「当前运行状态」——当前主机在清单里的名字、所属的组、所有主机的信息、配置文件路径等。它们不需要定义、也不能手动设置，直接就能用。
4.2 最常用的几个魔法变量
| 魔法变量 | 作用 |
|---|---|
inventory_hostname |
当前正在处理的主机在清单里的名字 |
hostvars |
一个字典，包含所有主机及其变量（用于跨主机取信息） |
group_names |
当前主机所属的所有组名（列表） |
groups |
一个字典：所有组名 -> 组内主机列表 |
inventory_dir |
当前主机首次定义所在的 inventory 目录 |
inventory_file |
当前主机首次定义所在的 inventory 文件名 |
playbook_dir |
当前 playbook 所在目录 |
role_name |
当前正在执行的角色名 |
ansible_play_hosts_all |
当前 play 目标的所有主机 |
ansible_limit |
本次运行 --limit 的值 |
查看：
ansible all -m debug -a 'var=inventory_hostname'
ansible all -m debug -a 'var=group_names'
ansible all -m debug -a 'var=hostvars'
4.3 在 Playbook 中使用魔法变量
- name: 打印当前主机信息
hosts: all
tasks:
- name: 用魔法变量
debug:
msg: "主机 {{ inventory_hostname }} 属于组 {{ group_names }}"
跨主机取信息（经典用法）：在一个 play 里读另一台主机的变量或 facts：
- name: 主节点读所有从节点的 IP
hosts: master
tasks:
- name: 打印所有节点
debug:
msg: "node1 的 IP 是 {{ hostvars['node1'].ansible_default_ipv4.address }}"
4.4 魔法变量 vs 事实变量：关键区别
这是新手最容易混淆的地方：
| 事实变量（Facts） | 魔法变量（Magic/Special） | |
|---|---|---|
| 内容 | 被管端采集的系统信息（CPU、内存、IP、系统版本…） | 运行状态信息（清单里的主机名、所属组、配置路径…） |
| 来源 | 从被管端采集 | 由控制端的清单/配置确定 |
| 是否随被管端改变 | 会（机器配置变了，facts 变） | 不会（清单怎么写就是什么） |
| 能否跨主机用 | 不能（无法在 A 主机用 B 主机的 facts） | 能（可用 hostvars[主机名].变量 跨主机读） |
一句话：事实变量来自被管端、只反映本机；魔法变量来自清单/配置、可跨主机用。例如在 server2 上用
hostvars.server1.inventory_hostname能得到 server1 的名字，这是魔法变量；但没法在 server2 上直接用 server1 的 CPU 事实。
五、自定义事实（facts.d）
除 Ansible 自动收集的 facts 外，也可以自定义事实。在被管端的 /etc/ansible/facts.d/ 目录下放置以 .fact 结尾的文件（INI 或 JSON 格式），下次收集时 Ansible 会以 ansible_local 命名空间读入。
被管端放一个自定义事实文件：
# 在被管端创建
mkdir -p /etc/ansible/facts.d
cat > /etc/ansible/facts.d/install.fact <<'EOF'
[install]
install_date=2024-08-04
EOF
控制端读取：
ansible web1 -m setup -a 'filter=ansible_local'
在 Playbook 中使用：
- name: 打印自定义事实
debug:
msg: "安装日期 {{ ansible_local.install.install_date }}"
用途：被管端是「生产/测试/开发」环境、属于哪个项目、维护人是谁等自定义信息。生产里常用来给主机打「环境标签」，配合
when做环境差异化。
六、变量优先级
变量有这么多定义方式，同名时谁说了算？这一章讲优先级——Ansible 里最容易困惑、也最影响排错的一环。
6.1 优先级从高到低（官方顺序）
Ansible 的变量有严格优先级，同名变量时高优先级覆盖低优先级。从高到低（简化版，日常够用）：
- 命令行
-e/--extra-vars（最高，永远赢） set_fact/ 缓存的事实（运行时设的）include_vars/vars_files- play 里的
vars host_vars/group_vars目录（host_vars优先于group_vars）- inventory 里直接写的变量
- role 的
defaults（最低，最容易被覆盖）
完整官方列表更细（还有 role 的
vars、vars_prompt等位置），但上表覆盖了 95% 的日常场景。核心记忆：-e最高，role defaults 最低。
6.2 为什么这样设计：默认值放低处，临时覆盖放高处
- 低优先级处放「默认值 / 公共值」：整组共用的
app_port放group_vars，role 的默认值放defaults/——它们易被覆盖，适合当兜底； - 中优先级放「Playbook 内固定值」：
vars、vars_files是写死在剧本里的业务配置； - 高优先级放「运行时临时值」：命令行
-e优先级最高，因为命令行是运维临时改参数、做灰度/演练最顺手的地方。
6.3 同名变量覆盖的实际例子
假设到处都定义了 app_port：
group_vars/webservers.yml: app_port: 8080 # 优先级低，先被设上
playbook 里 vars: app_port: 9090 # 覆盖成 9090
命令行 -e 'app_port=7070' app_port: 7070 # 最高，最终生效 7070
# 不传 -e：group_vars 的 8080 被 vars 的 9090 覆盖 → 输出 9090
ansible-playbook -i inventory.ini playbook.yml
# 传 -e：-e 的 7070 再覆盖 vars → 输出 7070
ansible-playbook -i inventory.ini playbook.yml -e 'app_port=7070'
排错时若发现变量值与预期不符，应按优先级链自上而下排查：是否存在更高优先级位置定义了同名变量。用
debug: var=app_port打印核实最直观。
七、Jinja2 模板与 template 模块
变量体系介绍完毕，即可将其用于配置文件渲染——这是第二篇预留的内容。Jinja2 是 Python 的模板引擎，Ansible 借其实现模板渲染：在模板中写入变量占位与逻辑，渲染时将变量替换进去，生成最终配置。template 模块把渲染结果写到被管端。
简单理解：模板 = 配置文件 + 变量占位符。写一份模板，就能为不同主机生成不同配置（IP、端口、主机名按需填充）。这就是「一份配置在不同机器上产生不同结果」的终极落地方式。
7.1 基本语法
变量输出：{{ 变量 }}
server_name {{ app_name }};
listen {{ app_port }};
逻辑控制：{% ... %}
{% if env == 'prod' %}
log_level: warn
{% else %}
log_level: info
{% endif %}
{% for host in nginx_backends %}
server {{ host }}:{{ app_port }};
{% endfor %}
过滤器 filters：用 | 对变量做处理
| 过滤器 | 作用 | 示例 |
|---|---|---|
default(x) |
变量不存在/为空时给默认值 | `{{ app_port |
upper / lower |
转大写 / 小写 | `{{ name |
trim |
去掉首尾空白 | `{{ name |
length |
求长度 | `{{ backends |
join(',') |
把列表拼成字符串 | `{{ backends |
过滤器可以链式使用：
{% set log_dir = app_name | default('myapp') | upper | trim %}
log_path: /var/log/{{ log_dir }}/app.log
{% set %} 定义变量、{% if x is defined %} 判空：
{% if log_level is defined %}
log_level: {{ log_level }}
{% else %}
log_level: info
{% endif %}
7.2 模板里的变量从哪来？
这是新手最容易懵的一点。模板中出现的变量（app_port、app_name 等）并非模板自带，而是渲染时由 Ansible 注入的。来源就是前面几章讲的整套变量体系：
- Playbook 的
vars/vars_files； - Inventory 的
group_vars/host_vars、清单内变量； - 被管端自动收集的 facts（
ansible_*）； register/set_fact运行时产生的变量；- 命令行
-e传入的变量。
模板能直接用任何在当前主机上可见的变量——这也是同一份模板在不同主机渲染结果不同的原因（各主机 facts 不同、所在组变量不同）。
若模板用了某变量却渲染成空或报
undefined，多半是：变量名拼错、只在别的组定义、或根本没定义。回 Playbook 用debug打印确认。
7.3 template 模块用法
模板文件通常以 .j2 结尾，放在 templates/ 目录：
- name: 渲染 nginx 配置
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
owner: root
mode: '0644'
notify: restart nginx
一个完整的模板示例 templates/nginx.conf.j2：
server {
listen {{ app_port }};
server_name {{ app_name }};
location / {
proxy_pass http://backend_pool;
}
}
upstream backend_pool {
{% for h in nginx_backends %}
server {{ h }}:{{ backend_port }};
{% endfor %}
}
template与copy的区别：copy把文件原样复制/写入；template会先渲染 Jinja2（处理{{ }}/{% %}）再写。需要变量化的配置用template，纯静态文件用copy。
八、变量在条件与遍历中的运用
变量最常见的两个用途，是配合**条件（when）与遍历（loop）**实现差异化动作。第二篇已介绍基础语法，此处补充变量视角的进阶用法，避免重复基础内容。
8.1 when 条件速查（第二篇的补充）
第二篇讲了 == 判断。这里补全常用的判断类型：
| 条件 | 示例 |
|---|---|
| 等于（字符串） | ansible_machine == "x86_64" |
| 等于（数字） | ansible_distribution_major_version == 8 |
| 大于 / 小于 | ansible_memfree_mb > 1024 |
| 不等于 | ansible_memfree_mb != 1024 |
| 变量存在 | custom_var is defined |
| 变量不存在 | custom_var is not defined |
| 在列表里 | ansible_distribution in supported_distros |
| 布尔为真/假 | var / not var |
| 组合 | a is defined and b == 'x'、c or (d and e) |
when 也支持列表（多个条件都满足才执行）：
when:
- my_var is defined
- my_var == 'abc'
8.2 列表变量与字典变量
列表（数组）：有序集合，按下标访问。
list_var1:
- var1
- var2
- var3
list_var2: ["var4", "var5", "var6"]
字典（hash/map）：键值对集合，可嵌套。
dict_var1:
var7: 7
var8: "eight"
混合：列表里放字典、字典里放列表。
# 列表里每个元素是字典
users:
- name: alice
shell: /bin/bash
- name: bob
shell: /bin/bash
# 字典里每个值是列表
dict_var:
web_ports:
- 80
- 8080
db_ports:
- 3306
8.3 遍历复杂结构（进阶）
第二篇讲了 loop 的基础用法（item、item.key/item.value）。当列表里每个元素是带多个字段的字典时，item.字段名 取各字段：
- name: 批量创建用户（列表里每个元素是字典）
user:
name: "{{ item.name }}"
shell: "{{ item.shell }}"
state: present
loop: "{{ users }}"
遍历字典（item.key/item.value）：
- name: 按字典建目录
file:
path: "/data/{{ item.key }}"
state: directory
mode: "{{ item.value }}"
loop:
web: "0755"
db: "0700"
旧写法
with_items/with_dict已被淘汰，新版本统一用loop。
九、Roles 角色：目录结构与复用
9.1 为什么需要 Roles
当 Playbook 越来越大、任务越来越多，全部写在一个文件里难以维护和复用。Roles（角色） 把「一类功能」（如安装并配置 nginx、管理用户、部署应用）封装成标准的目录结构，可以复用、分享、组合。
9.2 Roles 的标准目录结构
roles/
└── nginx/ # 角色名
├── tasks/
│ └── main.yml # 主任务文件（必选，会先执行）
├── handlers/
│ └── main.yml # 处理器
├── templates/
│ └── nginx.conf.j2 # 模板文件
├── files/
│ └── index.html # 静态文件（copy 用）
├── vars/
│ └── main.yml # 角色变量（优先级较高）
├── defaults/
│ └── main.yml # 默认变量（优先级最低，易被覆盖）
├── meta/
│ └── main.yml # 角色元数据/依赖
└── README.md
tasks/main.yml是角色入口，其它目录按需存在。标准角色有 7 个常用目录：tasks、handlers、templates、files、vars、defaults、meta。
9.3 在 Playbook 中使用 Roles
---
- name: 部署 Web 服务器
hosts: webservers
become: true
roles:
- common
- nginx
角色执行时，其 tasks/main.yml 依次执行，可访问角色目录下的 defaults/vars 变量和 templates/files 资源。角色可以组合（先 common 再 nginx）。
9.4 角色示例：一个 nginx 角色
roles/nginx/tasks/main.yml：
---
- name: 安装 nginx
yum:
name: nginx
state: present
when: ansible_os_family == 'RedHat'
- name: 安装 nginx（Debian）
apt:
name: nginx
state: present
when: ansible_os_family == 'Debian'
- name: 部署配置
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
notify: restart nginx
- name: 启动并开机自启
service:
name: nginx
state: started
enabled: true
roles/nginx/handlers/main.yml：
---
- name: restart nginx
service:
name: nginx
state: restarted
roles/nginx/defaults/main.yml（默认变量，易被覆盖）：
---
nginx_port: 80
nginx_server_name: localhost
角色里的
defaults（默认值，优先级最低）适合放「可被调用方覆盖」的变量；vars（角色变量，优先级较高）放「角色内部固定」的值。这与第 6 章的优先级设计呼应。
9.5 角色内任务拆分
角色 tasks/main.yml 可以用 import_tasks/include_tasks 引用子任务文件，把「安装」「配置」「启动」拆到独立文件，角色更清晰：
# roles/nginx/tasks/main.yml
---
- import_tasks: install.yml
- import_tasks: config.yml
- import_tasks: service.yml
9.6 ansible-galaxy：角色的初始化与下载
ansible-galaxy 是 Ansible 的角色/集合仓库与工具：
# 初始化一个角色的标准目录骨架
ansible-galaxy init myrole
# 搜索/安装社区现成角色
ansible-galaxy search nginx
ansible-galaxy install geerlingguy.nginx
# 按 requirements.yml 批量安装
ansible-galaxy install -r requirements.yml --roles-path ./roles
生产环境常直接复用 Ansible Galaxy 上维护良好的角色（如 geerlingguy 系列），避免从零手写。
ansible-galaxy init能快速生成标准目录骨架。
十、集合（Collections）与 ansible-galaxy
10.1 什么是集合（Collection）
集合（collection） 是现代 Ansible 组织模块/角色/插件的分发单元。它以命名空间.集合名 形式存在：
ansible.builtin：内置模块（装 ansible-core 就有，无需额外安装）；ansible.posix、community.general、community.docker、community.mysql等：扩展集合，需安装。
装完整版
ansible包时会预装一大批常用集合；装ansible-core则只有ansible.builtin，要扩展得自己ansible-galaxy collection install。
10.2 安装与查看集合
# 安装集合
ansible-galaxy collection install ansible.posix
ansible-galaxy collection install community.general
# 查看已安装的集合
ansible-galaxy collection list
# 从文件批量安装
ansible-galaxy collection install -r requirements.yml
10.3 调用集合里的模块
调用时要写完整命名空间：
- name: 使用集合里的模块
community.general.ufw:
rule: allow
port: 22
state: enabled
安装集合后，集合内的角色、模块都以
命名空间.集合名.模块名调用。官方文档的模块页顶部会标明它属于哪个集合、是否需要安装。
10.4 requirements.yml（声明依赖）
团队协作时，用一个 requirements.yml 声明需要的角色和集合，别人拉下来即可复现环境：
# requirements.yml
collections:
- name: ansible.posix
- name: community.general
roles:
- name: geerlingguy.nginx
ansible-galaxy install -r requirements.yml
十一、总结
11.1 本篇要点回顾
- 变量定义：
vars、vars_files、group_vars/host_vars、清单内、-e、set_fact；register拿任务结果、set_fact定义正式变量。 - 插值：
{{ }}引用、./[]访问字典列表、[]动态键；以{{开头的值要加双引号。 - 事实变量（Facts）：自动收集的被管端信息，
ansible_开头，用when做跨发行版判断。 - 魔法变量（Magic）：
inventory_hostname/hostvars/group_names等，来自清单/配置、可跨主机用；与事实变量的区别是「来源与能否跨主机」。 - 自定义事实：被管端
/etc/ansible/facts.d/*.fact→ansible_local，用于环境标签等。 - 变量优先级：
-e最高，roledefaults最低；默认值放低处、临时值放高处。 - Jinja2 模板：
{{ }}变量、{% %}逻辑、|过滤器；template渲染、copy原样复制；模板里的变量来自整套变量体系。 - Roles：7 个标准目录封装复用；
ansible-galaxy init生成骨架。 - 集合（Collections）：现代 Ansible 的分发单元，
ansible-galaxy collection install安装，命名空间.集合名.模块名调用。
11.2 下一步
至此涵盖变量、事实、魔法变量、Jinja2 模板、Roles 与集合，可实现「按主机差异化渲染、模块化复用」的自动化。这些能力可与验证排错、become 提权、ansible-vault 加密、端到端实战及 ansible-navigator/执行环境等生产级手段配合使用，构成完整的生产 Ansible 自动化（见《Ansible 实战、安全与滚动发布》）。
参考资料
- Ansible 变量：https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html
- Ansible 特殊变量（魔法变量）：https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html
- Ansible 事实与 setup 模块：https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html
- 自定义事实：https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_vars_facts.html
- Ansible 模板（Jinja2）：https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_templating.html
- Ansible Roles：https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_reuse_roles.html
- Ansible Collections：https://docs.ansible.com/ansible/latest/collections_guide/index.html
- Ansible Galaxy：https://docs.ansible.com/ansible/latest/galaxy/user_guide.html