如何使用Ghost迁移从专用服务器到DigitalOcean
2015-12-08
分类：系统运维
阅读()
评论()
介绍
这DigitalOcean蓝图文章由塞巴斯蒂安Gierlinger，在Ghost的高级的DevOps工程师。它涵盖了被送往迁移从专用服务器到DigitalOceanDropletGhost（专业版）的基础设施的步骤。在每个步骤中，塞巴斯蒂安将讨论面临的挑战，每一个挑战是如何解决，为什么选择各溶液。他也将提供链接到他发现是有帮助的。相关的资源
埃德。 Ghost（专业版）是Ghost托管平台，一个开源博客平台，用户可以在这里租预建Ghost的博客点击几下。Ghost（专业版）是持续的资金非营利性组织，Ghost基金会，用于管理Ghost开源项目。最初在专用服务器托管，Ghost（专业版）迁移到DigitalOcean以实现按需扩展。
问题陈述
在2014年最后一个季度，Ghost（专业版）很快outgrowing其原始的，专用的服务器基础架构，因为它每月为来自博客成千上万的约100万个请求。扩展现有的基础设施将需要约两个月的准备时间购买和部署新的物理服务器。总之，缩放专用服务器的基础设施的限制被危及Ghost（Pro）的平台的增长，其结果，Ghost开源项目的进一步发展。 我们需要解决我们不能迅速形成规模，才可能对客户还是我们的增长造成负面影响，通过迁移到改善基础设施。
要求
从我们一年多的运行Ghost（专业版）的经验，我们有被需要什么来改善我们的服务是个好主意。我们确定，我们的下一个基础设施应该满足以下要求：
- 能够扩大在几分钟之内的服务器容量
- 足够的内存来满足成千上万的博客
- 提供强大的客户支持
- 让我们没有显著重构迁移我们的软件
DigitalOcean满足了所有这些要求。 在迁移的规划中，我们确定，我们需要进行零宕机迁移。我们将进入技术性原因这一点。
迁移大纲
规划任何项目的迁移开始时的不确定性一定程度; 这是根本不可能预测到所有必需的步骤，更何况，你会遇到的任何问题。我们的迁移计划是通过研究和实施一个反复的过程形成的。 因为这是一个回顾性的文章中，我们能够在迁移过程组织成更容易理解这些广泛的步骤：
- 创建现有的服务器基础设施的库存
- 安全的公共网络
- 安全的专用网络
- 复制数据库
- 更新DNS（割接专门向目标服务器）
- 淘汰旧环境
今天，作为迁移的结果，Ghost（临）服务器拓扑结构如下：
![Ghost基础设施]()
- CloudFlare的提供内容分发网络（CDN），域名服务（DNS），从恶意请求缓存和保护
- 核心服务器主机ghost.org并负责用户和支付管理
- 高速缓存服务器被用来进一步加快响应和请求定向到正确的博客
- 应用服务器池包含其中运行客户的Ghost博客很多应用服务器的
- DB集群是握住你的博客数据MySQL数据库集群
- GitHub的处理我们的源代码管理
- Ruxit负责监控Ghost（专业版）的基础设施
- 亚马逊S3是用来存储加密，异地备份
让我们来看看这让我们对我们的新的，可扩展的服务器基础设施的步骤。
第1步：创建库存
第一步是创建什么目前我们现有的专用服务器基础架构使用配置管理工具运行的库存。
为什么？
在规划任何服务的迁移，它有办法可靠地再现现有的环境是很重要的。这将有助于确保迁移将顺利进行。当然，这要求每个服务器和软件组件被占。 当Ghost（专业）成立之初，快捷方式被带到得到它快速启动和运行。我们配置了我们原来的服务器手动因此，虽然现有的平台工作正常，我们没有每一个小细节的配置文件。
怎么样？
为了解决没有我们安装的软件包，防火墙设置的完整清单，和其他服务器配置的问题，我们推出了配置管理系统给我们的工具包。之一的好处
配置管理是，一旦系统建立时，它兼作文档和部署工具。 当是时候选择一个配置管理系统中，我们考虑了几种流行的配置管理工具，包括Puppet，Chef，Ansible和SaltStack。我们需要一个能够把工作做好，并没有用复杂超载的工具。最终，我们选择了
SaltStack。 下面是一些我们决定SaltStack的原因：
- 它的重量轻，而且易于安装和维护
- 它采用主/仆从管理基础架构，其中的Salt大师“推”更改喽罗。这意味着减少法师风险由数百名喽罗试图联系其被DDOSed，相比那里的喽罗拉离主变化的体系结构
- 它有一个专门的主服务器。这可以防止管理员和开发人员部署的变化直接从未受保护的开发机
- 它使用ZeroMQ，而不是SSH，对于法师和喽罗之间的通信。ZeroMQ使用更少的处理器的功耗和更有效比SSH，当涉及到处理的并发连接，同时还提供加密
作为额外的奖励，Salt-Cloud，它是包含在SaltStack，用紧密结合 - DigitalOcean API通过生成新的Droplet扩展我们的服务，使我们能够管理我们在命令行的基础设施。它被证明是为启动，停止和部署服务器，可靠，几分钟内一个非常重要的工具。
结果
虽然初始设置和新的Ghost部署（专业版）的基础设施花了一些时间约三个星期，SaltStack已经显示出其威力。第二迭代了约一周来部署。第三个安装我们的托管平台，这将成为我们今天的生产系统中，只用了两天时间。 创建库存和移动到配置管理工具是一个反复的过程，几乎跨越了我们平台的整个迁移。除了使迁移可能，这也浮出水面我们的设置需要改进的地方。
资源
如果您正在寻找上手SaltStack，请在DigitalOcean SaltStack系列的第一教程：
简介SaltStack术语和概念。从那里，你会发现其他的教程，这将帮助你在你自己的基础设施使用SaltStack。 如果您有兴趣了解一些其他流行的配置管理工具，这里有一些教程，可以帮助您开始：
第2步：安全的公共网络
第二步是确保我们的平台的内部服务器的公网的防火墙。
为什么？
在我们的旧环境，只有我们面向公众的服务器是在互联网上。我们所有的其他服务器，如应用程序和数据库服务器，是通过一个内部专用网络才能访问。随着向DigitalOcean的云，哪里来访问每个服务器甚至是那些并不需要公开有一个公网IP地址，我们需要解决这个新的安全问题。
怎么样？
我们通过建立一个保护我们的内部服务器的公网
iptables防火墙，阻止一切除了SSH流量。由于我们的服务器正在运行Ubuntu，我们使用UFW作为接口的iptables。 作为与基础结构的其余部分，我们的防火墙配置的中心与SaltStack管理。这使我们能够轻松地管理我们所有的服务器的防火墙，甚至需要特殊防火墙规则的。
结果
所有非公开的服务器，其中包括应用程序和数据库服务器（见拓扑图），有他们的访问挡着给公众。除了专用网络，我们将在稍后讨论，我们所有的内部服务器都只能通过与基于证书的验证SSH访问。
资源
如果您想了解防火墙的基本知识，以开始
什么是防火墙和它是如何工作的？教程。它解释了防火墙的基本知识，并链接到其他的教程，这将有助于你建立一个防火墙使用iptables来保护您的公共网络接口，UFW，或FirewallD（CentOS的）。
第3步：安全的专用网络
第三步是确保我们所有的服务器的专用网络与VPN。
为什么？
DigitalOcean的专用网络功能允许在同一数据中心内的Droplet而不发送出去的流量数据中心的相互沟通。虽然这个功能是伟大的，因为它使得高带宽和我们的基础设施内的低延迟连接，专用网络在所有Droplet在数据中心共享，包括那些属于其他DigitalOcean客户。也就是说，我们的专用网络保护通用互联网连接，但不一定是从Droplet不属于我们的专用网络上。
怎么样？
我们选择了通过建立一个VPN（虚拟专用网络），以确保我们所有的服务器的专用网络。通过VPN提供的加密和身份验证功能，非常适合我们的需要。 我们选择TINC为主要是因为它采用的是网状路由布局我们的VPN解决方案，这意味着可能当VPN流量直接发送到目的主机。它也使我们能够通过连接Droplet路由流量达到不直接连接到请求者Droplet。OpenVPN的不同，这可能是因为它的路线通过中央VPN服务器的每个连接，我们的VPN的行为很像传统的专用网络VPN管理复杂化。 它也使我们能够扩展我们的VPN来Droplet在远程数据中心，如果我们决定，我们需要跨越多个数据中心。 像我们的防火墙配置中，我们使用SaltStack集中管理我们的VPN配置。这使我们能够在所有我们的服务器，从而确保我们的VPN成员始终是准确的和最新的自动更新TINC VPN配置。
结果
我们的基础设施内的所有的网络流量是安全的，因为它通过VPN TINC私人网络接口。每Droplet运行TINC守护进程，它负责连接（和重新连接）到Droplet的一个给定的列表。作为使用网状VPN的结果，服务器之间的VPN连接的结构非常简单。
资源
如果您正在寻找上手TINC作为VPN解决方案，检查了
如何安装和TINC建立一个基本的VPN在Ubuntu 14.04的教程。
第4步：激活数据库复制
第四步是通过设置复制到我们的数据库迁移。
为什么？
本来，我们计划在数据库迁移期间服用Ghost（专业版）下线。这将使我们能够停顿，停顿，以确保数据的一致性和创建MySQL数据库的备份。然后，我们可以在备份转移到新的数据库服务器，并恢复他们完成数据库迁移。然而，在分析现有数据后，我们很快就意识到，这个过程不会是可行的。我们有大约500 GB的数据库，这意味着迁移将需要大约600小时的停机时间，不包括任何非预期的错误。以我们的服务为脱机状态，长期是完全不能接受的。我们需要另一解决方案。 我们决定转向复制迁移我们的MySQL数据库。数据库复制，其保持在多个服务器的数据库的相同拷贝，提供了一种迁移数据库不中断它。这消除了我们服务的任何停机的需求，并给了我们能够交换我们的旧数据库服务器关闭之前测试我们的新的数据库服务器的安全网。
怎么样？
以复制的优势，需要迁移数据库，我们一些额外的规划。虽然我们不能包括所有的细节，为简洁起见，这里是我们所经历的显着的步骤顺序。
1.配置主/从复制 我们配置了原来的数据库服务器作为主，而新的数据库服务器是Minion。这意味着，数据在一个方向上被复制，从原始数据库系统的数据库系统中的新的基础设施。
2.测试新的基础设施 使用这种主/从配置中，我们能够做负载测试，看看我们的新Ghost（专业版）系统的等效行为给我们的旧体制。需要注意的是，由于设置的性质，在我们的测试到从数据库所做的修改没有影响原来的（主）数据库。 经过我们的测试是成功的，我们在新的（从）数据库服务器消灭了数据，为下一步作准备。
3.配置主/主复制 随着测试了新的数据库服务器，我们激活主/主复制这意味着所有的数据库变化在两个方向上被复制。
结果
一旦主/主复制被激活，而原有数据库迁移到我们的新的服务器，新的基础设施已经准备好使用。我们有Ghost（专业版）的基础设施两个完全功能的情况下，新与旧，与数据库同步。然而，新的基础设施还没有激活，因为
ghost.org和
ghost.ioDNS记录，怎么我们的用户访问我们的服务，是在老的基础设施仍指向。 这意味着我们的服务的迁移现在减少到切换DNS条目指向新的服务器。由于使用主/主数据库复制的一个额外的好处，我们的设置会很快让我们轻松地返回到我们的老基础设施，如果我们遇到任何问题。
资源
要了解自己的环境中设置数据库复制，检查出这些教程：
第5步：更新DNS记录
第五步是通过更新我们的DNS记录把我们的新的基础设施投入生产。
为什么？
为了把我们的新的基础设施投入生产，所有我们需要做的是更新我们对我们的公开面对高速缓存和核心服务器，DNS记录
ghost.io和
ghost.org分别。
怎么样？
更新DNS记录是因为它需要进行DNS更改传播时间有时也会出现问题。如果处理不适当，传播可能需要时间和用户可能会被发送到旧的和新的系统。我们使用
的CloudFlare来管理我们的DNS条目，这使我们能够在实时DNS更改，所以我们能够避免这些问题。 当我们准备开始使用我们的系统，我们进行了以下顺序。首先，我们更新
ghost.org为指向新的核心服务器，然后进行测试，它的工作。接下来，我们更新
ghost.io为指向新的缓存服务器然后跑更多的测试。
结果
更新我们的DNS记录指向新的缓存和核心服务器后，我们的新的基础设施是活的; 我们所有的用户都从我们DigitalOcean，同一组服务器是目前在生产新的基础设施访问我们的Ghost（专业版）的服务。 我们仍然需要恢复我们的DNS的变化，如果我们遇到的任何问题，切换回原来的基础设施的能力。这将只需要几秒钟，因为在生产数据库仍然可以在两个基础设施，因为主/主复制仍然活跃，并与CloudFlare的DNS传播几乎瞬间发生。幸运的是，这是没有必要的，因为迁移到新的服务器经历了顺利。
资源
正如我们所讨论的，我们使用的CloudFlare来控制我们的服务的域名记录。除了他们的DNS服务，我们还支付他们的应用程序防火墙，CDN和DDOS防护。他们还提供基本的服务，用较少的特点，是免费的。要使用CloudFlare的管理您的域名，按照配置域使用的CloudFlare的部分
本教程。 另外，DigitalOcean还提供了域名服务器，你可以指向你自己的域名。然而，DigitalOcean DNS可能不适合快速DNS传播理想解决方案迁移项目，因为TTL（生存时间）值是不可配置。看看如何设置了按照本教程：
如何指向DigitalOcean域名服务器。 如果你正在寻找有关DNS的概念，在底漆
DNS简介术语，组件和概念教程是赶上了一个伟大的方式。
第6步：退役旧环境
最后一步是退役在我们的旧环境中的服务器。
为什么？
我们的服务对我们的新DigitalOcean设置完全运行，我们不再需要我们原来的专用服务器基础设施。淘汰我们的旧环境，会节省我们的业务和传统的管理成本。
怎么样？
关闭我们的老基础设施的电源之前，我们需要我们的新老服务器和数据库服务器之间切换关闭复制。
结果
随着数据库复制不再有效了两个环境之间，我们活跃Ghost（专业）设置不再有旧基础设施的联系。一旦断电，我们的老服务器，我们的迁移完成！
结论
从专用服务器迁移DigitalOceanGhost（专业版）平台是成功的！ 我们希望分享我们的经验，因为我们知道，迁移服务器环境是一项艰巨的任务，许多项目面对的问题。我们希望，我们如何迁移到DigitalOcean的细节将是一个有用的资源，其他项目正在寻求做自己的迁移。
觉得文章有用就打赏一下文章作者
支付宝扫一扫打赏
微信扫一扫打赏
