GitLab 是如何從 Azure 云遷移到谷歌云的,gitlab云環(huán)境

GitLab 是如何從 Azure 云遷移到谷歌云的

最近 GitLab.com 剛從 Azure 遷移到了谷歌云平臺(tái)（GCP），GitLab 認(rèn)為新平臺(tái)能更好地處理關(guān)鍵負(fù)載，提供最低的錯(cuò)誤率和最高的可用性。網(wǎng)站并沒(méi)有經(jīng)歷漫長(zhǎng)的下線(xiàn)維護(hù)時(shí)間就完成了遷移工作，而做到這一點(diǎn)背后的關(guān)鍵就是 GitLab 的鏡像切換能力。

GitLab 決定遷移到 GCP 的原因之一是希望新平臺(tái)能提升性能和一致性。GitLab 的 Chrissie Buchanan 還提到，GCP 對(duì) Kubernetes 的支持是另一個(gè)顯著因素。但將 GitLab 完全轉(zhuǎn)移到 Kubernetes 上來(lái)運(yùn)行的項(xiàng)目被推遲到遷移完成后才繼續(xù)進(jìn)行。

GitLab 團(tuán)隊(duì)很早就意識(shí)到，簡(jiǎn)單地關(guān)掉 GitLab.com，將所有數(shù)據(jù)從 Azure 復(fù)制到 GCP，更改 DNS 以指向新服務(wù)器，然后重新啟動(dòng)服務(wù)這條遷移路線(xiàn)是不可行的。實(shí)際上，光是復(fù)制大約半 PB 的數(shù)據(jù)然后驗(yàn)證所有數(shù)據(jù)是否正確傳輸就需要漫長(zhǎng)的下線(xiàn)維護(hù)時(shí)間了。。

因此 GitLab 的工程師走了另一條路子：他們加入了一項(xiàng)新功能，將網(wǎng)站鏡像到了多個(gè)自同步的 GitLab 實(shí)例上。平時(shí)，這些鏡像可以在云服務(wù)內(nèi)分發(fā)數(shù)據(jù)時(shí)提升性能和可靠性；而在這次跨云遷移的任務(wù)中，團(tuán)隊(duì)只要關(guān)閉基于 Azure 服務(wù)的鏡像，然后啟用在 GCP 服務(wù)上運(yùn)行的新鏡像（也就是故障切換）就可以了。

這項(xiàng)新功能稱(chēng)為 Geo，通過(guò)它可以在主服務(wù)不下線(xiàn)的前提下遷移 GitLab 的所有數(shù)據(jù)。所有數(shù)據(jù)傳輸完畢后，GitLab 的工程師就開(kāi)始關(guān)閉 Azure 上的鏡像，啟用 GCP 上的新鏡像，然后將后者設(shè)置為主鏡像。這一過(guò)程非常精巧，需要漫長(zhǎng)的的迭代、試錯(cuò)過(guò)程才能完美實(shí)現(xiàn)目標(biāo)。

InfoQ 采訪了 GitLab 聯(lián)盟副總裁 Brandon Jung 和基礎(chǔ)設(shè)施工程師 Andrew Newdigate，了解了更多細(xì)節(jié)。

InfoQ：你們介紹的遷移流程其實(shí)很簡(jiǎn)單直觀，核心就是使用鏡像解決問(wèn)題，只有最后的鏡像切換步驟麻煩一些。能否介紹一下你們遇到了哪些困難，又是如何解決的呢？

Andrew：舉個(gè)例子。有一個(gè)小問(wèn)題被我們長(zhǎng)期忽視了：

GitLab 公司在幾乎所有工作流程中都用到了 GitLab.com，其中故障轉(zhuǎn)移流程在 GitLab.com 上還用 markdown 做成了方案模板。

因?yàn)槲覀兪窃趯?duì)暫存實(shí)例進(jìn)行故障轉(zhuǎn)移，而我們的工作流程是在 GitLab.com 的生產(chǎn)實(shí)例上運(yùn)行的，所以后者在前者故障轉(zhuǎn)移期間都是可用的。結(jié)果遷移過(guò)程快結(jié)束的時(shí)候才有人發(fā)現(xiàn)，生產(chǎn)實(shí)例故障轉(zhuǎn)移的時(shí)候是沒(méi)法在 GitLab.com 上繼續(xù)展開(kāi)工作的。事后看來(lái)這是顯而易見(jiàn)的問(wèn)題，但不知何故我們都忽略了它，可能是因?yàn)槲覀兲?xí)慣使用自家產(chǎn)品了。

