跳至主要內容

精读笔记（RHCA 英文教材）· DO447 Chapter 10 Constructing Advanced Job Workflows

大约 12 分钟

精读笔记（RHCA 英文教材）· DO447 Chapter 10 Constructing Advanced Job Workflows

教材原文：RHCA 官方英文教材（教材第 353~400 页）（OCR 整书版已从本站移除，本页为章节精读） 关联知识：上一章 Ch9（Project/Job Template/角色）、Ch8（Inventory/Credential）；Fact/Survey/Workflow/Schedule 全部作用于 Job Template 体系；本系列配套 00-RHCA教材精读-导航与学习法.md 章节结构：10.1 Fact Caching（提速）→ 10.2 Job Template Surveys（变量交互）→ 10.3 Workflow Job Templates（多作业编排）→ 10.4 调度与通知 → Lab Constructing Advanced Job Workflows（project-review）

Chapter Goal / Objectives（原文+译）

  • GOAL: Use additional features of Job Templates to improve performance, simplify customization of Jobs, launch multiple Jobs, schedule automatically recurring Jobs, and provide notification of Job results.（用 Job Template 的进阶特性：提性能、简化定制、一次启动多个作业、定时自动重复、作业结果通知）
  • OBJECTIVES：① 用 Fact Caching 加速作业执行；② 建 Job Template Survey 帮用户更轻松地用自定义变量启动作业；③ 建 Workflow Job Template 把多个 Ansible 作业串成单一工作流启动；④ 配置作业定时执行与完成通知。

10.1 Improving Performance with Fact Caching（用 Fact 缓存提升性能）

为什么要缓存 Facts（考点）

  • facts＝Ansible 在受管主机上自动发现并注入的变量（主机专属信息），可在变量/条件/循环中当普通变量用。
  • 默认每个 play 第一条任务前都会自动跑 setup 模块采集 facts——保证数据新鲜，但大清单下性能代价大。不用 facts 时可 gather_facts: no 关掉。
  • 跨主机引用 facts 用“魔术变量”hostvars：servera 上取 serverb 的 IP → hostvars['serverb']['ansible_facts']['default_ipv4']['address']；前提是 serverb 的 facts 已被本 playbook 采集过。
  • Fact caching 一次解决两个问题：一个 playbook 采集全清单 facts 并缓存 → 后续 playbook 直接复用，不用再 setup / 不用手动跑 setup。

Tower 里的 Fact Cache（3.2+ 内置）

  • Tower 3.2+ 集成 fact cache 与事实缓存数据库；超时在全局管理，开关由 Job Template 控制。
  • 全局超时：Settings → JOBS → Per-Host Ansible Fact Cache Timeout（秒）；默认 0＝缓存永远有效——但若不定时重新采集，主机变化会导致 facts 过期/失真（风险点）。
  • 启用三步：Templates → 编辑目标 Job Template → OPTIONS 勾 Use Fact Cache → SAVE。
  • 配套做法：play 里 gather_facts: no（依赖缓存）+ 定期跑一个“刷新缓存”的 play 保持数据新鲜。刷新 play 最小形态：
    - name: Refresh fact cache
hosts: all
gather_facts: yes # 没有 tasks/roles，唯一动作就是采 facts
    建议分批采集（按主机子集分散负载），关键是在 facts 过期前覆盖全部主机。
  • IMPORTANT（机制考点）：作业启动时 Tower 把本次作业各主机的 ansible_facts 注入 memcache；作业结束后取回记录，只把“更新时间晚于缓存副本”的 fact 写回 fact cache 数据库（增量保存）。

