企业官网建设流程全解析

说实话，干了这么多年运维，Ansible在我手里早就不是“会不会用”的问题，而是“怎么用得让人不骂娘”的问题。早期踩过的坑、写过的烂剧本、被同事吐槽过的YAML缩进，都是血泪史。今天把Ansible Playbook这玩意儿一次讲透——从设计思路到语法坑、从实战案例到排查心得，希望你看完能少走几步弯路。

这篇文章适合这些读者：刚把Ansible装好、在ubuntu server上跑通了两条ad-hoc命令的新手；已经写过几个Playbook但总感觉哪里别扭、想理清变量和复用体系的进阶者；以及团队里准备推自动化运维项目、需要把脚本整理成可维护剧本的人。我会尽量用大白话解释原理，穿插真实项目里的实操记录。

1. 为什么要深入理解Playbook：自动化运维的核心载体

1.1 从Ad-Hoc命令到Playbook：你迟早要跨过这道坎

很多人接触Ansible是从ad-hoc命令开始的。一条ansible all -m ping测通，再顺手ansible all -m apt -a "name=nginx state=present"装个包，挺爽。但用不了几天你就会发现严重问题：你根本不记得上周给那十几台机器执行过什么命令，新来的同事接手时更是一脸懵。运维操作如果没有记录、没有版本、没有评审，那就等于裸奔。

Ad-hoc命令适合临时探活、调试和应急操作，但它不是“自动化运维项目”的正式形态。Playbook才是。我习惯把ad-hoc比作随口说的一句话，而Playbook是写进合同里的条款——前者说完就忘，后者白纸黑字、可以追溯、可以反复执行。

从ad-hoc走向Playbook的真正门槛不是语法，而是思维转变：你要从“执行一条命令”转变为“描述一个目标状态”。比如装Nginx，ad-hoc关心的是“执行安装命令”，Playbook关心的是“Nginx这个最终状态是否存在”。这种声明式思维是整个Ansible玩得转的关键，也是后面理解幂等性的基础。

1.2 Playbook到底解决了什么问题

用一句话总结：Playbook是把运维流程代码化、标准化、可复用化的一套机制。它解决了三个让人头疼的问题。

第一，可重复性。同样的任务，今天执行和三个月后执行，结果应该一样。以前写Shell脚本也能做到这一点，但Shell脚本天然是“面向步骤”的，遇到目标环境与预期不符的情况，脚本就乱了阵脚——要么报错退出，要么做出不可控的操作。Playbook则通过模块的幂等性设计，让“执行多次”和“执行一次”的结果尽量一致。

第二，可读性。Playbook写出来是接近自然语言的声明式文本，比如“安装nginx”“启动nginx服务”“复制配置文件”。哪怕是不懂Ansible的同事，第一次看也能大概猜出这段剧本在做什么。而一段500行的bash脚本，除非你逐行写注释，否则三个月后连自己都看不懂。

第三，可审计性。Playbook是一个文件，可以放进Git里做版本管理。谁改了什么、为什么改、哪个版本引入了某个变更，清清楚楚。这对于团队协作、故障回溯、合规审计来说都是硬需求。

1.3 一个Playbook的“最小可用”结构

先别管复杂概念，记住Playbook最基本的骨架就行。它是个YAML文件，顶层是一个列表，列表里每个元素是一个play，每个play定义了“在哪些机器上执行什么任务”。

--- - name: 安装并启动nginx hosts: web_servers become: yes tasks: - name: 确保nginx已安装 ansible.builtin.apt: name: nginx state: present - name: 确保nginx已启动 ansible.builtin.service: name: nginx state: started

这个剧本干了什么？它声明了两件事：目标机器是web_servers组里的机器，且使用超级权限执行；要做的任务是“安装nginx”和“启动nginx服务”。become: yes是提权开关，相当于sudo。tasks下面每个name是对这个任务的描述，这个描述会打印在执行日志里，所以写清楚点，别敷衍。