解決方案很簡(jiǎn)單：我們使用 GitLab 的推快遞鏡像功能在單獨(dú)的內(nèi)部 GitLab 實(shí)例上維護(hù)遷移項(xiàng)目的副本。對(duì) GitLab.com 所做的任何更改都將復(fù)制到鏡像中。在故障轉(zhuǎn)移期間我們使用這個(gè)實(shí)例代替生產(chǎn)實(shí)例。

InfoQ：GitLab.com 報(bào)告說(shuō)每日錯(cuò)誤率和整體服務(wù)可用性都有了顯著提升。為什么遷移到 GCP 會(huì)有這樣的效果？

Brandon：GCP 的一致網(wǎng)絡(luò)是 API 端點(diǎn)性能提升的最大功臣。

Andrew：Brandon 提到了網(wǎng)絡(luò)這一因素。我還在一篇博文中討論了其它 5 項(xiàng)因素，而且不是所有因素都是技術(shù)層面的。

InfoQ：在這些提升中 Geo 可能帶來(lái)的貢獻(xiàn)有多大？

Andrew：Geo 是一種數(shù)據(jù)復(fù)制和異地鏡像解決方案，也能用作災(zāi)難恢復(fù)方案，但它本身并不能提升 GitLab.com 的可用性。

事實(shí)上故障轉(zhuǎn)移完成后我們就在 GitLab.com 上禁用了 Geo。幾個(gè)月前我們又啟用了 Geo，用作異地備份用途。如果發(fā)生數(shù)據(jù)中心層面的重大中斷事故，我們就會(huì)開(kāi)始故障轉(zhuǎn)移到備份鏡像上，但它平時(shí)不會(huì)直接接收生產(chǎn)流量。

InfoQ：遷移過(guò)程并非易事。GitLab 團(tuán)隊(duì)從遷移到 GCP 的經(jīng)歷中學(xué)到了什么？

Brandon：總體來(lái)說(shuō)，我們能夠成功地從微軟 Azure 遷移到谷歌云是我們重視開(kāi)發(fā)和開(kāi)源的企業(yè)文化的功勞。

Brandon：GitLab 遷移到 GCP 后用戶(hù)就能更容易使用 Kubernetes 了，同時(shí)網(wǎng)站的性能、可用性和客戶(hù)服務(wù)水平都得到了提升。

Andrew：GCP 遷移項(xiàng)目是 GitLab 迄今為止開(kāi)展的最大工程項(xiàng)目之一。它需要整個(gè)組織內(nèi)多個(gè)團(tuán)隊(duì)之間的協(xié)調(diào)——包括工程（Geo、CI、計(jì)劃）團(tuán)隊(duì)、QA 團(tuán)隊(duì)、基礎(chǔ)架構(gòu)、營(yíng)銷(xiāo)、支持等。這些團(tuán)隊(duì)需要協(xié)調(diào)交付多個(gè)工作流。GitLab 有一個(gè)非常清晰和成熟的工程交付流程，非常適合我們的遠(yuǎn)程文化；但我們需要調(diào)整并擴(kuò)展這些流程，以便按時(shí)、安全地交付全公司共同參與的項(xiàng)目。由于我們?cè)跒?GitLab（產(chǎn)品）做內(nèi)部測(cè)試，因此還能向產(chǎn)品經(jīng)理提供反饋來(lái)改進(jìn)網(wǎng)站，以使網(wǎng)站能更好地支持大型多團(tuán)隊(duì)項(xiàng)目。產(chǎn)品管理團(tuán)隊(duì)反應(yīng)迅速，我們的大部分反饋現(xiàn)已獲得網(wǎng)站采納了。

特別聲明：以上文章內(nèi)容僅代表作者本人觀點(diǎn)，不代表ESG跨境電商觀點(diǎn)或立場(chǎng)。如有關(guān)于作品內(nèi)容、版權(quán)或其它問(wèn)題請(qǐng)于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。