Guided Exercise 1 要点（lab: project-facts）

  1. lab project-facts start；daniel（redhat123）登录。
  2. 让 DEV webservers setup 模板先跑一次——失败：playbook 用了 ansible_distribution fact 的值，但 play 不采 facts、模板也没开缓存 → 该任务报错。
  3. 修 playbook：gather_facts: yes（git pull → 改 → commit “Enabling facts gathering” → push）；模板勾 USE FACT CACHE → 再启动：成功，并把 Dev 清单全部主机 facts 写入缓存。
  4. 再把 playbook 改回 gather_facts: no → push → SCM 更新 → 启动：依然成功且更快——变量值来自缓存，无需再采集。
  5. 验证 facts 已存入 Tower fact cache（对应主机 servera 等）。

10.2 Creating Job Template Surveys to Set Variables for Jobs（用 Survey 为作业设变量）

变量管理背景（考点：vars_prompt 不支持）

  • 鼓励写可复用 playbook，变量值“最好只在一个地方设”，避免变量优先级纠缠。
  • CLI 时代两种交互设值：-e/--extra-vars（优先级最高）与 playbook 里 vars_prompt（低优先级、可被覆盖）。
  • IMPORTANT（考点）：Tower 不支持含 vars_prompt 的 playbook；其替代品就是 Survey。
  • 模板里设 extra variables 的两种方式：① EXTRA VARIABLES 字段直接写 YAML/JSON；② 该字段勾 PROMPT ON LAUNCH，启动时弹窗让用户编辑。
  • 重放（relaunch）注意：重放沿用原 extra vars 且不能改；要改就回原模板用新的 extra vars 再启动。

Survey 概念与规则（考点）

  • Survey＝给 Job Template 加一个“表单”，启动时用友好提问收集信息→设成 extra variables；不懂 Ansible 的人也能安全填。
  • 优先级（IMPORTANT）：Survey 设的值覆盖同名变量的任何其它设值，包括模板 EXTRA VARIABLES 字段与 PROMPT ON LAUNCH 输入——Survey 值即 extra vars，永远优先。（与 vars_prompt 低优先级不同，故二者不是直接替代关系。）
  • 7 种答案类型（考点表）： | ANSWER TYPE | 说明 | | --- | --- | | Text | 单行文本 | | Textarea | 多行文本 | | Password | 当敏感信息处理 | | Multiple Choice (single select) | 单选 | | Multiple Choice (multiple select) | 多选 | | Integer | 整数 | | Float | 浮点数 |
  • 校验规则：非列表类型（Text/Textarea/Password/Integer/Float）可设 MINIMUM/MAXIMUM LENGTH；可设 DEFAULT ANSWER（没填时用）；REQUIRED 勾选=必答。
  • 创建：Survey 只能在 Job Template 创建后添加（创建模板时没有）；Templates → 编辑模板 → ADD SURVEY → 逐题填 PROMPT / ANSWER VARIABLE NAME / ANSWER TYPE /（多选选项）/长度/默认值/REQUIRED → +ADD（下方 PREVIEW 即时预览）→ 顶部 ON/OFF（默认 ON）→ SAVE。
  • 启动流程：先应用模板的 extra vars/prompt-on-launch 值 → 再展示 Survey → Survey 答案覆盖前者。

Guided Exercise 2 要点（lab: project-survey）

  1. lab project-survey start；admin 给 DEV webservers setup 加 Survey：PROMPT=What version are you deploying?、ANSWER VARIABLE NAME=deployment_version、Text、MIN=1/MAX=40、DEFAULT=v1.0、REQUIRED；保存前确认开关 ON。
  2. 改 playbook 模板 index.html.j2 追加 Deployment Version: {{ deployment_version }} <br> → commit “Display Deployment Version on index page” → push → SCM 更新 Project。
  3. daniel 启动该模板 → 弹出 Survey 填版本 → 作业成功；访问 servera/serverb 页面底部出现 Deployment Version: v1.0。

10.3 Creating Workflow Job Templates and Launching Workflow Jobs（创建工作流模板）

