前言

过去手动部署 1 个高可用 apollo 集群并验证往往需要 1 ~ 2 个工作日，现在1 个工作日（7小时）可以部署 24 套，部署一套只需 18 分钟，并且所有集群都是生产就绪的，如何实现的？

TL;DR

• 基于 vscode 的统一开发环境
• 基于 libvirtd 的配套测试环境
• 基于 wireguard 的私网 gitlab 和生产服务器集群加密通信虚拟局域网
• 基于 gitlab 的多分支开发模式
• 基于 gitlab ci 的运维代码自动同步

统一的开发环境 & 可重复的测试环境

在我司办公区机房有一台 Linux 物理服务器，我使用这台服务器作为统一开发环境，平时所有的 ansible 代码编写工作都是通过 vscode remote development 登录这台物理服务器完成。下面是常见的 2 种访问方式：

每一个开发者会有自己的一个 Linux 普通用户，开发者只需在自己的电脑上安装好 vscode，通过 vscode remote development 插件和自己在服务器的普通账号 ssh 连接物理服务器即可， vscode 会在各自的开发者用户下运行 vscode server 进程，因为 vscode 实际上都跑在同一台物理服务器上，所以其他开发者就有了跟我一模一样的 ansible 开发环境。

这篇博客也是通过 vscode remote development 方式，编写出来的，如下图：

我给该物理服务器上默认配置好了全局代理加速，安装了 ansible、ansible-lint，并通过 libvirtd 虚拟化了多台跟生产环境相同系统、相同版本的虚拟机用于测试。因为这些虚拟机是运行在物理机虚拟化内的，所以可以非常方便的给这些虚拟机打快照。我给所有虚拟机准备了一份跟生产一致的快照版本，然后在这个快照基础上测试 ansible 代码，如果测试不通过需要重复测试，只需通过物理服务器上写好的恢复脚本，执行脚本一键恢复所有虚拟机的状态到最新的快照指定的状态，然后重复测试即可。

有了以上的准备，就可以实现高频率的 ansible 开发和测试，从而确保 ansible 代码的高度兼容和稳定可靠。

未来我们的生产服务器系统将逐步从 CentOS 过度到 OpenEuler（欧拉）系统，通过自建 OpenEuler 虚拟化并开展频繁的 ansible 代码兼容性测试，我们就能实现平滑的 CentOS 到 OpenEuler 的过渡了。

基于 WireGuard 的运维网络

这块与实际情况并不完全一致

公司的 gitlab 在办公区内网，但生产服务器分布在全国 34个省级行政区的自建机房，我们通过 gitlab 存放所有运维代码，然后通过 ci 自动同步到每个机房的管理服务器，最后由相关的运维同事登录管理服务器并执行 ansible playbook。如果要实现高质量、高效率的代码化运维，实现 gitlab 和每个机房的管理服务器的安全通信是必不可少的。

我们现在采用的是 WireGuard Point to Sites 的网络架构，如下图：

运维网转发节点是整个网络的中心，上面运行 WireGuard 作为服务端，具备公网 IP （假设是 1.2.3.4）。每个省份有一台运维管理服务器用于触发 ansible-playbook，运行 WireGuard 作为客户端，具备出公网的能力（可以 ping 通 1.2.3.4）。每个加入网络的客户端服务器会多一张虚拟网卡并得到一个 10.188.188.0/22 段的 IP，网络内的所有主机通过 10.188.188.0/22 的 IP 可以互相访问。

安全上，运维网转发节点通过 firewalld 限定请求的来源 IP，只有省份的管理服务器才允许访问运维网转发节点，从而归避免安全风险。

我们让 gitlab 服务器作为运维网的其中一个客户端，同样具备 10.188.188.0/24 的 IP，在管理服务器上安装 gitlab runner，并通过这个 IP 向 gitlab 注册自己，从而实现了跨分省的自动化运维。

gitlab 多分支协同

我们的开发模式是基于 gitlab 的多分支协同，有一条以自己的名字命令的分支，通过：

git pull --rebase --autostash origin master

跟最新的 master 分支保持同步并基于 Fast Forward 的 Merge 策略，从而保持简单的 git 记录。

我们的所有运维代码都存放在一个名为 infrastructure 的仓库内，里面的运维代码分为操作和数据，操作会被抽象为 ansible role 提交到 gitlab 以做复用；数据会被进一步分为敏感和不敏感数据，敏感数据加密后再提交到 gitlab，加密采用的是 gnupg + ansible-vault 的形式。在统一开发环境和每个机房管理服务器有 gnupg 的私钥。在开发时，如果需要编辑私密数据，只需执行：

ansible-vault decrypt group_vars/vault_example.yml

此时会触发 gnupg 提示输入密码用于鉴权（只有知道密码的人才能执行 ansible playbook）

编辑完成后，执行：

ansible-vault encrypt group_vars/vault_example.yml

重新加密然后提交到 gitlab 即可。

在调用 ansible playbook 时，也会自动触发 gnupg 弹出输入解密的窗口，输入正确的密码后即可顺利执行 ansible playbook。

因为运维代码化仓库中私密数据是加密的，所以我们可以向全公司开放运维代码，从而在公司内部实现安全可靠的运维设施和架构的开放。

运维代码自动同步

经过评审合并到 master 分支的运维代码会被认为是成熟的运维代码，会触发 gitlab ci 自动同步代码到所有的机房的运维管理服务器，如下图：

运维人员通过登录每个机房的运维管理服务器，执行相关的 ansible playbook，基于内网实现所有服务器的代码化管理。

最后附上开发流程图：