GitLab 是如何从 Azure 云迁移到谷歌云的?

栏目: 编程工具 · 发布时间: 5年前

内容简介:最近GitLab 决定迁移到 GCP 的原因之一是希望新平台能提升性能和一致性。GitLab 的 Chrissie Buchanan 还提到,GCP 对 Kubernetes 的支持是另一个显著因素。但将 GitLab 完全转移到 Kubernetes 上来运行的项目被推迟到迁移完成后才继续进行。GitLab 团队很早就意识到,

最近 GitLab.com 刚从 Azure 迁移到了谷歌云平台(GCP) ,GitLab 认为新平台能更好地处理关键负载,提供最低的错误率和最高的可用性。网站并没有经历漫长的下线维护时间就完成了迁移工作,而做到这一点背后的关键就是 GitLab 的镜像切换能力。

GitLab 决定迁移到 GCP 的原因之一是希望新平台能提升性能和一致性。GitLab 的 Chrissie Buchanan 还提到,GCP 对 Kubernetes 的支持是另一个显著因素。但将 GitLab 完全转移到 Kubernetes 上来运行的项目被推迟到迁移完成后才继续进行。

GitLab 团队很早就意识到, 简单地关掉 GitLab.com ,将所有数据从 Azure 复制到 GCP,更改 DNS 以指向新服务器,然后重新启动服务这条迁移路线是不可行的。实际上,光是复制大约半 PB 的数据然后验证所有数据是否正确传输就需要漫长的下线维护时间了。。

因此 GitLab 的工程师走了另一条路子:他们加入了一项新功能,将网站镜像到了多个自同步的 GitLab 实例上。平时,这些镜像可以在云服务内分发数据时提升性能和可靠性;而在这次跨云迁移的任务中,团队只要关闭基于 Azure 服务的镜像,然后启用在 GCP 服务上运行的新镜像(也就是故障切换)就可以了。

这项新功能称为 Geo,通过它可以在主服务不下线的前提下迁移 GitLab 的所有数据。所有数据传输完毕后,GitLab 的工程师就开始关闭 Azure 上的镜像,启用 GCP 上的新镜像,然后将后者设置为主镜像。这一过程非常精巧,需要漫长的的迭代、试错过程才能完美实现目标。

InfoQ 采访了 GitLab 联盟副总裁 Brandon Jung 和基础设施工程师 Andrew Newdigate,了解了更多细节。

InfoQ:你们介绍的迁移流程其实很简单直观,核心就是使用镜像解决问题,只有最后的镜像切换步骤麻烦一些。能否介绍一下你们遇到了哪些困难,又是如何解决的呢?

Andrew:举个例子。有一个小问题被我们长期忽视了:

  • GitLab 公司在几乎所有工作流程中都用到了 GitLab.com ,其中故障转移流程在 GitLab.com 上还用 markdown 做成了方案模板。
  • 因为我们是在对暂存实例进行故障转移,而我们的工作流程是在 GitLab.com 的生产实例上运行的,所以后者在前者故障转移期间都是可用的。
  • 结果迁移过程快结束的时候才有人发现,生产实例故障转移的时候是没法在 GitLab.com 上继续展开工作的。
  • 事后看来这是显而易见的问题,但不知何故我们都忽略了它,可能是因为我们太习惯使用自家产品了。
  • 解决方案很简单:我们使用 GitLab 的推送镜像功能在单独的内部 GitLab 实例上维护迁移项目的副本。对 GitLab.com 所做的任何更改都将复制到镜像中。在故障转移期间我们使用这个实例代替生产实例。

InfoQ:GitLab.com 报告说每日错误率和整体服务可用性都有了显著提升。为什么迁移到 GCP 会有这样的效果?

Brandon:GCP 的一致网络是 API 端点性能提升的最大功臣。

Andrew:Brandon 提到了网络这一因素。我还在 一篇博文 中讨论了其它 5 项因素,而且不是所有因素都是技术层面的。

InfoQ:在这些提升中 Geo 可能带来的贡献有多大?

Andrew:Geo 是一种数据复制和异地镜像解决方案,也能用作灾难恢复方案,但它本身并不能提升 GitLab.com 的可用性。

事实上故障转移完成后我们就在 GitLab.com 上禁用了 Geo。几个月前我们又启用了 Geo,用作异地备份用途。如果发生数据中心层面的重大中断事故,我们就会开始故障转移到备份镜像上,但它平时不会直接接收生产流量。

InfoQ:迁移过程并非易事。GitLab 团队从迁移到 GCP 的经历中学到了什么?

Brandon:总体来说,我们能够成功地从微软 Azure 迁移到谷歌云是我们重视开发和开源的企业文化的功劳。

Brandon:GitLab 迁移到 GCP 后用户就能更容易使用 Kubernetes 了,同时网站的性能、可用性和客户服务水平都得到了提升。

Andrew:GCP 迁移项目是 GitLab 迄今为止开展的最大工程项目之一。它需要整个组织内多个团队之间的协调——包括工程(Geo、CI、计划)团队、QA 团队、基础架构、营销、支持等。这些团队需要协调交付多个工作流。GitLab 有一个非常清晰和成熟的工程交付流程,非常适合我们的远程文化;但我们需要调整并扩展这些流程,以便按时、安全地交付全公司共同参与的项目。由于我们在为 GitLab(产品)做内部测试,因此还能向产品经理提供反馈来改进网站,以使网站能更好地支持大型多团队项目。产品管理团队反应迅速,我们的大部分反馈现已获得网站采纳了。

如果你有兴趣了解 GitLab 迁移到 GCP 过程的详细情况,可参阅我们上面链接的博客文章。

查看英文原文: How GitLab Managed to Migrate from Azure to Google Cloud Platform


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

捉虫记

捉虫记

施迎 / 清华大学出版社 / 2010-6 / 56.00元

《捉虫记:大容量Web应用性能测试与LoadRunner实战》主要讲解大容量Web性能测试的特点和方法,以及使用业内应用非常广泛的工具——Load Runner 9进行性能测试的具体技术与技巧。《捉虫记:大容量Web应用性能测试与LoadRunner实战》共17章,分为5篇。第1篇介绍软件测试的定义、方法和过程等内容:第2篇介绍Web应用、Web性能测试的分类、基本硬件知识、Web应用服务器选型、......一起来看看 《捉虫记》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码