为什么需要 Workflow（考点）

  • 复杂操作常需按顺序跑多个 playbook：例：Networking 团队先分配 IP+DNS → 成功后才轮到 Operations 装 OS → 再成功才由 Dev 部署应用；失败还要自动跑恢复 playbook。
  • 手工人肉按序启动易错；Workflow Job Template 把多个 Job Template 串成工作流：由前一步成功/失败决定下一步，可自动做恢复。
  • 启动方式：Web UI 手动、定时作业、外部程序调 Tower API。Workflow 不是简单的串行——用图形编辑器做分支决策。

创建与编辑（考点）

  • 创建前置：带 Organization 的 WJT 需要该组织 Admin 角色；不带 Organization 的 WJT 只有 **System Administrator（singleton）**能建。
  • 创建：Templates → “+” → Workflow Template → NAME +（可选 EXTRA VARIABLES）→ SAVE → 进入 Workflow Visualizer。
  • Visualizer 操作：
    • 起始只有一个 START 节点；点它选资源作为第一步。
    • 可加入的节点类型：Job Template（主节点，无标记）、Project Sync（左下角标 P）、Inventory Sync（标 I）——确保 Project/Inventory 在使用前已更新。
    • 悬停节点：红 − 删除；绿 + 追加后继节点；追加时出现 RUN 选择框，三选一决定父子关系： | RUN 关系 | 含义 | | --- | --- | | On Success | 前驱成功后执行 | | On Failure | 前驱失败后执行 | | Always | 无论成败都执行 |
    • 一个父节点可有多个子节点（如一个 On Success + 一个 On Failure）→ 形成分支决策树；连线颜色：绿=On Success、红=On Failure、蓝=Always。画完点 SAVE。
  • WJT 也可加 Survey：其产生的 extra variables 对工作流内每个作业都可见可用。

启动与查看（考点）

  • 启动需 WJT 上的 Execute 角色：被授予后，即使用户不能单独启动其内部的 Job Templates，也能通过 WJT 启动它们。
  • 启动方式与 JT 相同（Templates → 火箭图标）。
  • 结果页双栏：DETAILS（工作流参数）+ workflow progress（步骤进度图）；每个完成节点轮廓绿/红；步骤间连线绿(On Success)/红(On Failure)/蓝(Always)；节点有 DETAILS 链接可看该子作业输出。

Guided Exercise 3 要点（lab: project-workflow）

  1. lab project-workflow start；admin 建 WJT From Dev to Test（Default / EXTRA VARIABLES deployment_version: "v1.1"）。
  2. Visualizer 编排：START（蓝线 Always）→ My Webservers DEV Project Sync →（绿线 On Success）→ DEV webservers setup →（绿线）→ My Webservers TEST Project Sync →（绿线）→ TEST webservers setup。
  3. 启动：四台主机（servera/b/c/d）页面底部都出现 Deployment Version: v1.1。
  4. ssh root@servera 执行 shutdown -h now 再启动同一工作流：DEV 节点失败 → 整条工作流 Failed（失败节点 DETAILS 显示 servera 不可达）。
  5. 重启 servera（GE 结束）。

10.4 Scheduling Jobs and Configuring Notifications（调度作业与配置通知）

定时执行（考点）

  • 有 Job Template Execute 角色即可为其设置 schedule。
  • 配置：Templates → 目标 JT → 右侧 SCHEDULES → “+” → 填：
    • NAME；START DATE / START TIME；LOCAL TIME ZONE（可用 tzselect 查出标准写法）；REPEAT FREQUENCY：None（只跑一次）/ Minute / Hour / Day / Week / Month / Year（按频率再填细节，如“每 2 天”“每月第一个周日”）。
    • SAVE；用 ON/OFF 随时激活/停用（也可在 Schedules 页集中管理/编辑/删除）。
  • Tower 自带两个管理类定时作业（默认存在，可改时间与保留量）：
    • Cleanup Job Schedule：每周日清理历史作业详情（默认删除 >120 天）以省空间；
    • Cleanup Activity Schedule：每周二清理活动流记录（默认 >355 天）。

