来自Ghost的文章
简介
这篇DigitalOcean Blueprint文章由Ghost的高级DevOps工程师Sebastian Gierlinger撰写。它涵盖了将Ghost（Pro)基础设施从专用服务器迁移到DigitalOcean Droplets所采取的步骤。在每个步骤中，Sebastian将讨论所面临的挑战，如何解决每个挑战，以及为什么选择每个解决方案。他还将提供他认为有用的相关资源的链接。编辑
Ghost(Pro)是Ghost的托管平台，Ghost是一个开源博客平台，用户只需点击几下就可以租用预先构建的Ghost博客。Ghost(Pro)是管理Ghost开源项目的非营利性组织Ghost Foundation的持续资金来源。Ghost(Pro)最初托管在专用服务器上，后来迁移到DigitalOcean以实现按需扩展。
问题陈述
在2014年最后一个季度，Ghost(Pro)的增长速度迅速超过了其原有的专用服务器基础设施，因为它每月处理来自数万个博客的约1亿个请求。扩展现有基础设施将需要大约两个月的准备时间来购买和部署新的物理服务器。简而言之，扩展专用服务器基础设施的限制正在威胁Ghost(Pro)平台的发展，并因此威胁到Ghost开源项目的进一步发展。
我们需要解决我们无法快速扩展的问题，以免它通过迁移到改进的基础设施而对客户或我们的增长产生负面影响。
要求
从我们运行Ghost(Pro)一年多的经验来看，我们很清楚需要做些什么来改善我们的服务。我们确定我们的下一个基础设施应满足以下要求：
- 能够在几分钟内扩展服务器容量
- 有足够的内存为数千个博客服务
- 提供出色的客户支持
- 允许我们在不进行重大重构的情况下迁移软件
DigitalOcean满足了所有这些要求。
在规划迁移期间，我们确定需要执行零停机迁移。我们将在稍后讨论这一点的技术原因。
迁移大纲
计划任何项目的迁移都是从一定程度的不确定性开始的；根本不可能预测到所有必需的步骤，更不用说会遇到的任何问题了。我们的迁移计划是通过研究和实施的迭代过程形成的。
由于这是一篇回顾文章，我们能够将迁移过程组织成以下几个广泛的步骤，以便更容易理解：
- 创建现有服务器基础设施的库存
- 安全的公网
- 安全的专用网络
- 复制数据库
- 更新DNS(仅切换到目的服务器)
- 停用旧环境
如今，作为迁移的结果，Ghost(Pro)服务器拓扑如下所示：
- CloudFlare提供内容分发网络(CDN)、域名服务(DNS)、缓存和防范恶意请求
- 核心服务器托管ghost.org，负责用户和支付管理
- 使用缓存服务器进一步加快响应速度，并将请求定向到正确的博客
- App Server Pool由许多运行我们客户的Ghost博客的App服务器组成
- DB集群是保存您的博客数据的MySQL数据库集群
- GitHub负责我们的源代码管理
- Ruxit负责监控Ghost(Pro)基础设施
- Amazon S3用于存储加密的异地备份
让我们看一看实现我们新的、可扩展的服务器基础设施的步骤。
第一步：创建库存
第一步是使用配置管理工具创建当前在我们现有的专用服务器基础设施上运行的清单。
为什么？
在规划任何服务的迁移时，拥有一种可靠地重现现有环境的方法非常重要。这将有助于确保迁移顺利进行。当然，这需要考虑到每个服务器和软件组件。
当Ghost(Pro)第一次安装时，为了让它快速启动和运行，采取了一些捷径。我们手动配置了原始服务器，因此，尽管现有平台运行良好，但我们没有记录每一个微小的配置细节。
如何操作？
为了解决没有安装的软件包、防火墙设置和其他服务器配置的完整清单的问题，我们在工具包中引入了配置管理系统。配置管理的好处之一是，一旦设置了系统，它就兼有文档和部署工具的作用。
在选择配置管理 系统时，我们考虑了几个流行的配置管理工具，包括Pupet、Chef、Ansible和SaltStack。我们需要一个既能完成工作又不会因复杂性而过载的工具。最终，我们选择了** SaltStack** 。
以下是我们决定使用SaltStack的一些原因：
- 重量轻，易于安装和维护
- 它使用主/从管理基础设施，在该基础设施中，盐主将更改
推给小黄人。这意味着，与小黄人从主程序获取更改的架构相比，主程序被数百个小程序试图联系的DDOSID的风险降低了 - 它有一个专用的主服务器。这将防止管理员和开发人员直接从未受保护的开发人员计算机部署更改
- 它使用ZeroMQ而不是SSH来进行主人和小黄人之间的通信。ZeroMQ使用更少的处理器功率，在处理多个并发连接时比SSH更高效，同时仍提供加密
作为额外的好处，SaltStack中包含的Salt Cloud与DigitalOcean API紧密集成，通过生成新的水滴来扩展我们的服务，并允许我们从命令行管理基础设施。事实证明，它是一个非常重要的工具，可以在几分钟内可靠地启动、停止和部署服务器。
结果
虽然新的Ghost(Pro)基础设施的初始设置和部署花了一些时间--大约三周--但SaltStack已经展示了它的力量。第二次迭代花了大约一周的时间进行部署。我们的托管平台的第三次安装只花了两天时间，这将成为我们今天的生产系统。
创建清单并转移到配置管理工具是一个迭代过程，几乎跨越了我们平台的整个迁移过程。除了使迁移成为可能外，它还暴露了我们的设置中需要改进的部分。
资源
如果您希望开始使用SaltStack，请查看数字海洋SaltStack系列的第一个教程：SaltStack术语和Concepts.简介在那里，您将找到其他教程，帮助您在自己的基础设施中使用SaltStack。
如果您有兴趣了解其他一些流行的配置管理工具，这里有一些教程可以帮助您入门：
第二步：公网安全
第二步是使用防火墙保护我们平台内部服务器的公共网络。
为什么？
在我们的旧环境中，只有面向公众的服务器可以在互联网上使用。我们所有的其他服务器，如应用程序和数据库服务器，都只能通过内部专用网络访问。随着向DigitalOcean云的转移，每台服务器--即使是那些不需要公开访问的服务器--都有一个公共IP地址，我们需要解决这个新的安全问题。
如何操作？
我们通过设置iptabLes防火墙 来保护内部服务器的公共网络，该防火墙可以阻止除SSH流量以外的所有流量。因为我们的服务器运行的是Ubuntu，所以我们使用UFW作为iptabes的接口。
与基础设施的其余部分一样，我们的防火墙配置通过SaltStack进行集中管理。这使我们能够轻松管理所有服务器上的防火墙，即使是需要特殊防火墙规则的服务器也是如此。
结果
所有非公共服务器，包括应用程序和数据库服务器(见拓扑图)，对公众的访问都被阻止。除了我们将稍后讨论的专用网络之外，我们所有的内部服务器都只能通过基于证书的身份验证通过SSH进行访问。
资源
如果您想了解防火墙的基础知识，请从什么是防火墙以及如何使用Work？教程]开始学习。它解释了防火墙的基础知识，并提供了指向其他教程的链接，这些教程将帮助您设置防火墙，以使用iptabes、UFW或FirewallD(CentOS)保护您的公共网络接口。
第三步：安全内网
第三步是使用VPN保护我们所有服务器的专用网络。
为什么？
DigitalOcean的专用网络功能允许同一数据中心内的水滴相互通信，而不会将流量发送出数据中心。虽然这一功能很棒，因为它支持在我们的基础设施内进行高带宽和低延迟连接，但专用网络由数据中心的所有水滴共享，包括属于其他DigitalOcean客户的水滴。也就是说，我们的专用网络受到保护，不受一般互联网连接的影响，但不一定不受不属于我们的专用网络上的水滴的影响。
如何操作？
我们选择通过设置VPN(虚拟专用网络)来保护我们所有服务器的专用网络。VPN提供的加密和身份验证功能非常适合我们的需求。
我们选择TINC 作为我们的VPN解决方案，主要是因为它使用网状路由布局，这意味着VPN流量在可能的情况下直接发送到目的主机。它还允许我们通过连接的液滴来路由流量，以到达没有直接连接到请求者的液滴。与OpenVPN不同，OpenVPN可能会使VPN管理复杂化，因为它通过中央VPN服务器来路由每个连接，而我们的VPN的行为非常像传统的专用网络。
如果我们决定需要跨越多个数据中心，它还允许我们将VPN扩展到远程数据中心中的Drops。
与我们的防火墙配置一样，我们使用SaltStack来集中管理我们的VPN配置。这使我们能够自动更新我们所有服务器中的TINC VPN配置，从而确保我们的VPN成员始终是准确和最新的。
结果
我们基础设施内的所有网络流量都是安全的，因为它通过专用网络接口上的TINC VPN。每个液滴都运行一个TINC守护进程，负责连接(和重新连接)到给定的液滴列表。由于使用网状VPN，服务器之间的VPN连接的配置非常简单。
资源
如果您希望开始使用TINC作为VPN解决方案，请查看如何安装TINC并在Ubuntu 14.04上设置基本VPN》教程。
第四步：启动数据库复制
第四步是通过设置复制来迁移我们的数据库。
为什么？
最初，我们计划在数据库迁移期间使Ghost(Pro)离线。这将允许我们停顿-暂停以确保数据一致性-并创建MySQL数据库的备份。然后，我们可以将备份传输到新的数据库服务器，并恢复它们以完成数据库迁移。然而，在分析了我们现有的数据后，我们很快意识到这个过程是不可行的。我们有大约500 GB的数据库，这意味着迁移将需要大约6个小时的停机时间，这还不包括任何意外错误。让我们的服务离线这么长时间简直是不可接受的。我们需要另一个解决方案。
我们决定使用复制 来迁移我们的MySQL数据库。数据库复制在多个服务器上维护数据库的相同副本，提供了一种在不中断数据库的情况下迁移数据库的方法。这消除了我们的服务停机的需要，并为我们提供了安全网，使我们能够在关闭旧数据库服务器之前测试我们的新数据库服务器。
如何操作？
利用复制来迁移我们的数据库需要一些额外的规划。虽然我们不能包括所有细节，但为了简洁起见，以下是我们经历的重要步骤的顺序。
1.配置主备复制
我们将原始数据库服务器配置为主数据库服务器，将新数据库服务器配置为从数据库服务器。这意味着数据是单向复制的，从原始数据库系统复制到新基础设施中的数据库系统。
2.测试新的基础设施
使用这个主/从设置，我们能够进行负载测试，并查看我们的新Ghost(Pro)系统的行为是否与我们的旧设置相同。请注意，由于设置的性质，在我们的测试期间对从数据库所做的更改不会影响原始(主)数据库。
测试成功后，我们清除了新的(从)数据库服务器中的数据，为下一步做准备。
3.配置主/主复制
测试了新的数据库服务器后，我们激活了主/主复制，这意味着所有数据库更改都是双向复制的。
结果
一旦激活了主/主复制，并将原始数据库迁移到我们的新服务器，新的基础设施就可以使用了。我们有两个Ghost(Pro)基础设施的完整功能实例，旧的和新的，具有同步的数据库。然而，新的基础设施尚未启用，因为ghost.org和ghost.io域名记录--我们的用户如何访问我们的服务--仍然指向旧的基础设施。
这意味着我们的服务迁移现在减少到切换DNS条目以指向新服务器。作为使用master/master数据库复制的一个额外好处，如果我们遇到任何问题，我们的设置将允许我们快速轻松地恢复到旧的基础设施。
资源
要了解有关在您自己的环境中设置数据库复制的信息，请查看以下教程：
第五步：更新域名解析记录
第五步是通过更新我们的DNS记录将我们的新基础设施投入生产。
为什么？
要将我们的新基础设施投入生产，我们需要做的就是分别更新面向公众的缓存和核心服务器ghost.io和ghost.org的DNS记录。
如何操作？
由于传播DNS更改所需的时间较长，更新DNS记录有时会出现问题。如果操作不当，传播可能需要几个小时，用户可能会被发送到旧系统和新系统。我们使用CloudFlare 来管理我们的DNS条目，这使得我们可以实时更改DNS，所以我们能够避免这些问题。
当我们准备开始使用我们的系统时，我们执行了以下顺序。首先，我们将ghost.org更新为指向新的核心服务器，然后测试它是否正常工作。接下来，我们更新了ghost.io以指向新的缓存服务器，然后运行了更多测试。
结果
在更新了我们的DNS记录以指向新的高速缓存和核心服务器后，我们的新基础设施开始运行；我们的所有用户都从我们在DigitalOcean上的新基础设施访问我们的Ghost(Pro)服务，与目前正在生产的服务器集相同。
如果我们遇到任何问题，我们仍然能够恢复我们的DNS更改以切换回原始基础架构。这只需要几秒钟的时间，因为生产数据库对两个基础架构仍然可用，因为主/主复制仍处于活动状态，并且使用CloudFlare的DNS传播几乎是立即发生的。幸运的是，这并不是必需的，因为迁移到新服务器的过程非常顺利。
资源
正如我们所讨论的，我们使用CloudFlare来控制我们服务的域记录。除了他们的DNS服务，我们还为他们的应用防火墙、CDN和DDOS保护付费。他们还免费提供功能较少的基本服务。要使用云Flare管理您的域，请按照此tutorial.]中的配置您的域以使用云Flare部分操作
或者，DigitalOcean还提供域名服务器，您可以将域名指向这些域名。然而，DigitalOcean DNS可能不是迁移项目快速传播DNS的理想解决方案，因为TTL(生存时间)值是不可配置的。了解如何按照本教程进行设置：如何指向DigitalOcean Nameservers.
如果你正在寻找域名系统概念的入门读物，域名系统术语、组件和Concepts入门教程》是一个很好的入门方式。
第六步：退役旧环境
最后一步是淘汰旧环境中的服务器。
为什么？
随着我们的服务完全在我们新的DigitalOcean设置上运行，我们不再需要我们原来的专用服务器基础设施。让我们的旧环境退役将为我们节省运营和遗留管理成本。
如何操作？
在关闭我们的旧基础架构之前，我们需要关闭新旧数据库服务器之间的复制。
结果
由于我们的两个环境之间的数据库复制不再活跃，我们的Active Ghost(Pro)设置不再与旧的基础架构有任何联系。一旦关闭了旧服务器的电源，我们的迁移就完成了！
总结
将Ghost（Pro)平台从专用服务器迁移到DigitalOcean是成功的！
我们想分享我们的经验，因为我们知道迁移服务器环境是许多项目面临的一项具有挑战性的任务。我们希望我们如何迁移到DigitalOcean的细节将对其他希望进行自己迁移的项目提供有用的资源。
塞巴斯蒂安·吉尔林格著