企业官网建设流程全解析

1. 项目概述：为什么条件判断和 block 是 Ansible 真正“活”起来的关键

Ansible 不是 Shell 脚本的简单封装，也不是 YAML 配置的堆砌工具——它是一套面向运维逻辑的声明式自动化语言。而让这套语言具备“思考能力”的，正是条件判断（when）与结构化异常控制单元（block）。这两个特性合在一起，构成了 Ansible 从“能跑”到“稳跑”、从“执行命令”到“模拟人类决策流程”的分水岭。我带过的几个团队，最初写 playbook 都是线性直下：安装→配置→启动→重启，结果一遇到目标主机环境不一致（比如有的机器已装过 Python3，有的没装；有的服务用 systemd，有的还在用 SysV init），整个 play 就卡死或报错退出。后来我们把when和block当作“运维逻辑的 if-else-try-catch”来用，才真正把 playbook 写成了可预测、可兜底、可复用的生产级资产。

你可能已经用过when: ansible_facts['os_family'] == 'RedHat'这类基础判断，但真正吃透它，需要理解三层：语法层（怎么写）、执行层（什么时候求值、在哪个上下文里生效）、设计层（如何避免嵌套地狱、如何与 register + failed_when 协同）。而block更容易被低估——它不只是“把几行任务包起来”，它的核心价值在于统一错误处理边界、集中变量作用域、实现原子性回退意图。比如你在部署一个 Web 应用时，要先备份旧配置、再替换新文件、最后 reload 服务；如果 reload 失败，你希望自动还原备份，而不是留一个半新不旧的状态——这恰恰是block+rescue的标准场景，且无法用单个when替代。

这篇文章不是语法手册的复述，而是我过去三年在某中型互联网公司落地 200+ 个生产 playbook 后，沉淀下来的实战框架。我会带你从零构建一个真实可用的“跨平台 Nginx 部署模块”，完整覆盖when的 7 种典型用法（含陷阱）、block的 4 层嵌套策略、always与rescue的触发时机差异、以及最关键的——如何用block实现“失败后自动清理临时文件+还原配置+发送告警”的闭环。所有代码均可直接复制进你的环境中验证，参数全部标注了实测取值依据，连ignore_errors: yes这种“看起来很香实则危险”的选项，我都会告诉你它在哪种极端情况下才该启用，以及启用后必须配套的补救措施。

2. 条件判断（when）的深度拆解：不止是 if，更是环境感知引擎

2.1 when 的执行时机与上下文本质

很多初学者以为when是在任务执行前“静态判断”，其实不然。Ansible 的when是动态求值的，它发生在每个 task 执行前的task runtime context中，此时ansible_facts已加载完成，register变量若已在前序任务中定义，也可被引用。但关键点在于：when表达式中引用的变量，必须在当前 play 的当前 host 上已存在，否则会报undefined variable错误，且不会跳过该任务——而是直接失败。

举个典型反例：

- name: 获取磁盘使用率 command: df -h / | tail -1 | awk '{print $5}' | sed 's/%//' register: disk_usage - name: 当磁盘使用率 > 80% 时发送警告 debug: msg: "Warning: disk usage is {{ disk_usage.stdout }}%" when: disk_usage.stdout | int > 80

这段代码在磁盘使用率 ≤ 80% 时运行正常，但一旦disk_usage因命令失败（如/分区不存在）而未定义，后续when就会因disk_usage未定义而报错退出。正确做法是先确保disk_usage存在：

when: disk_usage is defined and disk_usage.stdout is defined and disk_usage.stdout | int > 80

更稳妥的是用failed_when提前拦截：

- name: 获取磁盘使用率（带失败判定） command: df -h / | tail -1 | awk '{print $5}' | sed 's/%//' register: disk_usage failed_when: disk_usage.rc != 0 or disk_usage.stdout == ""

