Ansible批量配置高可用节点的核心是通过代码固化一致性与冗余性。需明确共性需求（如多节点服务协同、状态共享、VIP漂移、配置统一），完成控制节点与被控环境准备（安装Ansible、SSH密钥登录、连通性测试），结构化编写主机清单分离环境与角色，用Playbook结合变量与Jinja2模板统一部署组件（如Keepalived+HAProxy），并验证故障转移实效性。
用 Ansible 批量配置高可用节点，核心是把“一致性”和“冗余性”通过代码固化下来，而不是靠人工逐台操作。关键不在命令多复杂，而在结构是否清晰、变量是否可复用、失败能否快速定位。
明确高可用节点的共性需求
高可用不是简单装几台一样服务的机器，而是让它们能协同工作、自动故障转移。典型需求包括：
- 同一服务在多个节点上运行（如 Keepalived + HAProxy、RustFS 存储服务、etcd 集群）
- 节点间共享状态或选举主节点（需时间同步、网络互通、密钥信任）
- VIP（虚拟 IP）由 Keepalived 管理，在主节点宕机时自动漂移
- 所有节点配置必须严格一致（版本、端口、证书、启动参数）
准备控制节点与被控环境
这是所有批量操作的前提，漏一步就卡住：
- 在控制节点安装 Ansible（Ubuntu 用
sudo apt install ansible -y，CentOS 用sudo yum install epel-release ansible -y） - 所有被控节点开启 SSH 服务，且允许密钥登录（禁用密码登录更安全）
- 控制节点生成密钥对，并用
ssh-copy-id或authorized_key模块分发公钥到全部节点 - 测试连通性：
ansible all -m ping -i your_inventory_file，确保返回SUCCESS
编写结构化主机清单（Inventory）
别直接写死 /etc/ansible/hosts，推荐项目内自定义 inventory 目录，例如：
# inventories/prod/hosts [rustfs_nodes] node1 ansible_host=192.168.1.101 ansible_user=root node2 ansible_host=192.168.1.102 ansible_user=root node3 ansible_host=192.168.1.103 ansible_user=root [rustfs_nodes:vars] cluster_vip: 192.168.1.200 cluster_port: 8080
这样能把环境差异（如测试/生产）和节点角色完全分离，后续 Playbook 可直接引用 {{ cluster_vip }}。
用 Playbook 实现高可用组件的统一部署
以 Keepalived + HAProxy 为例，一个 Playbook 就能完成三件事：安装、配置、启动。重点在于把“谁是主、谁是备”用变量控制：
-
在
group_vars/rustfs_nodes.yml中定义：keepalived_state: "{{ 'MASTER' if inventory_hostname == 'node1' else 'BACKUP' }}" keepalived_priority: "{{ 100 if inventory_hostname == 'node1' else 90 }}" -
Playbook 中任务示例：
- name: 安装 keepalived 和 haproxy apt: name={{ item }} state=present update_cache=yes loop: [keepalived, haproxy] - name: 部署 keepalived 配置 template: src=keepalived.conf.j2 dest=/etc/keepalived/keepalived.conf notify: restart keepalived - name: 启用并启动服务 service: name={{ item }} state=started enabled=yes loop: [keepalived, haproxy]模板文件
keepalived.conf.j2里用 Jinja2 渲染{{ keepalived_state }}和{{ keepalived_priority }}，避免硬编码。
验证高可用是否真正生效
部署完不能只看服务 running，要模拟故障：
- 手动
systemctl stop keepalived在主节点上，观察 VIP 是否秒级漂移到备节点（用ip addr show查看） - 用
curl http://{{ cluster_vip }}:{{ cluster_port }}持续请求，确认无中断 - 检查各节点日志：
journalctl -u keepalived -n 50 --no-pager，确认Transition to MASTER/BACKUP日志正常出现
不复杂但容易忽略。
