全球最大多媒體制作開(kāi)發(fā)商 Adobe 用 Argo 高級(jí)部署模式的最佳實(shí)踐
幾年前，Adobe 采取了一項(xiàng)戰(zhàn)略舉措來(lái)?yè)肀?Kubernetes，幫助工程師開(kāi)發(fā)和發(fā)布可跨云移植的應(yīng)用程序。團(tuán)隊(duì)已經(jīng)接受了 K8s，并且看到了可擴(kuò)展性和可用性的提高以及成本的降低。隨著時(shí)間的推移凸顯出副作用，我們已經(jīng)看到大量的 CI/CD 技術(shù)被使用，以及大量的本地代碼，所有這些都用于處理部署基礎(chǔ)設(shè)施。
為了減少技術(shù)蔓延并允許工程師加速其他計(jì)劃，Adobe 正朝著使用基于 Argo 項(xiàng)目的 CI/CD 通用平臺(tái)的方向發(fā)展。選擇它主要是因?yàn)椋喉?xiàng)目的模塊化、對(duì) Kubernetes 的原生支持、淺的學(xué)習(xí)曲線和易于設(shè)置。
我們的團(tuán)隊(duì)是 Spinnaker 的長(zhǎng)期用戶
#公眾號(hào)：進(jìn)擊云原生 注：Spinnaker 是一個(gè)開(kāi)源 CD 軟件平臺(tái)，可與 Kubernetes、Google Cloud Platform、AWS、Microsoft Azure 和 Oracle Cloud 配合使用。它主要是一個(gè)部署和交付平臺(tái)，用于獲取工件并將其部署到生產(chǎn)中。Spinnaker 的儀表板和界面都非常易于使用。開(kāi)發(fā)人員可以輕松地將他們的代碼推送到發(fā)布分支，該工具會(huì)自動(dòng)構(gòu)建、測(cè)試、驗(yàn)證并將代碼推送到生產(chǎn)環(huán)境。借助 Spinnaker，你可以使用 Seamless Kubernetes、 Github 和 Google 的云構(gòu)建集成，輕松交付、部署對(duì)軟件的更改。
多年來(lái)，我們依靠它為眾多項(xiàng)目構(gòu)建了持續(xù)部署管道。但在此過(guò)程中，我們也遇到了一些挑戰(zhàn)。當(dāng) Adobe 決定在 Argo 之上構(gòu)建 CI/CD 平臺(tái)時(shí)，我們抓住了改用 GitOps 和 Argo 的機(jī)會(huì)。主要原因是 GitOps 附帶的自我修復(fù)選項(xiàng)（我們過(guò)去曾受此影響）以及使用原生 K8s 對(duì)象而不是使用 Spinnaker API 和 UI 所帶來(lái)的復(fù)雜性降低。
然而，我們轉(zhuǎn)向 Argo 并非沒(méi)有挑戰(zhàn)。我們不得不將我們的思維方式轉(zhuǎn)變?yōu)橐环N新的范式：GitOps，并適應(yīng) Argo 的實(shí)現(xiàn)。例如，Argo 不提供開(kāi)箱即用的自動(dòng)升級(jí)或自動(dòng)回滾。以前，我們認(rèn)為這些功能是理所當(dāng)然的?，F(xiàn)在，我們必須使用 Argo Workflows 調(diào)整和實(shí)現(xiàn)這些功能。
提升和回滾
因此，我們構(gòu)建了一個(gè)工作流，可以自動(dòng)將提交從 Dev 提升到 Stage 以及從 Stage 到 Prod。提升的決定是基于健康檢查和測(cè)試結(jié)果的，后者是在 PostSync hook 上執(zhí)行的：
https://argo-cd.readthedocs.io/en/stable/user-guide/resource_hooks/
每個(gè)環(huán)境的部署邏輯都非常簡(jiǎn)單：
- 工作流通過(guò)提交新的應(yīng)用程序版本來(lái)促進(jìn)對(duì)環(huán)境的提交
- 然后，工作流觸發(fā) Argo 應(yīng)用程序的同步，并等待同步成功完成，以確保 Argo 應(yīng)用程序狀態(tài)是健康的
- PostSync 鉤子觸發(fā)一個(gè) Kubernetes 作業(yè)，該作業(yè)針對(duì)更新的環(huán)境執(zhí)行一套功能測(cè)試
- 如果作業(yè)成功完成，Argo 應(yīng)用程序的同步將成功返回，工作流將進(jìn)入下一個(gè)環(huán)境
在每個(gè)環(huán)境都成功更新的理想情況下，結(jié)果將是剛剛部署的應(yīng)用程序版本將已為每個(gè)環(huán)境提交。
那么如果在部署過(guò)程中出現(xiàn)問(wèn)題怎么辦？這就是自動(dòng)回滾發(fā)揮作用的地方。
假設(shè)部署管道在 Dev 中成功部署，但在 Stage 中失敗，因?yàn)闇y(cè)試失敗?；貪L就是恢復(fù)兩個(gè)提交：一個(gè)用于 Stage，一個(gè)用于 Dev。
那么這是怎么發(fā)生的呢？正如我們之前提到的，測(cè)試是在 PostSync 掛鉤上執(zhí)行的。如果測(cè)試失敗并且運(yùn)行它們的作業(yè)未成功完成，則同步階段將失敗。反過(guò)來(lái)，這將使我們的工作流程中的同步和等待任務(wù)失敗。此時(shí)，工作流也將被視為失敗。
那么回滾什么時(shí)候發(fā)生呢？我們使用了一個(gè)退出處理程序，它在工作流完成時(shí)被調(diào)用，無(wú)論成功與否。退出處理程序檢查工作流狀態(tài)；如果失敗，它會(huì)檢索工作流所做的所有提交并還原它們。
即使持續(xù)部署管道包含質(zhì)量門(mén)和功能測(cè)試
預(yù)覽環(huán)境
即使持續(xù)部署管道包含質(zhì)量門(mén)和功能測(cè)試，正在部署的更改也有可能（即使不太可能）包含難以發(fā)現(xiàn)的錯(cuò)誤。即使是最短的故障也可能對(duì)關(guān)鍵應(yīng)用程序（例如數(shù)據(jù)收集）產(chǎn)生巨大影響。那么，我們?nèi)绾芜M(jìn)一步確保將失敗的風(fēng)險(xiǎn)降到最低呢？
我們多年來(lái)一直使用的一種模式是為每個(gè)打開(kāi)的 PR 創(chuàng)建預(yù)覽環(huán)境。那么這是如何工作的呢？
這很簡(jiǎn)單，首次打開(kāi) PR 時(shí)，我們構(gòu)建代碼，然后將 PR 代碼部署到專用的按需環(huán)境中。環(huán)境是部分或完全隔離的，這取決于應(yīng)用程序的性質(zhì)。它允許我們?cè)诳紤]合并代碼之前單獨(dú)驗(yàn)證 PR。
漸進(jìn)式部署
預(yù)覽環(huán)境和部署后測(cè)試相結(jié)合，可以進(jìn)行可靠的驗(yàn)證。我們甚至可以在合并到主線之前部署代碼并自動(dòng)對(duì)其進(jìn)行測(cè)試。然而，有時(shí)會(huì)出現(xiàn)錯(cuò)誤場(chǎng)景，甚至是驗(yàn)證只能在現(xiàn)實(shí)環(huán)境中隨著時(shí)間的推移才能完成。那么我們?nèi)绾翁幚磉@些情況并進(jìn)一步降低失敗的風(fēng)險(xiǎn)呢？想到的第一件事是使用帶有 Argo Rollouts 的漸進(jìn)式部署。
這包括逐步向 prod 環(huán)境推出，推出步驟由驗(yàn)證和分析控制。例如，我們可能會(huì)路由功能測(cè)試以針對(duì)金絲雀副本運(yùn)行，并使用它們來(lái)驗(yàn)證金絲雀部署
這適用于公開(kāi) HTTP API 的應(yīng)用程序。對(duì)于流式應(yīng)用程序，我們可以進(jìn)行分析
并根據(jù)處理指標(biāo)決定是否提升金絲雀?；蛘呶覀兩踔量梢詫烧呓Y(jié)合起來(lái)。
Wave 部署
在 Adobe 中，許多服務(wù)部署在全球各地。例如 Experience Platform Edge Network 部署在七個(gè)地區(qū)。
如果出現(xiàn)應(yīng)用程序缺陷，一次在所有區(qū)域部署邊緣服務(wù)可能會(huì)產(chǎn)生重大影響。難以發(fā)現(xiàn)的問(wèn)題可能潛伏在代碼更改中；如果更改在整個(gè)應(yīng)用程序部署中同時(shí)推出，這可能會(huì)帶來(lái)災(zāi)難。
那么我們?nèi)绾螠p小爆炸半徑呢？按順序部署遠(yuǎn)非理想，因?yàn)樗鼤?huì)使部署不必要地冗長(zhǎng)。解決方案是分波部署。也就是說(shuō)，將部署拆分為多個(gè)波次，其中每個(gè)波次包含一個(gè)或多個(gè)地理區(qū)域。
這個(gè)想法是為了盡量減少爆炸半徑開(kāi)始部署在一個(gè)最初的波限制在一個(gè)或兩個(gè)地區(qū)。當(dāng)然，如何選擇這些初始區(qū)域取決于應(yīng)用程序上下文; 一種方法是根據(jù)客戶/用戶的數(shù)量進(jìn)行部署，并讓構(gòu)建有足夠的時(shí)間來(lái)建立信心。例如，首先在用戶數(shù)量最少的區(qū)域進(jìn)行部署，以便在部署中出現(xiàn)缺陷時(shí)影響最小。
如果第一波成功，您可以繼續(xù)在其他地區(qū)進(jìn)行第二波部署，依此類推。通過(guò)分波部署，您可以將功能測(cè)試和金絲雀分析未發(fā)現(xiàn)的錯(cuò)誤的影響限制在最少的用戶身上。如果發(fā)生故障，您可以回滾已部署的整個(gè)區(qū)域集。
你可以更進(jìn)一步: 第一波可能包括一個(gè)dark launch。我們?cè)?Adobe 中做到這一點(diǎn)的方法是，我們使用一個(gè)不接收任何實(shí)際流量的 prod 配置將代碼部署到一個(gè)專用的 pre-prod 環(huán)境中。環(huán)境接收由功能測(cè)試生成的合成流量，并用于在類似生產(chǎn)的設(shè)置中驗(yàn)證代碼。
從持續(xù)部署退一步
我們是持續(xù)部署的大力支持者。事實(shí)上，我們多年來(lái)一直在成功地使用持續(xù)部署。它幫助我們更有信心地部署質(zhì)量代碼。它還幫助我們晚上睡得很好，因?yàn)檫@些年來(lái)我們發(fā)生的事件較少。
然而，我們意識(shí)到持續(xù)部署并不適合所有用例。當(dāng)持續(xù)部署對(duì)團(tuán)隊(duì)不起作用時(shí)，存在現(xiàn)實(shí)世界的場(chǎng)景。
- 可能是部署需要很長(zhǎng)時(shí)間
- 可能需要緩慢地將金絲雀部署到生產(chǎn)環(huán)境以捕獲關(guān)鍵業(yè)務(wù)指標(biāo)
- 或者部署工作流需要執(zhí)行許多任務(wù)
如果部署需要很長(zhǎng)時(shí)間（例如 30 分鐘或更長(zhǎng)時(shí)間），則部署將排隊(duì)。您不能期望開(kāi)發(fā)人員等待數(shù)小時(shí)才能部署他們的更改。
可能是您有一個(gè)大型團(tuán)隊(duì)在處理單個(gè) repo，并且向主線提交的頻率很高?；蛘?，業(yè)務(wù)環(huán)境可能要求部署遵循一定的節(jié)奏。比如說(shuō)，每天甚至每周。
我們?nèi)绾翁幚磉@種情況？在這些場(chǎng)景中，使用持續(xù)交付是更好的選擇。它需要與持續(xù)部署模型一樣的勤奮和對(duì)質(zhì)量的重視，因?yàn)樗髽?gòu)建可在任何時(shí)間點(diǎn)發(fā)布的工件，就像持續(xù)部署模型一樣。不同之處在于您不會(huì)將所有更改都部署到生產(chǎn)環(huán)境中。部署到 prod 成為一個(gè)單獨(dú)的操作，可以在以后采取，具體取決于團(tuán)隊(duì)的部署策略。我們探索的一種模式：
- 將提交作為常規(guī)升級(jí)工作流程的一部分部署到預(yù)生產(chǎn)環(huán)境；
- 按計(jì)劃部署到 prod
out-of-band，在主分支中部署最新的提交。
總結(jié)
通過(guò)采用這些實(shí)踐，您可以構(gòu)建穩(wěn)定可靠的部署管道，從而使部署到生產(chǎn)環(huán)境沒(méi)有什么特別之處。雖然從 Spinnaker 遷移到 Argo 并非沒(méi)有挑戰(zhàn)，但我們已經(jīng)設(shè)法在 Argo 之上構(gòu)建了同樣強(qiáng)大的工作流程并進(jìn)一步發(fā)展和優(yōu)化。
譯自：https://containerjournal.com/features/advanced-deployment-patterns-with-argo/
本文由mdnice多平臺(tái)發(fā)布