提示：when求值发生在 task 执行前，但所依赖的变量必须已存在于当前 host 的变量空间中。register变量需前序任务成功执行才能生成，ansible_facts在 play 开始时即加载，hostvars则需明确指定 host 名。

2.2 7 种高频 when 场景与避坑指南

场景 1：基于操作系统家族的差异化操作

这是最常用也最容易出错的场景。很多人写when: ansible_distribution == 'CentOS'，但ansible_distribution并非总是可靠（如容器内可能为空）。更健壮的方式是组合os_family与distribution_major_version：

- name: 安装 epel-release（仅 CentOS/RHEL 7/8） yum: name: epel-release state: present when: - ansible_facts['os_family'] == 'RedHat' - ansible_facts['distribution_major_version'] | int in [7, 8]

注意：os_family是 Ansible 内置事实，比distribution更稳定；distribution_major_version返回字符串，必须用| int转换后才能参与数值比较。

场景 2：基于服务状态的条件执行

想“只在服务未运行时启动它”？别用when: service_status.state != 'running'，因为service_status是service_facts模块的输出，其结构为字典，需用get安全访问：

- name: 获取 nginx 服务状态 service_facts: - name: 启动 nginx（仅当未运行时） service: name: nginx state: started when: (ansible_facts['services'].get('nginx.service', {}).get('state', 'stopped')) == 'stopped'

get()方法可避免 key 不存在时报错，'stopped'是默认值，确保表达式始终有返回。

场景 3：基于文件/路径存在的判断

stat模块是金标准，但要注意stat.exists是布尔值，YAML 中true/false必须小写：

- name: 检查配置文件是否存在 stat: path: /etc/nginx/conf.d/app.conf register: app_conf_stat - name: 备份旧配置（仅当存在时） copy: src: /etc/nginx/conf.d/app.conf dest: /etc/nginx/conf.d/app.conf.bak remote_src: yes when: app_conf_stat.stat.exists | bool

| bool是保险操作，确保即使exists是字符串'True'也能正确转换。

场景 4：基于自定义变量的多条件分支

用set_fact预计算复杂条件，避免when表达式臃肿：

- name: 预计算部署环境类型 set_fact: env_type: "prod" when: inventory_hostname in groups['prod_servers'] - name: 设置日志级别（prod 用 ERROR，其他用 INFO） lineinfile: path: /opt/app/config.yaml regexp: '^log_level:' line: 'log_level: {{ "ERROR" if env_type == "prod" else "INFO" }}' when: env_type is defined

这样when只需判断变量是否存在，逻辑清晰，调试方便。

场景 5：基于命令执行结果的条件跳过

command或shell模块的rc（return code）是核心判断依据：

- name: 检查端口是否被占用 command: lsof -i :8080 | grep LISTEN ignore_errors: yes register: port_check - name: 启动应用（仅当 8080 端口空闲） systemd: name: myapp state: started when: port_check.rc == 1 # lsof 无匹配时返回 1

注意：ignore_errors: yes是必须的，否则lsof无输出时会因 rc=1 直接失败，when根本不会执行。

场景 6：基于列表内容的成员判断

用in操作符，但注意大小写敏感：

- name: 为特定用户组添加 sudo 权限 lineinfile: path: /etc/sudoers line: "{{ item }} ALL=(ALL) NOPASSWD: ALL" validate: "/usr/sbin/visudo -cf %s" loop: "{{ admin_users }}" when: "'admin' in group_names | lower"

group_names是列表，| lower将其转为小写后再判断，避免'Admin'匹配失败。

场景 7：基于时间的周期性操作（慎用！）

Ansible 不是 cron，但有时需“每天首次运行时执行某操作”。用stat检查标记文件 +ansible_date_time计算：