后面所有复杂功能——变量、模板、循环、条件、角色、处理器——都是在丰富这个骨架。但骨架永远是这个：在哪里（hosts）、干什么（tasks）、以什么身份干（become）。把这三点刻在脑子里，你就不会在Playbook里迷路。

2. Playbook语法核心：YAML、Task与模块的协同

2.1 YAML是地基：缩进、列表、字典，一个都不能错

Playbook的载体是YAML。很多人玩Ansible玩得崩溃，一半时间是在跟YAML格式搏斗。YAML的规则说简单也简单，说严格也严格，最核心的无非三条：缩进表示层级、冒号表示键值、短横线表示列表项。

但就是这三条，能坑掉无数新手（和部分老手）。最常见的问题是：用Tab键缩进。YAML只认空格，不认Tab。你在编辑器里看着对齐了，Ansible跑起来直接抛Syntax Error或者解析出一个完全错误的结构。我建议所有写Playbook的人把编辑器的“Tab转空格”打开，缩进统一用两个空格。

另一类问题发生在写字典值时忘了加空格，比如hosts:web_servers——冒号后面必须跟一个空格，否则YAML会把它整个当字符串。这类错误其实很好排查，因为Ansible会提示“Syntax Error”，但问题在于控制台报错信息往往带有一堆堆栈，新手容易慌。我遇到这种情况的第一反应永远是：看报错里的line和column，直接定位到那一行，八成是缩进错乱或者冒号空格问题。

- name: 示例 hosts: all vars: user_name: zhangsan user_info: { "age": 18, "city": "beijing" } package_list: - nginx - git - curl

上面这个例子展示了三种最常见的YAML写法：普通字符串键值、行内字典、列表。写熟了你会觉得YAML挺舒服的，但在那之前，请养成写完自检的习惯。

2.2 Task的本质：模块加参数，Ansible的灵魂

Playbook玩得再花，最后真正干活的还是“模块”。Task是对模块的一次调用，它由模块名、模块参数、任务属性三部分组成。模块是Ansible内置好的一堆“操作原语”，比如apt管包、copy管文件复制、service管服务状态、command管执行命令。

这里我想强调一个很多初学者完全误解的地方：能用模块干的事，尽量不要用command或shell模块硬凑。为什么？因为模块被设计成幂等的，而command默认不幂等。比如你用command: apt install -y nginx，第一次执行是安装，第二次执行它依然会走一遍，Ansible无法判断“是否需要执行”。但apt模块不同，它内部会检查nginx是不是已经装了，装了就直接跳过，并把状态标记为ok——这就是幂等性的来源。

写Task的时候，推荐尽量把模块名写完整。从Ansible 2.10开始，模块被收纳到集合中，比如apt应该写作ansible.builtin.apt。这个写法虽然啰嗦一点，但能避免很多版本兼容性问题。如果你的环境是Ansible 2.9或更老版本，用apt这种短名也行；但新项目建议直接上完整名，后面升级时省心。

模块参数有长格式和短格式两种。短格式是key=value一行拼写，适合参数少的场景；长格式是用YAML字典逐行写，适合参数多、可读性要求高的场景。永远记住：可读性优先。

tasks: - name: 用短格式安装nginx ansible.builtin.apt: name=nginx state=present - name: 用长格式安装nginx ansible.builtin.apt: name: nginx state: present

长格式多写几行，但结构清晰、后续加参数方便。实践中我基本全用长格式。

2.3 变量与优先级：别再被“变量不生效”逼疯了

变量是Playbook里最容易出乱子的地方，因为Ansible的变量来源太多了：命令行--extra-vars、Play文件里的vars、inventory里的host_vars和group_vars、角色里的defaults和vars、甚至set_fact动态设置的变量。这些变量之间有严格的优先级，记不住优先级顺序，就会出现"我明明在group_vars里设了值，为什么playbook里还是用旧值"的惨案。

给你一个简化版记忆法，按优先级从低到高排：

