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

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

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

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

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

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

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

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

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

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

Andrew：舉個例子。有一個小問題被我們長期忽視了：

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

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

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

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

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

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

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

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

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

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

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

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

Andrew：GCP 遷移項(xiàng)目是 GitLab 迄今為止開展的最大工程項(xiàng)目之一。它需要整個組織內(nèi)多個團(tuán)隊(duì)之間的協(xié)調(diào)——包括工程（Geo、CI、計(jì)劃）團(tuán)隊(duì)、QA 團(tuán)隊(duì)、基礎(chǔ)架構(gòu)、營銷、支持等。這些團(tuán)隊(duì)需要協(xié)調(diào)交付多個工作流。GitLab 有一個非常清晰和成熟的工程交付流程，非常適合我們的遠(yuǎn)程文化；但我們需要調(diào)整并擴(kuò)展這些流程，以便按時、安全地交付全公司共同參與的項(xiàng)目。由于我們在為 GitLab（產(chǎn)品）做內(nèi)部測試，因此還能向產(chǎn)品經(jīng)理提供反饋來改進(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)或立場。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。