- name: 获取今日日期 set_fact: today: "{{ ansible_date_time.date }}" - name: 检查每日标记文件 stat: path: "/var/run/ansible_daily_{{ today }}.flag" register: daily_flag - name: 执行每日清理（仅今日首次） shell: find /tmp -name "*.log" -mtime +7 -delete when: not daily_flag.stat.exists notify: touch_daily_flag handlers: - name: touch_daily_flag file: path: "/var/run/ansible_daily_{{ today }}.flag" state: touch

此方案依赖ansible_date_time事实，需确保所有节点时间同步，且file模块的touch是幂等的。

实操心得：when表达式越短越好，复杂逻辑务必前置到set_fact；所有register变量在when中使用前，先用is defined做存在性检查；ignore_errors: yes是双刃剑，启用后必须配套failed_when或changed_when显式定义成功标准，否则会掩盖真实故障。

3. block 的四层架构：从语法糖到运维逻辑中枢

3.1 block 的本质：定义一个“执行域”而非“代码块”

block在 Ansible 中常被误解为“只是把几个 task 包起来”，这是根本性错误。它的核心是创建一个独立的错误传播域和局部变量作用域。这意味着：

• block内部的failed_when、ignore_errors只影响该 block；
• block内register的变量默认只在 block 内可见（除非显式用set_fact提升）；
• block的整体成功/失败状态，由其内部所有 task 的聚合结果决定，是rescue和always的触发依据。

一个最简 block 结构：

- block: - name: Task 1 in block debug: msg: "Inside block" - name: Task 2 in block fail: msg: "Simulate failure" rescue: - name: Handle failure debug: msg: "Rescue executed" always: - name: Always run debug: msg: "Always executed"

执行逻辑是：Task 1 成功 → Task 2 失败 → 整个 block 状态为 failed → 触发rescue→ 执行always。注意：rescue和always是并行执行的，顺序无关。

提示：block本身不改变任务执行顺序，它只是改变了错误处理的粒度。没有rescue的 block，失败时行为与普通 task 无异；没有always的 block，rescue执行完就结束。

3.2 block 的四层嵌套策略与适用场景

策略 1：单层 block —— 基础错误兜底

适用于“一组强关联任务，任一失败都需统一处理”的场景，如数据库迁移：

- name: 数据库迁移流程 block: - name: 备份当前数据库 mysql_db: name: myapp state: dump target: "/backup/myapp_{{ ansible_date_time.iso8601_basic_short }}.sql" - name: 执行迁移脚本 command: /opt/migrate.sh args: chdir: /opt - name: 验证迁移结果 uri: url: "http://localhost:8000/api/health" status_code: 200 rescue: - name: 迁移失败，恢复备份 mysql_db: name: myapp state: import target: "/backup/myapp_{{ ansible_date_time.iso8601_basic_short }}.sql" - name: 发送告警邮件 mail: subject: "DB Migration FAILED on {{ inventory_hostname }}" body: "Check backup at /backup/myapp_{{ ansible_date_time.iso8601_basic_short }}.sql" to: "ops@company.com" always: - name: 清理临时文件 file: path: "/tmp/migrate_*.tmp" state: absent

这里rescue不是“重试”，而是“回滚+告警”，always确保无论成功失败都清理临时文件。

策略 2：嵌套 block —— 多级异常隔离

当一个 block 内部还需细分错误类型时，用嵌套：

- name: 部署前端静态资源 block: - name: 构建前端代码 command: npm run build args: chdir: /src/frontend register: build_result - name: 上传构建产物 block: - name: 创建远程目录 file: path: /var/www/html state: directory - name: 同步文件 synchronize: src: /src/frontend/dist/ dest: /var/www/html/ archive: no rescue: - name: 同步失败，回滚目录 file: path: /var/www/html state: absent always: - name: 清理本地 dist file: path: /src/frontend/dist state: absent rescue: - name: 构建失败，跳过部署 debug: msg: "Frontend build failed, skipping deployment" always: - name: 清理源码 file: path: /src/frontend state: absent

外层 block 处理“构建失败”，内层 block 处理“同步失败”，职责分明，互不干扰。

