跳至主要內容

精读笔记（RHCA 英文教材）· DO447 Chapter 1 Developing with Recommended Practices

大约 7 分钟

精读笔记（RHCA 英文教材）· DO447 Chapter 1 Developing with Recommended Practices

教材原文：RHCA 官方英文教材（教材第 1~21 页）（OCR 整书版已从本站移除，本页为章节精读） 关联知识：02-08-Ansible自动化（RH294DO447）、05-认证考试要点；本系列配套 00-RHCA教材精读-导航与学习法.md

Chapter Goal / Objectives（原文+译）

  • GOAL: Demonstrate and implement recommended practices for effective and efficient Ansible automation.（演示并落地“高效 Ansible 自动化”的推荐实践）
  • OBJECTIVES: ① 描述并演示开发/维护 Ansible 自动化方案的推荐实践；② 用推荐实践在 Git 仓库中创建和管理 Playbook。
  • 结构：两个 Section + 各自 Guided Exercise + Lab Developing with Recommended Practices。

1.1 Implementing Recommended Practices（落地推荐实践）

Describing Ansible Effective Usage（三个要点，源自 Jeff Geerling）

Keep Things Simple · Stay Organized · Test Often 有效使用 Ansible 不是堆特性，而是讲组织与实践。

Keep Things Simple（保持简单）

  • 可读性：多写注释、善用空行、给 play/task 起有意义的名字（一眼看懂“在做什么”）→ 便于排错。
  • 用原生 YAML 语法，不用旧式 module: key=value 折叠写法。反例 service: name=postfix state=started；正例：
    - name: Postfix is running
service:
name: postfix
state: started
  • 优先专用模块（yum/copy/service/template…），少用 command/shell/raw：专用模块更易幂等、更好维护。
  • 显式写 state：别依赖模块默认（如 yum 默认 present），防止 Ansible 后续版本默认行为变化。
  • 统一代码风格：缩进几个空格、空行规范、play/task/role/变量命名、注释风格——团队约定一致。
  • YAML 不是编程语言：复杂控制流写不动时，考虑换思路（Jinja2 过滤器处理数据）而不是硬堆结构。

Stay Organized（保持组织）

  • 命名规范：变量名带所属作用域前缀，例如角色内部变量统一 haproxy_（haproxy_port、haproxy_appservers…），避免变量冲突，也是“namespace（命名空间）”思想。
  • 集中 inventory、用动态清单：单一事实来源 + 自动更新；云/容器/虚机场景最合适。无法动态时可用 group_by 按 fact 临时分组：
    - name: Generate dynamic groups based on architecture
group_by:
key: arch_{{ ansible_facts['architecture'] }}
  • 分组维度建议：地域（region/DC）、环境（dev/staging/prod）、站点或服务（web/app/db 角色）。 ⚠️ 主机属于多个组时会继承所有组变量；同一变量多组冲突时后加载的覆盖，需特别小心设计。
  • Roles 复用：角色要单一职责、通用化并通过变量配置（不改角色代码复用于不同 playbook）；用 ansible-galaxy init 初始化结构；可选用 redhat-system-roles（官方支持）或社区 Galaxy 角色（质量参差需甄别）；角色放项目 roles/ 目录。
  • 集中控制节点运行：所有 playbook 从一台专用控制机跑，便于审计权限；管理员个人账号 + SSH key + sudo，离职即撤销；进阶方案是 Ansible Tower（本课程后半部分）。

Test Often（频繁测试）

  • 校验任务结果：别只信返回码，用 register + failed_when 校验真实状态，例如网页测试：
    - name: Check web site from web server
uri:
url: http://{{ ansible_fqdn }}
return_content: yes
register: example_webpage
failed_when: example_webpage.status != 200
  • block/rescue 做恢复回滚（类似 try/catch）：block 里失败 → 执行 rescue 重启服务恢复。
  • 用最新版 Ansible 常测：提前发现弃用/变化；弃用警告一般提前 4 个 minor 版本发出；关注官方 Porting Guides。
  • 测试工具链： | 工具/命令 | 作用 | | --- | --- | | ansible-playbook --syntax-check | 只查语法不执行 | | ansible-playbook --check | 检查模式：对真机演练“会改什么”；个别任务可 check_mode: no 强制照跑 | | ansible-lint | 静态审查 playbook 潜在问题 | | yamllint | 检查 YAML 语法问题 |

Guided Exercise 要点（lab: development-practices）

把既有项目改成推荐实践：角色变量统一加 haproxy_ 前缀并同步模板 → defaults/main.yml 放默认值 → mkdir group_vars && cp appservers.yml group_vars/lb_servers.yml 用组变量覆盖后端列表 → 新增 [region_eu] 组 + group_vars/region_eu.yml 覆盖 webapp_message → ansible-playbook site.yml → curl 对比默认/欧洲内容 → ansible-playbook clean.yml 还原 → lab development-practices finish。

1.2 Managing Ansible Project Materials Using Git

Infrastructure as Code（基础设施即代码）

  • 不再手工管理基础设施，而是“跑自动化代码来定义/构建系统”；Ansible 项目就是代码 → 必须用 Git 版本控制，才能支持 dev → QA → prod 的生命周期：分支上提交→非生产环境测试→合入主分支→应用到生产。

