在接手管理超过 500 台服务器时，我意识到继续使用 SSH 循环跑 Shell 脚本简直是自杀。不仅执行慢，而且无法保证幂等性（Idempotency）——脚本跑一半报错了，重跑会不会破坏系统？
Ansible 成了我的救星。它无 Agent（Agentless）、基于 SSH、语法简单（YAML），非常适合从传统运维向自动化运维转型。
1. 为什么选择 Ansible？
- 无 Agent: 不需要像 SaltStack 或 Zabbix 那样在每台机器上安装客户端，依赖 SSH 和 Python 即可。
- 幂等性: 大多数 Ansible 模块（Module）都是幂等的。例如
yum模块，如果包已经安装，它什么都不做；如果没安装，它才执行安装。 - 声明式: 你只需要描述“想要的状态”（State），而不是“怎么做”。
2. 核心组件最佳实践
2.1 Inventory 管理
不要把 IP 写死在 /etc/ansible/hosts 里。
- 分组策略: 按业务线、环境、地理位置分组。
[webservers:children] web_prod web_stage [web_prod] 10.0.1.[10:20] [db_servers] db-master ansible_host=10.0.2.10 - 动态 Inventory: 如果你的机器在 AWS 或阿里云上，使用 Dynamic Inventory 脚本直接通过 API 获取主机列表，实现自动发现。
2.2 Playbook 与 Roles
不要写几千行的巨型 Playbook。使用 Roles 进行模块化拆分。
推荐目录结构：
site.yml
roles/
common/ # 基础配置：NTP, Users, SSH keys
nginx/ # Nginx 安装与配置
mysql/ # MySQL 安装与优化
app_deploy/ # 应用部署逻辑
Role 的复用性: 一个写得好的 Nginx Role，应该能通过传入不同的变量（Variables），同时支持静态站点、反向代理和负载均衡配置。
2.3 变量管理 (Variables)
group_vars/: 存放全局或组级别的变量（如 DNS 服务器、Repo 地址）。host_vars/: 存放特定主机的变量（如 Router ID）。- Vault: 敏感信息（密码、Key）必须使用
ansible-vault加密，严禁明文提交到 Git。
3. 编写健壮的 Playbook
3.1 错误处理
默认情况下，Ansible 遇到错误会停止在当前主机上的执行。
ignore_errors: yes: 忽略非关键错误。failed_when: 自定义失败条件。例如，grep 没找到字符串通常返回 1，但这可能不是错误。changed_when: 显式定义何时算“变更”，保持输出整洁。
3.2 Handlers 的妙用
修改配置文件后重启服务，不要直接写 Task，而要用 Handler。
tasks:
- name: Copy nginx config
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
notify: Restart Nginx
handlers:
- name: Restart Nginx
service:
name: nginx
state: restarted
这样，无论配置修改了多少次，Nginx 只会在最后重启一次。
4. 大规模集群性能优化
管理几台机器很快，但管理上千台时，Ansible 可能会很慢。
- 开启 SSH Pipelining: 减少 SSH 连接次数。在
ansible.cfg中设置pipelining = True。 - 调整 Forks: 默认并发是 5，太保守了。根据控制机性能，调大到 50 甚至 100。
[defaults] forks = 50 - Fact Caching: 收集主机信息（Gather Facts）很耗时。开启 Redis 或 JSON 文件缓存，避免每次运行都重新收集。
- Mitogen: 一个第三方插件，能将 Ansible 执行速度提升 3-7 倍（强烈推荐）。
5. 总结
自动化运维的目标是“将人的时间从重复劳动中解放出来”。Ansible 不仅仅是一个工具，更是一种“基础设施即代码”（IaC）的思维方式。当你把所有的系统配置都代码化后，服务器就从“宠物”变成了“牲口”——随时可以销毁，随时可以重建。