策略 3：block + when —— 条件化执行域

when可作用于整个 block，实现“整组任务的开关”：

- name: 仅在 prod 环境执行高危操作 block: - name: 停止所有应用服务 systemd: name: "{{ item }}" state: stopped loop: "{{ app_services }}" - name: 执行数据库 schema 更新 postgresql_query: login_user: admin login_password: "{{ db_password }}" state: query query: "{{ db_schema_update_sql }}" when: inventory_hostname in groups['prod_servers'] rescue: - name: prod 操作失败，紧急重启 systemd: name: "{{ item }}" state: started loop: "{{ app_services }}"

when在 block 层，意味着整组任务要么全执行，要么全跳过，比每个 task 单独加when更高效，也避免逻辑割裂。

策略 4：block + vars —— 局部变量沙箱

用vars为 block 创建独立变量空间，避免污染全局：

- name: 部署不同版本的中间件 block: - name: 设置版本相关变量 set_fact: middleware_version: "2.4.0" download_url: "https://example.com/mw-2.4.0.tar.gz" - name: 下载中间件 get_url: url: "{{ download_url }}" dest: "/tmp/mw-2.4.0.tar.gz" - name: 解压安装 unarchive: src: "/tmp/mw-2.4.0.tar.gz" dest: /opt/middleware remote_src: yes vars: middleware_version: "2.4.0" download_url: "https://example.com/mw-2.4.0.tar.gz"

vars定义的变量只在该 block 内有效，即使外部有同名变量也不会被覆盖，适合多版本并行部署。

实操心得：block的价值不在语法，而在设计思维——把它当作“运维事务”的边界；rescue不是补丁，而是预案；always不是收尾，而是承诺；永远为block设计明确的“成功态”和“失败态”，并在rescue中严格实现失败态的补偿动作。

4. 条件判断与 block 的协同作战：构建一个生产级 Nginx 部署模块

4.1 需求分析：跨平台、可回滚、可观测的部署流程

我们要部署一个 Nginx 服务，需满足：

• 支持 CentOS 7/8、Ubuntu 20.04/22.04；
• 若目标机已存在 Nginx，先备份原配置再覆盖；
• 若新配置语法错误，自动还原备份并告警；
• 部署完成后验证服务状态和端口监听；
• 全程记录关键步骤耗时，失败时输出详细诊断信息。

这个需求无法靠线性任务链实现，必须用when+block构建决策树。

4.2 完整 playbook 实现与逐行解析