1. 角色的defaults/main.yml（最低）
2. inventory里的host_vars和group_vars
3. Play中的vars和vars_files
4. 角色的vars/main.yml
5. 任务里通过set_fact/register设置的变量
6. 命令行--extra-vars（最高）

也就是说，命令行传入的变量永远是老大，谁也盖不过它。defaults里的值最容易被覆盖，适合放“可以被使用者覆盖的默认值”。

这里分享一个我踩过的大坑：在inventory文件中给一组机器定义了ansible_user，结果某台机器要用不同用户名登录，我在playbook里又写了vars: ansible_user: xxx，以为能覆盖。执行的时候发现压根没生效。原因就是inventory的变量优先级高于play直接定义的vars，所以你必须去host_vars里改，或者用--extra-vars强推。从那以后，我每次排查变量问题都会先用ansible-inventory --host <主机名> --vars看一下实际生效的变量值，省了很多排查时间。

2.4 模板系统与Facts：动态生成配置文件的利器

真实环境里，配置文件往往因机器而异。比如Nginx的worker_processes要根据CPU核数调整，应用的数据库连接串要区分测试环境和生产环境。如果每个环境写一份配置，累死且容易漏。Playbook的解决方案是“模板”。

Ansible使用Jinja2模板引擎，模板文件以.j2结尾。模板里可以嵌入变量、写简单的循环和条件。结合“Facts”——Ansible在每台机器上自动采集的系统信息（CPU核数、内存、IP、操作系统等），可以轻松生成贴合当前机器的配置。

先看一个模板示例，这是nginx.conf.j2的片段：

worker_processes {{ ansible_processor_cores }}; server { listen 80; server_name {{ server_name }}; root {{ web_root }}; }

再看Playbook里怎么使用模板：

- name: 渲染nginx配置模板 ansible.builtin.template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf owner: root group: root mode: '0644' notify: reload nginx

这里有个细节值得注意：ansible_processor_cores和server_name的来源不同。前者是Facts自动采集的，后者是你在vars或host_vars里定义的。Facts是Ansible很强大的能力，执行Playbook时默认会先跑一遍gather_facts，把系统信息抓回来，放在变量里供模板使用。如果不需要Facts，可以在play里设gather_facts: no来提速，但前提是你确实用不到。

3. 项目实测：一个完整的Web服务部署Playbook

3.1 场景设定与目录结构

理论讲再多，不如实际跑一版。下面我模拟一个非常典型的场景：在一个ubuntu server组上，通过Ansible部署一套Nginx静态站点服务，包括安装Nginx、渲染index页面、启动服务、配置防火墙放行80端口。

实际运维项目里我强烈建议按“角色”组织目录结构。先建好目录骨架，就算现在只有一个角色，也为后续扩展留好了位置。

web-deploy/ ├── inventory.ini ├── playbook.yml └── roles/ └── nginx/ ├── tasks/ │ └── main.yml ├── templates/ │ └── index.html.j2 ├── handlers/ │ └── main.yml └── defaults/ └── main.yml

这个结构是Ansible官方推荐的Roles标准布局，tasks放主任务、templates放模板、handlers放处理器、defaults放默认变量。别小看这个布局，它让每个角色的职责边界非常清楚——以后你要加个PHP-FPM角色，直接新建一个roles/php-fpm/目录就行，互不干扰。

3.2 编写部署Nginx的Playbook

先看inventory文件。最简单的写法是INI格式，可以定义主机组和组变量：

[web_servers] 192.168.1.10 ansible_user=ubuntu 192.168.1.11 ansible_user=ubuntu [web_servers:vars] ansible_ssh_private_key_file=~/.ssh/id_ed25519

再看看入口playbook文件。这个文件是执行时的入口，它负责把角色关联到主机组上，并可以传入一些play级别的变量：

--- - name: 部署nginx静态站点 hosts: web_servers become: yes gather_facts: yes roles: - nginx

非常简单对吧？但实际干活的都在roles/nginx/里面。roles/nginx/defaults/main.yml定义默认变量：

