一次服务器迁移的总结

虽然其实整个过程就是很low，但是呢，毕竟第一次做一整坨服务器的迁移。所以还是强行假装很高端的样子。

迁之前##

首先是事件的起因。时间的起因大概就是digital ocean(DO)的服务器本来和vultr(V)的服务器价格一样的，然后我的服务器基本都在DO上。然后V的服务器降价了一半，然后所以理所应当的，所有服务器都会从DO迁往V。

然后就是我服务器的一个节奏：

• jenkins的master服务器，主要任务就是运行jenkins的网站，打包软件，部署软件，不跑build。
• jenkins的node服务器，啥也不干，就跑build。
• jenkins的node服务器2号，这个服务器厉害之处就在于这个服务器是带desktop的，所以不仅会跑build，还会跑软件的functional测试。
• db服务器，就很弱鸡的一个db服务器，啥都没有。
• 流量服务器，就是跑一个微信公众号的server，然后跑一个应用的登陆服务器，然后跑一个ss服务器。这个服务器本身就在V上。
• 应用服务器，就是跑了两个应用在上面。

迁的过程##

第一波###

首先就是升级流量服务器，因为降价之前，人家是5刀700多M内存，然后降价后还是5刀1G内存，所以要升级。但是这个升级就很简单，点一下V自带的升级就好了。

然后就是迁应用服务器。因为应用服务器全部都在docker里，所以直接申请了instance。然后jenkins里有安装服务器的job，会装docker在内的一堆工具。装完了之后，把之前应用的部署job的服务器ip改一下，就可以上车了。但是要命的是，要让流量服务器知道应用在哪。所以去数据库里手工改了一下应用服务器的ip地址。

虽然说我db服务器没有docker。但是呢，讲道理迁数据库主要是迁数据，谁管你数据库怎么样了。所以用jenkins里用来备份数据库的job，备份了一发。跑到新申请的db的instance上，手工装上db，然后手工导入了数据。

最愉快的还是迁jenkins的node了。因为jenkins的性能始终是慢的，所以现在jenkins的node变成了两个node。所以，只需要跑到jenkins改下node的配置就好了。爽的不行。

第一波迁移话了2小时。主要是认证ssh，改jenkins的时候各种帕金森综合症，手抖的不行。主要是11点的时候，都准备说睡觉了，突然跟我说要迁服务器？于是就剩下了jenkins的master服务器，和跑UI的node。

---

第二波###

在第二波和第一波之间，大概经历了，jenkins的job的一个重组，然后才开始第二波

我的jenkins没有在docker里，然后起了个服务器，装了个jenkins，给了root权限给jenkins，然后导入了jenkins的备份。然后把原来服务器的各种key，全部考了过去。然后更新所有地方的web hook。最气的，还要把所有应用的各种配置，一起发送到新的节点去。然后至今不敢destroy掉原来的jenkins，就是怕考掉了什么。这个的确有待改进。

然后迁ui的node。主要恼火在于要装VNC，虽然理论上我也不知道为什么要装。感觉装个图形界面就够了，但是还是装了一发VNC。然后把之前的build迁到新的node上。然后各种悲剧。首先是jenkins的各种job的地址配错，漏配，这个是和jenkins的job没有整理好造成的，重复的ip多次出现。然后就是需要连接到VNC上去跑gradle，目测是没有插件的。所以就不能利用jenkins自动装gradle，然后就要手工装，然后还要能自己连到自己的ssh。反正很诡异

但就此为止，反正这一次迁移算是完成了。

迁的结果##

所有服务全不转移到了V上。DO上目前除了留了个jenkins服务器准备关机一段时间之外，所有服务器已经全部销毁。空留了大概XX刀在上面。

然后准备进一步整理jenkins，把服务器的信息作为jenkins的环境变量处理，然后公用。不然之后迁服务器简直要命了。

最后，docker大法好，天灭手动部署。人在做，天在看，手动部署留祸患。个位上网搜，九评手动部署，有真相。