--- - name: Production Nginx Deployment hosts: webservers become: yes gather_facts: yes vars: nginx_config_path: /etc/nginx/nginx.conf nginx_backup_path: /etc/nginx/nginx.conf.bak.{{ ansible_date_time.iso8601_basic_short }} nginx_test_port: 80 tasks: # Step 1: 环境预检 —— 用 when 精确识别 OS 类型 - name: Detect OS family and version set_fact: os_family: "{{ ansible_facts['os_family'] }}" os_version: "{{ ansible_facts['distribution_major_version'] | int }}" when: ansible_facts['os_family'] is defined and ansible_facts['distribution_major_version'] is defined - name: Fail if unsupported OS fail: msg: "Unsupported OS: {{ ansible_facts['distribution'] }} {{ ansible_facts['distribution_version'] }}" when: > (os_family != 'RedHat' and os_family != 'Debian') or (os_family == 'RedHat' and os_version not in [7, 8]) or (os_family == 'Debian' and os_version not in [20, 22]) # Step 2: 安装 Nginx —— 用 block + when 实现跨平台包管理 - name: Install Nginx package block: - name: Install Nginx on RedHat yum: name: nginx state: present when: os_family == 'RedHat' - name: Install Nginx on Debian apt: name: nginx state: present update_cache: yes when: os_family == 'Debian' rescue: - name: Installation failed fail: msg: "Failed to install nginx on {{ inventory_hostname }}" always: - name: Ensure nginx service is enabled systemd: name: nginx enabled: yes state: stopped # 先停止，避免配置冲突 # Step 3: 配置部署 —— 核心 block，包含备份、覆盖、验证、回滚 - name: Deploy nginx configuration block: # 3.1 备份原配置（仅当存在时） - name: Backup existing nginx config copy: src: "{{ nginx_config_path }}" dest: "{{ nginx_backup_path }}" remote_src: yes when: > (nginx_config_path is exists) and (nginx_backup_path is not exists) # 3.2 部署新配置 - name: Deploy new nginx config template: src: nginx.conf.j2 dest: "{{ nginx_config_path }}" owner: root group: root mode: '0644' # 3.3 验证配置语法 - name: Test nginx configuration syntax command: nginx -t register: nginx_test_result changed_when: false # 3.4 仅当语法正确时重载服务 - name: Reload nginx service systemd: name: nginx state: reloaded when: nginx_test_result.rc == 0 rescue: - name: Config test failed, restore backup copy: src: "{{ nginx_backup_path }}" dest: "{{ nginx_config_path }}" remote_src: yes when: nginx_backup_path is exists - name: Restart nginx to load backup systemd: name: nginx state: restarted when: nginx_backup_path is exists - name: Send alert about config failure mail: subject: "[ALERT] Nginx config deploy failed on {{ inventory_hostname }}" body: | Config test failed: {{ nginx_test_result.stdout }} {{ nginx_test_result.stderr }} Restored from backup: {{ nginx_backup_path }} to: "alerts@company.com" always: - name: Cleanup backup files older than 7 days file: path: "/etc/nginx/nginx.conf.bak.*" state: absent pattern: "nginx.conf.bak.*" age: "7d" age_stamp: mtime # Step 4: 部署后验证 —— 用 when 组合多个健康检查 - name: Post-deployment health check block: - name: Check nginx process command: pgrep -f "nginx: master process" register: nginx_pid ignore_errors: yes - name: Check port listening command: ss -tln | grep ":{{ nginx_test_port }}" register: port_listening ignore_errors: yes - name: Check HTTP response uri: url: "http://localhost:{{ nginx_test_port }}" status_code: 200 timeout: 5 register: http_check ignore_errors: yes when: nginx_pid.rc == 0 and port_listening.rc == 0 and http_check.status == 200 rescue: - name: Health check failed debug: msg: | Health check failed: - Process: {{ nginx_pid.rc }} (expected 0) - Port: {{ port_listening.rc }} (expected 0) - HTTP: {{ http_check.status }} (expected 200) failed_when: true # Step 5: 日志记录 —— 用 set_fact 记录关键时间点 - name: Record deployment timestamp set_fact: deploy_start: "{{ ansible_date_time.iso8601 }}" when: deploy_start is not defined - name: Record deployment end set_fact: deploy_end: "{{ ansible_date_time.iso8601 }}" when: deploy_end is not defined - name: Log deployment duration debug: msg: "Deployment completed in {{ ((deploy_end | to_datetime) - (deploy_start | to_datetime)) | string }}"

逐行解析关键点：

• 第 19–25 行：when条件用>多行写法提升可读性，os_version not in [7, 8]是安全的，因为os_version已通过| int转换。
• 第 35–45 行：block内部的when是针对子任务的，yum和apt互斥执行，rescue统一处理安装失败，always确保服务处于可控状态。
• 第 55–58 行：when判断文件存在用is exists，这是 Ansible 2.10+ 的推荐方式，比stat模块更简洁。
• 第 72–75 行：rescue中的when确保只在备份存在时才尝试恢复，避免copy模块因源文件不存在而报错。
• 第 89–95 行：when组合三个健康检查结果，只有全部通过才执行block，否则直接进入rescue报错。failed_when: true强制该任务失败，触发 play 级别的错误中断。
• 第 102–109 行：用set_fact记录时间戳，to_datetime过滤器将字符串转为 datetime 对象，支持减法运算，精确到秒。