Introducing Git（DVCS 基础）

  • Git 是分布式版本控制系统：每次修改成为 commit，可恢复旧版、对比差异、留审计日志、多人协作合并。
  • 四个区域（figure）：working tree（工作区）→ staging area/index（暂存区）→ local repository（本地仓库）→ remote repository（远程仓库）。
  • 创建仓库：克隆现成仓库 git clone git@git.lab.example.com:project.git；全新项目 git init；服务器共享用 git init --bare（裸仓库无工作区，只存历史，供 push/pull）。

Initial Git Configuration

  • git config --global user.name 'Peter Shadowman'、git config --global user.email peter@host.example.com（存 ~/.gitconfig，commit 署名用）。
  • 可选：启用 git-prompt.sh 让 bash 提示符显示分支与脏状态：(branch *) 有修改未暂存、(branch +) 已暂存、(branch %) 有未跟踪文件、可组合如 (branch *+)。

The Git Workflow（日常流程）

  1. git status：看 modified/untracked/staged 状态（dirty vs clean）。
  2. git add 文件：把改动放入暂存区（stage）。
  3. git commit：把暂存内容提交成 commit。
  4. git push：推送到远程；git pull：拉取并合并远程变更。
  • commit 的组成：40 位 SHA-1 十六进制唯一 ID；改动文件与精确 diff；parent commit ID；author/committer；references（分支/标签都是指向 commit 的命名指针）。
  • 提交信息：简明有意义（summary + why），保持清晰历史，参照 chris.beams.io 的 How to Write a Git Commit Message。

Branches and References（分支）

  • git branch feature/1：从当前 HEAD 创建分支引用；git checkout feature/1：切分支（HEAD 移动）。
  • 开发/修复在分支并行 → 完成后 git checkout master + git merge feature/2 合并；两边改同一处会 merge conflict，需手工编辑解决（本课不展开）。
  • git checkout -b feature/2：一步“建+切”；git tag tag/1.0：给关键 commit 打标签，之后可 git checkout tag/1.0 回到该点。
  • 新分支默认只在本地：git push --set-upstream origin feature/2（或 -u）推上去并建立跟踪，之后该分支 git push/git pull 直达远程。

Structuring Ansible Projects in Git（目录规范）

  • 每个 Ansible 项目一个独立 Git 仓库，结构遵循官方 Best Practices，示例：
    site.yml # 主 playbook，include 各层 playbook
webservers.yml # 分层 playbook（web 层）
dbservers.yml # （db 层）
roles/
webserver/
tasks/main.yml # 任务（可 include 其他文件）
defaults/main.yml # 低优先级默认变量
templates/httpd.conf.j2
files/motd
handlers/main.yml # handlers
meta/main.yml # 角色元信息/依赖
library/ # 自定义模块（可选）
filter_plugins/ # 自定义过滤器（可选）
  • 角色单独建仓库：多人/多项目共享的角色若各自拷一份会分叉；不推荐 Git submodule（难管理）。
  • 推荐：项目里留空 roles/ + README 说明，运行前用 ansible-galaxy 从角色 Git 仓库拉最新版本；在项目 .gitignore 写 roles/*/*，避免把角色内容误提交。

Guided Exercise 要点（lab: my_webservers_DEV）

git clone 项目 → 按最佳实践补 group_vars/host_vars 与角色 → 分支 development 上提交（含 Jinja2 模板改版）→ git push --set-upstream origin development → 修改角色名并全项目同步引用（如 my_role → apache）→ 补 play 摘要性 names → 提交推送到 master → ansible-playbook 验证 → lab development-review finish。

命令速查表

场景命令
语法检查ansible-playbook --syntax-check playbook.yml
演练（check mode）ansible-playbook --check playbook.yml
静态审查ansible-lint playbook.yml、yamllint playbook.yml
角色初始化ansible-galaxy init 角色名
拉取角色ansible-galaxy install -r requirements.yml
Git 身份git config --global user.name/user.email
克隆/新建git clone URL / git init / git init --bare
日常提交git status → git add . → git commit -m "msg"
同步远程git push / git pull
分支git branch 名字、git checkout -b 名字、git merge 分支、git tag 标签
查看历史git log、git show 提交ID

核心词汇表

英文中文速记
recommended practices推荐实践（简单/组织/测试）
idempotent幂等（重复执行结果不变）
register / failed_when注册变量 / 失败条件校验
deprecation notice弃用提示（提前 4 个 minor 版本）
check mode / syntax check演练模式 / 语法检查
group_by按 fact 动态分组模块
host variables inheritance主机变量继承（后加载覆盖）
central control node集中控制节点
infrastructure as code (IaC)基础设施即代码
distributed version control分布式版本控制
staging area (index)暂存区
bare repository裸仓库（无工作区）
HEAD / reference / tag当前提交指针 / 引用 / 标签
merge conflict合并冲突（需手工解决）
--set-upstream (-u)建远程分支并建立跟踪
submodule子模块（角色共享不推荐）
.gitignore忽略规则文件（roles//）

本章自测

  1. 有效使用 Ansible 的三句话是什么？2. 为什么优先专用模块而非 command/shell？3. 组变量冲突时哪个值生效？4. 用哪两条命令做语法检查与演练？5. register+failed_when 解决什么问题？6. Git 四个区域及 add/commit 的作用？7. 裸仓库与普通仓库区别？8. 为什么角色不要用 submodule 管理？9. roles/*/* 写在哪个文件里、作用是什么？