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

jopen 4年前

英文原文:How Ghost Migrated From Dedicated Servers to DigitalOcean

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

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

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

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

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

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

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

下面就让我们来详细看看迁移过程的 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 更多功能,请参考使用手册:123.

Step 2:确保公网安全

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

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

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

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

Step 3:确保专用网络安全

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

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

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

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

Step 4:启动数据库备份

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

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

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

  1. 配置 Master/Slave 备份

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

  2. 测试新基础设施

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

  3. 配置 Master/Master 备份

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

Step 5:更新 DNS 记录

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

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

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

Step 6:下线旧的运行环境

最后一步就是下线旧运行环境中的服务器。所有服务都运行在新的 DigitalOcean 中,我们不再需要原来的专用服务器基础设施了。淘汰旧的设备能大大节省我们的开支。

在关停旧的基础设施前,我们需要停掉新旧数据库服务器的备份。

结语

把 Ghost (Pro)平台从专用服务器迁移到 DigitalOcean 非常成功。我们希望分享自己的经验,因为我们知道业务迁移是很多项目面临的一个挑战。我们希望自己迁移到 DigitalOcean 的分享对其他准备迁移的项目能有借鉴意义。

来自: InfoQ