--- nginx_port: 80 site_name: mysite web_root: /var/www/mysite

roles/nginx/tasks/main.yml是核心任务列表：

--- - name: 更新apt缓存 ansible.builtin.apt: update_cache: yes cache_valid_time: 3600 - name: 安装nginx ansible.builtin.apt: name: nginx state: present - name: 创建站点目录 ansible.builtin.file: path: "{{ web_root }}" state: directory owner: www-data group: www-data mode: '0755' - name: 渲染index页面模板 ansible.builtin.template: src: index.html.j2 dest: "{{ web_root }}/index.html" owner: www-data group: www-data mode: '0644' - name: 渲染nginx站点配置 ansible.builtin.template: src: nginx.conf.j2 dest: "/etc/nginx/sites-available/{{ site_name }}" notify: reload nginx - name: 启用站点配置 ansible.builtin.file: src: "/etc/nginx/sites-available/{{ site_name }}" dest: "/etc/nginx/sites-enabled/{{ site_name }}" state: link notify: reload nginx - name: 确保nginx服务运行 ansible.builtin.service: name: nginx state: started enabled: yes - name: 放行80端口 community.general.ufw: rule: allow port: "{{ nginx_port }}" proto: tcp

逐行解释几个容易忽略的细节。第一，cache_valid_time: 3600的意思是apt缓存如果在3600秒内更新过，就跳过update_cache。这个参数能有效减少重复执行时的等待时间。第二，启用站点配置时没有直接复制文件，而是做软链接，这是Nginx官方推荐的站点管理方式——你可以同时存在多个sites-available配置，但只在sites-enabled里链接需要的。第三，notify: reload nginx这个声明会和handlers联动，配置文件一旦发现变化，就触发Nginx重载，而不是重启。重载比重启优雅得多，不会中断现有连接，这在下文会展开讲。

roles/nginx/templates/index.html.j2也很简单：

<!DOCTYPE html> <html> <head><title>{{ site_name }}</title></head> <body> <h1>Welcome to {{ site_name }}!</h1> <p>This page is deployed by Ansible.</p> </body> </html>

通过模板，不同环境下只要传不同的site_name变量，就能渲染出不同的页面，不需要手工修改每一个文件。

3.3 Handlers与notify的联动机制

handler是Playbook里非常巧妙的机制，用来处理“变更后的动作”。它和普通task长得很像，但有两个关键区别：它是通过notify被触发的，而不是直接执行；同一个handler在一次playbook运行中即使被多次notify，也只会执行一次。

举个例子。上面任务里有两处notify: reload nginx，分别对应渲染nginx站点配置和启用站点配置链接。如果两个任务都发生了变更，handler也不会被调用两次。它会在本轮play所有task执行完后统一处理，而且只运行一次。这看起来是个小事，但避免了重复reload导致的服务抖动。

定义handler的地方在roles/nginx/handlers/main.yml：

--- - name: reload nginx ansible.builtin.service: name: nginx state: reloaded

这个机制的精髓在于“按需执行”：配置文件没变，就绝不reload；配置文件变了，才触发一次reload。这一设计让Playbook在反复执行时非常安全。我在生产环境里见过因为配置管理工具每次都重启服务、导致线上偶发闪断的事故，用handler+notify机制就能从根上避免。

3.4 用角色组织后的实际执行效果

执行整个项目只需要一条命令：

ansible-playbook -i inventory.ini playbook.yml

如果一切顺利，你会看到每个task的输出状态都是ok或者changed。首次执行时安装类任务大概率是changed，因为确实装了东西；第二次执行时应该基本变成ok——这就是幂等性在工作。

这里顺手提一个实用参数：加-v可以看到更多执行细节，加--check做演练模式。演练模式不会真正修改系统，只会告诉你“会发生哪些变更”，这在改动生产环境前是必须做的一步。

我在实际部署中经常这么干：先在测试机上执行一次完整playbook，确认无误后，再到生产环境加--check先干跑一遍，最后再真实执行。这一步看似多余，但能拦住绝大多数低级错误。