作业结果通知（考点）

  • 动机：Tower 集中记录作业历史（审计）；关键作业还要即时告警成功/失败 → Notification Templates。
  • Notification Template：定义“怎么发”的通知模板，属于某个 Organization，创建后可用于该组织内 Job Template / Project / Workflow（也可用于 Project/Inventory 同步等 system job）。
  • 支持机制：Email、Slack、Twilio、PagerDuty、HipChat、Webhook、IRC（开放协议 + 商业方案都有）。
  • Email 型创建：Notifications → “+” → NAME + ORGANIZATION → TYPE=Email → TYPE DETAILS：SENDER EMAIL、RECIPIENT LIST（每行一个）、PORT（SMTP 中继端口；另需 HOST 字段）、可选 SMTP 认证与安全传输 → SAVE。
  • 启用：模板详情 → NOTIFICATIONS → 列出本组织可用通知模板 → 把 SUCCESS / FAILURE 两个开关按需拨 ON。
  • 验证思路：通知模板行内铃铛图标发测试通知；作业完成后收信（示例邮件含作业 #、状态、inventory/project/playbook/credential、逐主机 ok/changed 等 JSON 详情）。

Guided Exercise 4 要点（lab: project-notification）

  1. lab project-notification start（脚本起 SMTP 服务）；admin 建 Email 通知模板 Notify on Job Success and Failure：HOST=localhost、RECIPIENT=student@localhost、SENDER=system@tower.lab.example.com、PORT=25 → 点铃铛验证“Notification sent”。
  2. 在 DEV webservers setup 模板 NOTIFICATIONS 里把 SUCCESS、FAILURE 都拨 ON。
  3. 启动带 deployment_version: "v1.2" 的作业 → ssh tower 后 tail -f /var/mail/student 看到 Job # 成功邮件（含 JSON 明细）→ servera/serverb 页面显示 v1.2。
  4. 按“当前时间 +3 分钟”给该模板建定时作业 Automatic job run（SCHEDULES → “+” → 时间设为 3 分钟后）→ 等待自动执行（GE 结束）。

Lab 要点（lab: project-review，教材第 391~399 页 Performance Checklist）

  1. lab project-review start（建好 Prod 用的仓库/Project/Job Template）。
  2. 给 TEST webservers setup 与 PROD webservers setup 两个模板都勾 Fact Caching。
  3. 建 WJT From Test to Prod：Default / EXTRA VARIABLES deployment_version: "v1.3"；编排：My Webservers TEST Project Sync →（成功）TEST webservers setup →（成功）My Webservers PROD Project Sync →（成功）PROD webservers setup。
  4. 给 WJT 加 Survey（必答）：PROMPT=What version are you deploying?、ANSWER VARIABLE=deployment_version、Text、MIN=1/MAX=40、DEFAULT=v1.0。
  5. 用现有 Notify on Job Success and Failure 模板把 WJT 的 SUCCESS、FAILURE 通知都打开。
  6. 启动 WJT，Survey 里输入 v1.3 → 成功后收邮件通知；验证 serverc/d/e/f 四台页面已更新。
  7. Evaluation：lab project-review grade 修正后重跑至成功。

SUMMARY（教材原话要点 6 条 → 考点归纳）

  • Fact caching 加速作业，但要配套管理 facts 采集（定时刷新防过期）。
  • Survey 让单次启动自动化更友好：提示用户填 playbook 用到的 extra variables（值最高优先级）。
  • Workflow Job Template 可顺序启动多个 Job Template，并按前一步成功/失败分支执行（含自动恢复）。
  • Job Template 可配一次性或周期 schedule；Notification Templates 在作业成功/失败时发通知（多机制）。
  • Tower 提供可浏览的 REST API，易自动化 Tower 运维并与第三方系统集成（下章 Ch11 展开）。

命令速查表

