标签用来切执行范围
标签是给任务、块、角色、play 贴的名字，运行时按名字挑选要执行的部分：只跑配置类任务、跳过破坏性步骤、单独重跑某一层。它的价值在长剧本里尤其明显——整份剧本跑一次要十几分钟，但只想改一个配置片段时，靠标签能把范围压到几秒钟，同时避免重复执行有风险的动作。
基本信息
| 贴标签位置 | 任务、块、角色引用、play 都可以带标签，含在块或角色上的标签会作用于其内部任务 |
|---|---|
| 选择执行 | 命令行按标签筛选执行或跳过标签，两者可同时使用 |
| 特殊标签 | 有一个总是执行的保留标签，用于收集事实与安全检查类任务，具体名称以官方文档为准 |
| 清单预览 | 只看剧本里有哪些标签，便于决定筛选条件 |
| 继承关系 | 块与角色的标签会向下传递到内部任务 |
| 命名建议 | 按“层次”而不是按“偶尔用途”命名，避免标签爆炸 |
典型使用场景
- 只改配置：日常调参只跑配置相关标签，跳过安装与初始化步骤
- 跳过危险操作：常规执行时排除重建、清空数据这类标签
- 分层验证：先跑基线标签，再跑业务标签，逐步放开
- 排障重跑：只重跑某个子系统的标签，避免整份剧本重来
- 多团队分工：平台组与业务组各自认领自己的标签范围
- 灰度习惯化：把“先跑检查类标签、再跑变更类标签”固化成流程
打标签与筛选
打标签与筛选
- hosts: web
roles:
- role: common
tags: [baseline] # 角色级标签会传递给它内部所有任务
- role: nginx
tags: [web, nginx]
tasks:
- name: 下发配置
ansible.builtin.template:
src: app.conf.j2
dest: /etc/app/app.conf
tags: [config] # 任务级标签
- name: 重建索引（有风险，默认跳过）
ansible.builtin.command: /usr/local/bin/rebuild-index.sh
tags: [rebuild, never] # 保留标签：默认不执行，需显式指定
# 用法
# ansible-playbook -i inventory site.yml --list-tags # 看有哪些标签
# ansible-playbook -i inventory site.yml --tags config # 只跑配置
# ansible-playbook -i inventory site.yml --skip-tags rebuild # 跳过重建
# ansible-playbook -i inventory site.yml --tags web,config # 多个标签取并集标签设计对照
| 设计方式 | 优点 | 问题 |
|---|---|---|
| 按层次（基线、配置、发布） | 范围清晰，任何剧本都能复用同一套筛选口径 | 需要团队先约定层次划分 |
| 按组件（nginx、mysql） | 定位到具体子系统，适合排障 | 组件数量增长后标签迅速膨胀 |
| 按动作风险（重建、清空） | 可以一键排除危险操作 | 风险等级会随场景变化，需定期复核 |
| 按环境（生产、测试） | 表面直观 | 环境本就该由清单区分，用标签容易混乱 |
| 万能标签（all、通用） | 写起来省事 | 失去筛选意义，等同没打标签 |
保留标签中的“默认不执行”那一类很适合包裹危险动作：平时全量执行不会碰到它，需要时显式指定标签才会运行。这比靠注释提醒可靠得多。
筛选执行会跳过未选中的任务，其中可能包含前置条件（创建目录、安装包）。跳过的前置步骤缺失时，后续任务会以难以理解的方式失败。用标签切范围前，先确认被跳过的部分不会成为必要条件。
怎么避免标签失控
标签混乱的根源是随用随加。可行做法是先在团队内定三到五类固定标签（例如基线、配置、发布、验证、危险操作），新增标签必须能归入某一类；再定期用清单预览检查是否有长期无人使用的标签，清理掉。标签数量稳定，筛选口径才会稳定。