4. Playbook核心机制：条件、循环与幂等性

4.1 when条件判断：让任务在合适的机器上做合适的事

当你的inventory里不再是“清一色的ubuntu server”时，条件判断就成刚需了。比如你管理着一批机器，一部分是Debian系，一部分是RedHat系，apt和yum模块就不能混用。Playbook的解决方案是when关键字，它支持表达式判断，常用的是结合Facts。

- name: Debian系安装nginx ansible.builtin.apt: name: nginx state: present when: ansible_os_family == "Debian" - name: RedHat系安装nginx ansible.builtin.yum: name: nginx state: present when: ansible_os_family == "RedHat"

when后面跟的是一个Jinja2表达式。它可以直接写ansible_os_family == "Debian"这种比较，也可以写variable is defined（变量已定义）、variable is not defined（变量未定义）、以及组合条件when: (a is defined) and (b is defined)。

我遇到的比较实用的场景是配置差异化。比如内网机器需要配置NTP到内网时钟源，而云端机器则用默认的云厂商时钟源。这种差异性非常适合用when+group_vars里的变量来控制。同类机器归到同一个组，组里定义一个ntp_server变量，任务里判断这个变量是否有值、值是什么，再决定写入哪份配置。这样一套playbook就能管住多环境，而不是为每个环境复制一份几乎相同的文件。

4.2 loop循环：批量处理的正确姿态

重复写十几个几乎一样的task，是新手最爱犯的错。比如创建十个用户，有些人会真写十条user模块的task。实际上用loop一行就搞定了。

- name: 批量创建用户 ansible.builtin.user: name: "{{ item }}" state: present groups: "dev" loop: - zhangsan - lisi - wangwu - zhaoliu

loop遍历列表，每次把当前元素赋给item，然后在模块参数里通过{{ item }}引用。如果你需要遍历更复杂的数据结构，比如字典列表，item.name、item.uid这样取字段就行：

- name: 批量创建带uid的用户 ansible.builtin.user: name: "{{ item.name }}" uid: "{{ item.uid }}" state: present loop: - name: zhangsan uid: 1001 - name: lisi uid: 1002

循环的价值不只是少写几行代码，更重要的是“批量操作的配置项集中在一起”，改动时只需修改列表里的数据，任务本身不用动。这体现了一种数据和逻辑分离的思想，和模板的原理异曲同工。

4.3 幂等性：为什么我的Playbook每次执行结果都不一样

这是整个Ansible里最容易被问崩的话题。幂等性是指“多次执行的结果与一次执行的结果一致”，Playbook的理想状态是每次跑完，系统都处于声明好的目标状态，而不是越跑越偏。但很多人会发现，自己的playbook执行两次，第二次还是显示一堆changed，甚至导致系统状态不对。

之所以会这样，绝大部分原因是用了不幂等的操作方式。command模块和shell模块是不做状态检查的——你让它执行cp它就执行，你让它执行systemctl restart nginx它就重启，它不会去思考“这个文件是不是已经复制过了”“服务是不是本来就在运行”。滥用这两个模块，是Playbook失去幂等性的头号元凶。

那怎么救？分两种情况。第一，能换模块就换模块。复制文件用copy和template，安装包用apt/yum，管理服务用service/systemd。这些模块内部实现了状态检测。第二，如果确实必须用命令模块，就要人为补上幂等性。command模块有creates参数和removes参数，分别表示“如果该文件已存在就跳过”和“如果该文件不存在就跳过”，让命令只在必要的时候执行。

- name: 只在文件不存在时初始化数据库 ansible.builtin.command: /usr/local/bin/init_db.sh args: creates: /var/lib/myapp/db_initialized.lock

另一个常见问题是：你用了shell模块，但它检测不到文件变化导致重复执行。这种情况下可以用changed_when手动告诉Ansible“什么时候才算发生了变更”：

