使用Ansible配置两台配置相互依赖的服务器的最佳方案

你提到的拆分双playbook的方案完全可行，也是这类集群部署场景的主流成熟落地方案，符合Ansible的官方最佳实践。

核心逻辑 #

这类有跨节点依赖的场景，核心思路是先完成所有节点的基础设施交付，收集全量元信息后再统一做上层配置，避免边创建边配置时的变量缺失问题。

具体落地步骤 #

• 第一个playbook：负责基础设施交付与信息采集
  • 按现有逻辑依次创建虚拟机A、B，创建完成后通过setup模块、云厂商SDK模块或者自定义的信息拉取脚本，采集两台机器的IP、初始登录密码等需要的元数据
  • 将采集到的信息写入独立的变量文件（推荐yaml格式）或者直接更新Ansible inventory文件，示例变量格式如下：

    cluster_nodes:
      node_a:
        ip: 192.168.1.12
        ansible_ssh_pass: "your_password_a"
      node_b:
        ip: 192.168.1.13
        ansible_ssh_pass: "your_password_b"
    

  • 不推荐用临时内存变量存储，写入静态文件方便后续排查问题时回溯节点初始信息，也支持后续配置playbook单独重跑
• 第二个playbook：负责上层服务配置
  • 执行前先加载第一步生成的变量文件/inventory，此时两台节点的所有需要的信息都已经存在全局变量中
  • 配置节点A时直接引用cluster_nodes.node_b.ip、cluster_nodes.node_b.ansible_ssh_pass即可，配置节点B时同理引用A的变量
  • 如果服务配置是幂等的，可以先给两台节点都写入对方的配置信息，再统一启动服务，完全不会出现依赖冲突

可选精简方案 #

如果不想拆分两个独立playbook，也可以把逻辑拆成同一playbook下的三个play段：

1. 第一段仅在本地控制节点执行，完成两台虚拟机的创建、信息采集，把变量注册到全局作用域
2. 第二段针对节点A执行配置，直接调用已采集到的B的变量
3. 第三段针对节点B执行配置，直接调用已采集到的A的变量

但更推荐双playbook的拆分方案，基础设施层和配置层完全解耦，后续调整虚拟机配置、新增节点都不需要修改上层配置的代码，可维护性更高。
这类多节点依赖的集群（高可用集群、分布式存储、数据库主从等）部署基本都是这套分层逻辑，已经是业内通用的成熟方案，不需要额外做复杂的跨节点变量轮询、动态依赖判断等逻辑。

内容的提问来源于stack exchange，提问作者TSG