数据库运维开发环境的调试模式演进

这是学习笔记的第 2393篇文章

昨天同事反馈了一个问题，原本的办公机环境中的虚拟机是可以对外暴露办公机的IP,提供相应的数据库运维API服务，比如办公机的IP是192.168.10.100，而虚拟机使用virtualbox，使用了主机模式，IP可能是192.168.56.100，那么192.168.56.100上面的API服务可以对外使用192.168.10.100来访问。一般开发环境测试完成之后，就推送到GitLab，经过验证就发布了，所以测试有测试的相关服务，线上有线上的相关服务，IP方式模式都是相对固定的。

听起来是一件挺简单的事情，最近这种多服务间进行联调的模式不可用了，也就是上图红色的部分所示，如果使用桥接模式的IP,在网络那边有明确的限制，也是不可行的，所以原本简单粗暴的测试联调就得转换思路了。

我们想了一种思路，那就是申请一台新的Linux服务器，保持和线上一致的环境，然后开启桌面模式，那么办公机就可以通过vnc等方式连接到Linux服务器了，然后在Linux下开发测试，提交代码变更，听起来是一件很不错的主意，而且统一的Linux环境还可以共享基础的配置，免去了很多人重复配置环境的苦恼，整体设计如下图所示：

但是这种模式有几个问题，其中一个是测试Linux服务器上面的代码是大家分别测试，但是提交是个问题，如果要想最大限度的保证效率，那么可能大家都可以向主分支提交代码，那样一来就有点乱了，而且麻烦的是一旦发现冲突，其实就确实一个统一去merge的角色。另外一点是远程桌面的办公模式是相对可行的，如果网络不够好，还是比较痛苦的，退一万步来讲，肯定开发的效率是本机最方便效率最高的。

期间我们也讨论了干脆申请一台统一的Windows服务器，排除Python依赖库的差异，我们不能确认的是在Windows上正常运行的服务，是否在Linux上完全可用，所以这个方案也被我们很快抛弃了。

还有一种模式，是我们使用办公机来开发逻辑，假设我们通过一种机制把变更的代码先推送到开发服务器（Linux）上面，那么这个服务就是一个相对固定的访问模式了，在开发联调中的问题如果要修改，可以不断的调整，直到满足业务场景的测试，那么问题就来了，有什么样的机制能够保证我们可以把代码随时同步发布到IDC的开发服务器，如下图红色部分所示：

这个时候有很多潜在的解决方案，我先想到了两种:

1)第一种，我们使用Filezilla在办公机上面文件的传输，也算是一种快速发布模式

2）第二种，我们可以在办公机上面配置一个bat脚本，实现文件从虚拟机上面下载，然后推送到测试环境

虽然都可行，但是感觉流程还是缺点东西，所以我们继续想，有了下面的方案，也就是IDC测试服务器上面配置一个WEB文件服务，默认的Python文件服务也就是一条命令的事情，但是这里我们得做下额外的工作，那就是得保证WEB文件服务可以上传文件，所以需要简单写一个Python脚本来实现，改进后的方案如下：

这种方案带来的好处就是我们可以制定策略，来满足个性化的配置和快速发布。

比如有A,B,C三个人，那么三个人在IDC测试服务器上面可以使用不同的目录，使用不同的WEB文件服务，比如：

A,配置7001的API端口，配置9001的WEB文件服务

B,配置7002的API端口，配置9002的WEB文件服务

C,配置7003的API端口，配置9003的WEB文件服务

如此一来，经过测试，整个过程是可以随意发布，随意测试，而且对其他人都没有直接的影响，而经过测试的代码就可以按照测试情况进行提交，合并到主分支了。