- name: 判断配置是否有更新 ansible.builtin.shell: /usr/local/bin/check_and_update.sh register: result changed_when: "'updated' in result.stdout"

register把命令执行的输出存到变量里，changed_when根据输出内容决定这个任务是否被标记为变更。这个技巧在封装一些不内置幂等逻辑的脚本时特别有用。

记着一句话：幂等性不是模块自带的光环，而是写Playbook的人必须具备的工程意识。每写一个任务，都问自己一句：如果这台机器已经处于目标状态，我再执行一次这个任务，会发生什么？如果答案是“还是会变”，那就得想办法让它“能检测不变”。

5. 常见问题与排查技巧实录

5.1 YAML格式错误：90%的报错都发生在这里

Ansible报错最常见的就是Syntax Error，但它的提示往往不够直观，尤其对于刚入门的人。我遇到过的经典案例是：某次在写变量字典时，把键值对的两个空格缩进写成了四个空格，导致Ansible把字典误判成了列表片段，抛出的报错完全看不出来问题在哪。

遇到格式错误别慌，按顺序做三步。第一步，看报错最后的line和column，定位到具体位置。第二步，用编辑器打开那个文件，把不可见字符显示出来，检查是不是混入了Tab。第三步，如果还是找不到，把出错的片段暂时注释掉一半，二分法缩小范围。

这里给你一个可以立即用起来的土办法：本地装个yamllint，每次写完Playbook先跑一下yamllint playbook.yml。它能告诉你行尾空格多了、缩进不一致、文件末尾缺换行等一连串格式问题。虽然它有点“吹毛求疵”，但用来保底很舒服。

5.2 变量类型混淆：数字、字符串、布尔值真的不一样

YAML里看似随意的写法，背后是严格的数据类型。很多人被state: present养成了手抽习惯，写端口号时写port: 80没问题，但写版本号时写version: 1.0，就会因为被解析成字符串而踩坑。

最常见的坑是布尔值。YAML里yes/no、true/false、on/off都会被解析成布尔值。早期Ansible的老项目里有大量become: yes这种写法，这是合法的。但如果变量值是给某个配置文件用的，比如debug_enabled: yes，模板里输出出来可能是个True而不是yes——你想要的文本和你得到的数据就对不上了。

处理这种问题，我的习惯是：凡是模板里要输出成文本的变量，统一在模板里用| string过滤器强制转成字符串，或者用to_json明确指定输出格式。别依赖YAML的“智能类型转换”，类型明确才是王道。

5.3 提权与become问题：明明连上了却什么也改不了

Playbook连上了主机，但执行任务时报权限不足，这是新手最常遇到的问题。Ansible默认用配好的ansible_user登录，这个用户不一定是root。像ubuntu server这种云服务器，默认用户是ubuntu，有sudo权限但需要密码或免密配置。

Playbook里的提权配置主要靠三个关键词：become（是否提权）、become_user（提权到哪个用户，默认root）、become_method（用什么方式提权，默认sudo）。如果sudo需要密码，你需要在执行时加-K参数手动输入sudo密码，或者把密码配置到inventory的变量ansible_become_password里（务必用vault加密，不要明文写）。

有个细节：become: yes放在play级别，表示这个play里的所有任务都提权；放在task级别，表示只有这个任务提权。后者粒度更细，更安全。但要注意，file模块创建文件时，owner和group如果不指定，默认是运行Ansible的用户，而不是become后的用户。这个坑会导致你明明用了become，创建出来的文件属主还是错乱的。所以涉及文件属主的任务，显式写好owner和group永远是更稳的。

5.4 模块参数错误：看文档看文档还是看文档

模块的参数写错，Ansible会给出错误提示，但你得能看懂。比如service模块的state参数，合法值是started、stopped、restarted、reloaded——你用enable想表达开机自启，就写错了，正确参数是enabled。每个模块的参数很多，记不住是常态，别硬背。