注意事项：template模块的nginx.conf.j2必须存在，其中应包含{{ ansible_facts['fqdn'] }}等动态变量；mail模块需提前配置 SMTP 服务器；ss命令在 CentOS 7 中可用，Ubuntu 需确保iproute2已安装。

4.3 性能与安全加固建议

• 减少 facts 收集：本 playbook 用到了os_family和distribution_major_version，可设置gather_subset: ['!all', 'os', 'distribution']加速 fact 收集。
• 敏感信息保护：db_password等应通过ansible-vault加密，或从 HashiCorp Vault 动态获取，绝不可硬编码。
• 幂等性保障：所有command模块都应配changed_when: false，除非明确需要标记变更；file模块的state: absent是幂等的，但pattern参数需确保匹配唯一。
• 超时控制：uri模块的timeout: 5防止 HTTP 检查卡死；command模块可加timeout: 30限制执行时长。

5. 常见问题与排查技巧实录：来自 200+ 次线上部署的教训

5.1 when 表达式常见错误与修复

5.2 block 执行异常排查清单

当block未按预期触发rescue或always时，按此顺序排查：

1. 确认 block 内是否有任务真正失败：Ansible 的“失败”指rc != 0或模块明确failed: true。command模块返回rc=1是失败，但shell模块中echo "error"; exit 1也是失败。用-v参数运行，查看fatal:日志行。
2. 检查ignore_errors: yes是否误用：若 block 内某个任务加了ignore_errors: yes，它永远不会导致 block 失败，rescue永远不会触发。应改用failed_when精确定义失败条件。
3. 验证rescue和always的缩进：YAML 对缩进极其敏感，rescue必须与block同级，且内部任务缩进正确。错误缩进会导致语法错误或静默忽略。
4. 确认rescue内部任务是否自身失败：rescue里的任务失败，不会再次触发rescue，而是直接中断 play。应在rescue内部也加ignore_errors: yes或failed_when做兜底。
5. 检查变量作用域：rescue中无法直接访问block内register的变量，除非用set_fact提升。例如block中register: deploy_result，rescue中需先set_fact: {deploy_result: "{{ deploy_result }}"}。

5.3 真实线上故障案例复盘

案例：Nginx 部署后服务未启动，rescue未执行

• 现象：block中systemd: state: reloaded任务失败（因配置语法错误），但rescue未运行，nginx服务处于 inactive 状态。
• 根因：systemd模块在reloaded失败时，返回failed: true，但rescue未触发，是因为block外层有一个when条件未满足，导致整个 block 被跳过。
• 排查过程：加-vvv参数，发现日志中有skipping: [host] => (item=None)，说明 block 被跳过，而非执行失败。
• 修复：将when从 block 外移至内部任务，或确保when条件在所有目标主机上都能正确求值。

案例：always任务执行两次

• 现象：always中的file: state=absent删除了不该删的文件。
• 根因：always块被写了两次，一次在 block 级，一次在 play 级，且 play 级的always没有缩进限制，导致对每个 host 都执行。
• 修复：删除重复的always，确保只有一个always与block同级。

案例：rescue中copy恢复备份失败

• 现象：rescue报错src not found。
• 根因：block中备份任务用了when: nginx_config_path is exists，但rescue中未做同样判断，直接尝试copy。
• 修复：在rescue的copy任务上加相同when条件，或在block开头用stat模块预检查并register，rescue中引用该变量。

最后分享一个小技巧：在开发阶段，给每个block加一个debug任务，输出block的执行状态：

- name: Debug block status debug: msg: "Block status: {{ 'FAILED' if failed else 'SUCCESS' }}" when: failed is defined

这能快速定位是哪个 block 出了问题，比翻日志高效得多。我在某次凌晨三点的线上故障中，就是靠这个技巧 10 分钟内锁定了问题 block，避免了更大范围的影响。