场景操作/命令
全局 fact 超时Settings → JOBS → Per-Host Ansible Fact Cache Timeout（秒，0=永不过期）
模板开缓存Templates → 模板 → OPTIONS → Use Fact Cache
刷新缓存 playgather_facts: yes 且无 tasks 的 playbook（分批定期跑）
加 SurveyTemplates → 模板 → ADD SURVEY → 逐题配置 → +ADD → ON → SAVE
建 Workflow 模板Templates → “+” → Workflow Template → Workflow Visualizer 连线
节点关系绿 + 追加节点，RUN 选 On Success/On Failure/Always（蓝绿红连线）
建通知模板Notifications → “+” → TYPE=Email → SENDER/RECIPIENT/PORT 等
开作业通知模板 → NOTIFICATIONS → SUCCESS/FAILURE 开关 ON
定时作业模板 → SCHEDULES → “+” → 起止时间/时区/频率（None~Year）
管理定时清理Cleanup Job Schedule（周日、>120 天）/ Cleanup Activity（周二、>355 天）
GE / Lablab project-facts / project-survey / project-workflow / project-notification / project-review start|grade|finish
查邮件通知ssh tower → tail -f /var/mail/student

核心词汇表

英文中文速记
facts / setup module自动发现的主机变量 / 采集模块
gather_facts: no关闭自动采集（依赖缓存时用）
hostvars跨主机取 facts 的魔术变量
fact cache事实缓存（Tower 数据库；memcache 中转增量写回）
Per-Host Ansible Fact Cache Timeout全局缓存有效期（默认 0=永不过期）
Use Fact Cache模板 OPTIONS 里的缓存开关
extra variables额外变量（-e；YAML/JSON，优先级最高）
vars_promptplaybook 交互提问（Tower 不支持 → 用 Survey）
Survey作业模板表单（收集 extra vars，值覆盖其它设值）
ANSWER TYPE（7 种）Text/Textarea/Password/单选/多选/Integer/Float
REQUIRED / DEFAULT ANSWER必答 / 默认答案
Workflow Job Template工作流模板（多 JT 按成败分支编排）
Workflow Visualizer图形化编排器（START→节点→连线）
Project Sync / Inventory Sync node工作流内项目/清单同步节点（标 P/I）
On Success / On Failure / Always节点 RUN 关系（绿/红/蓝连线）
schedule定时作业（Execute 角色可设）
REPEAT FREQUENCY重复频率 None~Year
Cleanup Job / Activity ScheduleTower 内置管理清理作业
Notification Template通知模板（Email/Slack/Twilio/PagerDuty/HipChat/Webhook/IRC）
SUCCESS / FAILURE toggle模板上启用成功/失败通知的开关
REST APITower 可浏览 API（自动化与集成）

本章自测

  1. 为什么默认每个 play 都会采 facts？哪些场景下会“白采”？两个“不用事实采集也能拿到事实”的手段是什么？
  2. Tower fact cache 的超时在哪设、默认值是多少、有什么风险？缓存怎么写入（memcache→数据库的时机与条件）？
  3. GE1 的“失败→gather_facts yes→开缓存→再改 no 仍成功”验证了什么结论？
  4. Tower 为什么不支持 vars_prompt？Survey 与它的优先级差异在哪？
  5. Survey 的 7 种答案类型？长度限制适用于哪些类型？REQUIRED 与 DEFAULT ANSWER 各管什么？
  6. 创建 WJT 的权限要求（带/不带 Organization）？Visualizer 里能加哪三类节点？RUN 三选项的连线颜色？
  7. 有 WJT Execute 角色但无内部 JT 权限，能不能启动该 WJT？启动后到哪看每步结果？
  8. 定时作业的 Execute 角色要求与 REPEAT FREQUENCY 取值？Tower 自带哪两个清理调度、各自默认周期与保留天数？
  9. 建 Email 通知模板要填哪些关键字段？怎么让某 Job Template 在成功/失败时都发信？测试通知用哪个图标？
  10. SUMMARY 六条如何对应 Objectives 四条？（提示：REST API 一条没有对应 Objective，为 Ch11 埋伏笔。）用自己的话把 Fact Cache→Survey→Workflow→Schedule/Notify 串成一条“企业级作业流水线”叙述。