我的建议是：拿不准模块用法时，先在本地起个测试虚机，跑一遍ansible-doc 模块名查看文档，或者直接在命令行敲ansible-doc ansible.builtin.copy看示例。ansible-doc是安了Ansible就自带的工具，给出的参数说明和示例非常权威。经验越多，反而越会频繁用这个命令，因为它能避免一切“我以为是这样”的惨案。

6. 进阶打磨：几个让Playbook更好用的调试与优化技巧

6.1 调试三板斧：语法检查、干跑、逐步执行

写完一个Playbook，第一件事永远是ansible-playbook --syntax-check playbook.yml。它只做语法解析，不连接任何主机，消耗极低但能拦住百分之八十的低级错误。我一般会把这步放进Git的pre-commit钩子或者CI流程里，防止带病代码进入版本库。

第二件事是--check，也就是干跑模式。Ansible会“模拟执行”任务，告诉你哪些任务会变更、哪些不会，但不会真正修改系统。这个模式对copy、template、service这种状态型模块非常准，但对command、shell这种命令型模块基本没法预测——因为它不会真跑命令，也就不知道命令的结果。所以看到--check输出里命令模块显示changed或skipped时，别太当真，真正的验证还得靠第三招。

第三招是分步执行和定位。ansible-playbook playbook.yml --start-at-task="安装nginx"可以从指定任务开始执行，非常适合中途挂了后重跑。配合--limit hostname可以只跑某一台机器。如果想定位某台机器上的具体输出，-vvv详细日志模式能把SSH连接、模块执行细节全部打出来，代价是输出会非常啰嗦，日常调试够用了。

6.2 性能优化：当你的inventory膨胀到几十台机器

管理三五台机器时，Playbook慢一点无所谓。但到了几十上百台，你会发现一个明显的瓶颈：gather_facts阶段要SSH连到每台机器采集系统信息，Completely串行执行时非常耗时。实际上Ansible默认就是并行执行的，forks参数控制并发数，默认是5。如果你管理20台机器，把forks调到15到20，速度提升会立竿见影。

serial参数则相反，它控制“每批次多少台机器”。这主要用于滚动更新场景。比如你把serial: 1设置为一批一台，某台更新失败时Ansible会停下来，不至于整批机器全部挂掉。这个参数在生产环境变更中非常重要——我更愿意让它慢一点，也不想看到一次挂掉一个机房的场面。

如果你确信playbook里用不到系统Facts，可以在play级别设置gather_facts: no，直接跳过采集阶段。但这个优化要谨慎，万一后面某个任务使用了ansible_facts里的变量，就会报“变量未定义”。我的习惯是：playbook刚写的时候默认开着Facts，等稳定了再根据实际引用情况决定是否关闭。

6.3 关于这个项目后续扩展，和我个人的一点实践体会

Playbook这个东西，能讲的远不止这些。变量模板、角色、集合、Vault加密、AWX/Ansible Tower的界面化调度，每块都能再写一篇。但如果你把上面这些核心机制弄明白，相当于已经拿到了“自动化运维项目”的通行证，后面的路不过是按需扩展。

最后的最后，说几句掏心窝的话。第一，Playbook的工程规范比“能跑”重要得多。目录结构、命名习惯、变量作用域、handlers的用法，这些在写第一个角色时就该定好规矩，否则项目一复杂，你就会陷入无休止的重构。第二，尽量让Playbook保持“描述状态”而不是“堆砌命令”。这条原则贯彻得越好，你的剧本维护成本就越低。第三，善用社区的角色库——Ansible Galaxy上有大量现成角色，不用重复造轮子。但引入第三方角色前，一定要通读其tasks目录，因为别人的写法你未必认同，出了安全问题更不划算。

我自己现在写任何一套自动化部署，都是从最小可用的Playbook起步，跑通后再逐步加角色、加变量、加CI联动。最忌讳的是一上来就设计一个庞大无比的目录结构，结果写了一半自己都不想维护。先让机器动起来，再慢慢把代码变优雅。这大概也是Ansible教给我的最朴素、也最实用的道理了。