只需6步，教你把服务迁移到云端

责任编辑：jackye 作者：张英洁 |来源：企业网D1Net 2016-02-24 09:34:10 本文摘自：INFOQ

Ghost是一个开源博客平台，而Ghost(Pro)是它的托管平台。这篇文章的作者是Ghost的高级DevOps工程师Sebastian Gierlinger。他用简单的6个步骤，总结了Ghost(Pro)的基础设施从专用服务器迁移到DigitalOcean Droplets的过程。

以一年多运营Ghost(Pro)的经验来看，我们认为自己的下一代基础设施需要满足如下需求：

能够在几分钟内对服务器扩容拥有能服务数千个博客的大内存提供强大的客户支持在不做重大重构的前提下迁移软件

任何一个项目的迁移，都以一定程度的不确定性开始。一开始就预料到所有的迁移步骤是不可能的，更不要说预料到任何一个即将遇到的问题。但鉴于这是一篇回顾文章，出于方便理解的目的，迁移过程包括以下几个大步骤：

为现有的服务器基础设施建立目录确保公网安全确保专用网络安全备份数据库更新DNS（切换到目标服务器）下线旧的运行环境

迁移后的Ghost(Pro)系统架构是这样的：

　　下面就让我们来详细看看迁移过程的6个步骤。

Step 1：创建目录

第一步是用配置管理工具创建一个目录，用来显示现存的服务器基础设施上运行着什么。

我们并没有一个完整的目录，包含所有安装的软件、防火墙设置和其他服务器配置。为了解决这个问题，我们引入了一个配置管理系统工具箱。配置管理的一大好处就是，一旦系统建立起来，它既可以作为记录文档，又可以用作一个部署工具。

我们考虑过几个比较流行的配置管理工具，包括Puppet、Chef、Ansible和SaltStack。我们需要一个既能完成工作又不容易因为复杂性而过载的工具。最终就选择了SaltStack。

下面是几个选择SaltStack的原因：

它很轻量，易于安装和维护；它采用master/minion的架构，可以将更改从master“推送”到minion端，避免了由于频繁请求可能造成的DDoS攻击；它拥有一个专门的主服务器，可以防止管理员和开发者直接在未受保护的生产环境部署更改；Master和Minion的通信采用ZeroMQ而不是SSH。在处理多个加密并发连接时，ZeroMQ使用更少的CPU资源，效率更高。

另一个附加的好处是Salt Cloud，它包含在SaltStack里，并且和DigitalOcean的API无缝兼容，资源可以快速弹性伸缩，我们可以用命令行管理系统资源。

虽然这个新的Ghost(Pro)架构初始设置和配置颇花费了一些时间——大概3周，但SaltStack表现除了它强大的功能。第二步迭代配置用了大概一周，第三步部署托管平台只用了两天。

创建一个目录，并把它迁移到配置管理工具，这是一个迭代的过程，会涵盖几乎整个系统迁移的过程。除了完成迁移，创建目录还暴露了我们结构中需要改进的部分。读者如果想要尝试SaltStack更多功能，请参考使用手册：1、2、3.

Step 2：确保公网安全

第二步是为了确保平台内部服务器的公网防火墙安全。

以前，只有我们面向公众的服务器可以通过外网访问；其他服务，比如APP和数据库服务，只能通过专用网络访问。迁移到DigitalOcean的云端后，所有服务器都有一个公共IP地址，我们必须解决这项新的安全隐患。

我们给内部服务器的公网设置了一个iptables规则，能够拦截除了SSH加密通信的其他所有连接。我们自己的服务器用的是Ubuntu，所以用UFW作为iptables的管理界面。

和其他基础设施一样，防火墙配置是通过SaltStack完成的，方便于我们统一管理。

Step 3：确保专用网络安全

第三步是用VPN确保所有服务器专用网络的安全。

DigitalOcean的专用网络允许同一数据中心的Droplets彼此通信。这个特点非常棒，它在基础设施内保证了高带宽和低延时，专用网络被共享给数据中心所有的Droplets，包括那些属于其他DigitalOcean客户的Droplets。这就是说，专用网络保护我们不会被接入一般的互联网连接，但可能接入其他不属于我们的Droplets。

我们选择配置VPN来确保服务器专用网络的安全，它提供的加密和身份认证正是我们所需要的。我们选了Tinc VPN，因为它有网状路由布局，这意味着它的流量会尽可能直接发送到目标主机。它允许通过直连的Droplets发送流量，而不必直接与请求者相连。不像OpenVPN那样把VPN管理复杂化，我们的VPN更像是个传统的专用网络。

就像防火墙配置一样，我们用SaltStack集中管理VPN配置。这样就可以在所有服务器中自动更新Tinc VPN的配置，从而保证了所有VPN网络的正确和及时更新。

Step 4：启动数据库备份

第四步是设置备份来迁移数据库。

最初，我们计划在数据库迁移期间把Ghost(Pro)下线。这样暂停一下，我们就可以保持数据的连续性，并为MySQL数据库备份。然后我们再把备份传到新数据库服务器上，最后重置一下就能完成数据库迁移。然而，分析完现有数据后，我们发现这并不可行。我们有大约500G的数据库，这意味着预计需要6小时的下载时间，还不包括任何意外的错误。服务下线那么长时间是不能接受的。我们需要其他解决方案。

我们决定首先迁移备份数据库，这样可以保证在迁移数据的一致性，同时也能保证数据库迁移过程中线上服务不中断。下面简述备份步骤：

配置Master/Slave备份

把原始数据库服务器设置为master，新数据库服务器设为slave。这意味着从原始数据库系统到新架构的数据库备份是单向的。

测试新基础设施

用这样的master/slave设置，就可以测试了，看我们新的Ghost(Pro)系统是不是和原有设置保持一致。所有测试完成后，我们删除了新的数据库服务器（slave）数据来为下一步做准备。

配置Master/Master备份

新数据库服务器测试后，我们开启了master/master备份，这意味着所有的数据变更是双向的。一旦开启master/master备份，原始数据库被迁移到新服务器上，新的基础设施准备就绪了。更多关于数据库迁移的教程，请参考1、2。

Step 5：更新DNS记录

第五步是更新DNS记录，以此把新基础设施投入使用。

更新DNS记录有时候会出现问题，因为DNS生效需要时间。如果处理得当，生效时间是几个小时，用户可以使用新老系统。我们使用CloudFlare管理DNS条目，它支持实时修改DNS，这样我们就能避免可能出现的问题了。

当准备启用新系统时，我们执行了以下步骤。首先，更新ghost.org，使它指向新的核心服务器；然后，测试运行；最后，更新ghost.io，使它指向新缓存服务器，再多测试几次。

Step 6：下线旧的运行环境