微软收购 GitHub 之后，很多 GitHub 用户将代码库迁移到了 GitLab。现在，GitLab 坐不住了。6 月 25 日，GitLab 官博宣布其云托管将从微软 Azure 转向谷歌云平台 Google Cloud Platform （GCP）。官博中称，提高 GitLab.com 的性能和可靠性一直是 GitLab 的首要任务。在这方面，他们已经取得了一些成果，同时正在计划进行一项重大变化，并可能取得显着成效。
“我们相信 Kubernetes 是未来，是一项能够大规模提高可靠性的技术。”官博中这样说到。几个月前，Google 和 GitLab 宣布 GitLab 与 Google Kubernetes Engine（GKE）集成，GitLab 项目可连接托管在 GCP 平台上的 Kubernets 集群，实现运行持续集成作业，并设置持续部署流水线。选择 GCP 作为云提供商，是因为 GitLab 希望能在 Kubernetes 上运行。Kubernetes 由 Google 开源，而 GKE 拥有最强大最成熟的 Kubernetes 支持。从 Azure 迁移到 GCP 将推动 Gitab.com 更好地为用户关键工作负载服务。
开始迁移之后，GitLab 将使用 GKE 将 worker fleet 转移到 Kubernetes，继续专注于提高 GitLab.com 的稳定性和可扩展性。此举将利用 GitLab 的 Cloud Native chart (https://gitlab.com/charts/gitlab)，其中 GitLab 11.0 现在处于测试阶段。
在迁移过程中，GitLab 会使用自己的 Geo 产品。Geo 允许使用 GitLab 实例的完整只读镜像。Geo 实例除了可以浏览 GitLab 用户界面，还可用于克隆和提取项目，从而使分布在不同地理位置的团队更有效地进行协作。
Geo 可以在发生意外中断的时候实现灾难恢复，还可以在迁移 GitLab 实例过程中用于完成故障转移。
作为 GitLab 产品中所有内部测试的惯例，GitLab 使用 Geo 将 GitLab.com 从 Microsoft Azure 移到 Google 云平台。 Geo 运行良好，在 GA 发布后收获了很多用户，因为也在不断扩展。GitLab 相信 Geo 在迁移过程中会表现良好，这次的迁移也将证明 Geo 的价值。
更多有关 Geo 灾难恢复的信息参考：https://docs.gitlab.com/ee/administration/geo/disaster_recovery/
过去几个月中，GitLab 一直在维护 GitLab.com 的一个 Geo 辅助站点，名为 gprd.gitlab.com，运行在 Google 云平台上。这个辅助站点中保存着最新的约 200TB 的 Git 数据和 PostgreSQL 中 2TB 关系数据的同步副本。最初 GitLab 还复制了 Git LFS，文件上传和其他文件，但之后这些文件已经同时迁移到 Google Cloud Storage （GCS）对象存储中。GitLab 将 GCP 数据中心选择在了美国南卡罗来纳州的 us-east1 站点。他们目前的 Azure 数据中心位于弗吉尼亚州的 US East2 区。它们之间有 800km 的往返距离，或 3 光微秒，也就是说，两个站点之间需要 30ms 的 ping 时间。
由于在 Azure 和 GCP 之间需要同步大量数据，GitLab 最初担心过这种额外的延迟以及它可能对 Geo 转移带来的风险。但是，在进行初步测试后，GitLab 意识到网络延迟和带宽并不是迁移中的瓶颈。
在 Geo 转移的同时，GitLab 还将所有文件工件（包括 CI 工件，Traces（CI 日志文件），文件附件，LFS 对象和其他文件上传）迁移到 GCS，即 Google 的托管对象存储实现。这个过程把基于 Azure 文件服务器的约 200TB 数据迁移到了 GCS。
以前，GitLab.com 都将这些文件存储在 NFS 服务器上，并将 NFS 卷装载到每个网络和机群中的 API worker fleet 上。 NFS 是单点故障，难以扩展。切换到 GCS 允许 GitLab 利用其内置的冗余和多区域功能。这反过来将有助于提高他们自己的可用性并从堆栈中移除单点故障。对象存储工作是将 GitLab.com 基础架构从 NFS 转移出去的长期战略的一部分，这个战略中还包括了 Gitaly 项目——GitLab 的 Git RPC 服务。将 GitLab.com 迁离 NFS 也是将 GitLab.com 转移到 Kubernetes 的先决条件。
每周，Geo、生产和质量团队都会举行一到两次视频会议，在预发布环境中排练故障转移。
跟生产事件一样，排练从 Azure 进行到 GCP。 GitLab 对事件进行计时，仔细监控每个阶段需要花费的时间，并尽可能减少时间。故障转移目前需要两个小时，其中包括对故障转移环境的质量保证。
整个过程包含 4 个步骤：
-
预检清单：https://gitlab.com/gitlab-com/migration/blob/master/.gitlab/issue_templates/preflight_checks.md
主要故障转移程序：https://gitlab.com/gitlab-com/migration/blob/master/.gitlab/issue_templates/failover.md
测试计划：https://gitlab.com/gitlab-com/migration/blob/master/.gitlab/issue_templates/test_plan.md
故障恢复过程，用于撤消更改，以便为下一次故障转移彩排做好预发布环境的准备：https://gitlab.com/gitlab-com/migration/blob/master/.gitlab/issue_templates/failback.md
以上链接中的文档作为 issue 模板存储在 GitLab 上，GitLab 可以在每次连续的故障转移尝试中使用它们创建 issue。
每次排练都会发现新的错误和问题。GitLab Migration 追踪器被用来追踪这些问题。然后，任何对故障转移过程的更改都会作为合并请求发送到 issue 模板中。这个过程能够快速迭代故障转移过程，改进故障转移文档。
故障转移中的首要任务是确保用户数据的完整性。只有当确认所有问题都已解决，没有数据丢失风险，并且在 GCP 中的新环境已经生产就绪了，GitLab 才会进行故障转移。
故障转移计划于 2018 年 7 月 28 日（周六）进行，后续 GitLab 会提供充分的预先通知。
参考链接：
https://about.gitlab.com/2018/06/25/moving-to-gcp/
http://www.infoq.com/cn/news/2018/04/gitlab-google-kubernetes-engine
活动推荐
目前运维的方法有很多痛点，无论是异常检测，故障发现，瓶颈分析，自愈等工作都需要有大量的人工参与。随着公司越做越大，运维的场景也将会变得越来越复杂。那么仅仅依靠人工经验的运维工作将会变得捉襟见肘，所以就必然会走向基于机器学习算法的智能运维（AIOps）。来 ArchSummit 全球架构师峰会上，和我们一起关注 AIOps 的现状和未来发展。
