一、背景

本文整理自Hank Hudgins，Capital One高階工程師，在JFrog 2019使用者大會上的講演《Automated Artifactory HA Pipeline》。

Capital One是美國最大的數字化銀行之一，其IT管理方法和應用技術也極為敏捷，全球擁有上萬研發，具備非常豐富的 DevOps落地經驗。在Capital One的DevOps體系當中，有很多類似於JFrog Aritfactory的HA（高可用）應用服務叢集。眾所周知，HA叢集的運維，如升級、擴容、打補丁等工作，要想在保持使用者服務不中斷，服務水平不降級的前提下完成，尤其是在像Capital One這麼大規模的DevOps系統當中，是十分困難、複雜，和高風險的。 

Captital One使用的Artifactory為其DevOps體系中的製品及依賴管理提供了企業級解決方案，擁有工作（primary）和容災（HR）兩類HA叢集。Hank所在的Artifactory維護團隊，針對Artifactory HA叢集維護的難點，透過建設和執行自動化的流水線，在不影響使用者使用和服務水平的前提下，自動、高效、保質地完成了諸如版本升級、配置更新、補丁載入等工作，並且在檢測到問題時，還能夠實現自動化的回滾。在本次講演中，Hank就介紹了這套自動化流水線的組成與特色。

二、自動化流水線概述

Capital One採用這套可靠的自動化流水線，在Artifactory HA叢集的維護工作中獲得了良好的收益：

首先是透過自動化加速了維護程式，使得開發人員能夠集中精力進行研發，而不需要考慮重複性的部署和測試任務；其次，流水線的可複用性也為維護工作提供了便捷的可擴充套件性，透過修改相關配置，流水線就能在新的環境中進行部署；最後，流水線還提供了可以快速檢測缺陷，並實現無縫、高效回滾的部署過程。

該自動化流水線是按下述方式組成的：

首先是利用Jenkins驅動整個流水線，並整合GitHub進行觸發：

·        每個Pull Request會觸發小規模的測試以得到快速反饋。這些測試不是HA叢集範圍的，但可以得到快速驗證；

·        每個Merge會觸發研發環境HA叢集範圍的部署，並進行相關測試；

·        標籤（Tag）被用來標記程式碼更新的驗證階段和對應的環境。

其次，利用Terraform建立基礎設施，實現了“類”藍/綠的釋出。

最後，利用Chef cookbook實現針對各種應用服務的操作和配置更新。除了Artifactory，這些應用服務還包括了相關用於反向代理的Nginx、監控的Datadog，以及日誌收集的Splunk。

三、自動化流水線組成

接下來，Hank逐一介紹了這套自動化流水線各個階段的任務及實現方式。

首先是程式碼的靜態分析，針對Pull Request和Merge執行。分析的目的是對程式碼結構進行快速驗證和反饋，確保其符合業界標準。流水線整合了一系列的Linter來實現針對不同型別程式碼的靜態分析。

接下來是安全測試，這在流水線當中體現了“左移”的原則，能夠在真正部署之前儘早的檢測和發現潛在的安全漏洞。目前的安全測試分兩類，一類是靜態安全測試，即透過分析程式碼結構來發現如SQL隱碼攻擊、Cross-site指令碼等安全隱患；另一類是JFrog Xray提供的依賴測試，檢測三方依賴包中是否包含已知安全漏洞，並推薦對應的修復版本。

下一步是單元/整合測試，用於驗證程式碼的更新不會破壞預期的功能。這一步測試也可以應用於Artifactory的Custom user plugin的測試。流水線透過啟動包含Artifactory的容器，安裝並測試這些custom plugin，確保其正確工作，而不需要連線到真正的Artifactory HA叢集。

在完成了上述初步的測試之後，自動化流水線進入釋出過程。首先要把部署相關的檔案暫存到可靠的位置，這樣在叢集自動縮放的過程中不會依賴到其他系統，也包括Artifactory自身。目前，部署的相關檔案，包括二進位制包和Chef cookbook，都從Artifactory下載並快取到S3儲存上。

自動化流水線的部署階段實現了“類”藍/綠的部署過程，能夠保證新叢集的部署不會影響到Artifactory的正常服務：

1.   把使用者流量切換到容災叢集；

2.   縮容現有工作叢集，僅保留幾個節點（保持和容災叢集的資料同步），不包括primary節點（由於Artifactory HA叢集實現了多活的架構，每個節點都是支援讀/寫的，所以縮容primary節點並不會影響正常服務）。

3.   基於同樣的資料庫和S3儲存，部署新的工作叢集，包括新的primary節點。

4.   當新的工作叢集透過測試後，再把使用者流量切換回新的工作叢集。

5.   之後再對容災叢集進行升級部署。

在上述部署過程中，兩個Artifactory叢集之間始終保持著資料同步，所以從使用者的角度來看，部署是無縫切換的。

部署完成之後，要立即對叢集中的各個應用服務進行檢測。Jenkins透過SSH通道訪問新的服務，並執行測試，確保Artifactory、Nginx等應用服務執行正常，相關配置檔案的內容、位置、許可權都部署正確，以及所有的網路埠都正常開通。如果檢測失敗，將會啟動回滾過程。

接下來要執行系列的測試，確保Artifactory的各個repository都工作正常，包括能夠正確拉取Docker映象。同時，也要檢測新的系統配置是否會影響製品依賴的解析，以及對不同虛擬repository的製品上傳。

最後，還要進行效能測試，確保部署後叢集效能沒有下降。目前是利用Jmeter來模擬產品級流量，儘可能的匹配峰值流量時的API呼叫頻率。常規15分鐘的負載測試作為流水線的一部分，而可選的1小時負載測試，只有大的變更時才會執行。

效能測試的難點在於流量的建模，這是因為Artifactory的全語言特性帶來的複雜性，支援多種資料包型別，及對接相應的包管理系統。透過分析Artifactory日誌，獲得了用於測試的API呼叫序列。

最後，是自動化流水線當中的回滾機制。目前實現了兩種回滾：

·        In-region回滾。當部署後的測試失敗時，馬上啟動自動化回滾，刪除新的叢集，並恢復舊的叢集。

·        DR容錯回滾。當工作叢集升級成功後，或監測幾天使用者流量，沒有問題的時候再更新容災叢集。如果在這幾天中發現問題，就會啟動容錯回滾：先把使用者流量切換到DR叢集，然後把工作叢集回滾到之前版本，資料庫回滾到之前的快照，再透過Artifactory Replication同步資料，最後再把流量切換回回滾後的工作叢集。

資料庫的回滾是個難題。在大版本的升級過程中，可能會有DB schema的變化，這時自動化的資料庫回滾很難實現，目前暫時還是透過手工操作來完成。

四、總結

Capital One透過自動化流水線實現Artifactory HA叢集的維護工作，獲得了很好的效果和收益，加速了釋出過程，提供了良好的可複用性和擴充套件性，也能夠啟動有效的回滾機制。

透過自動化流水線的應用也可以看出，即使如Artifactory這樣成熟的商業化產品，也需要對基礎架構和配置進行全面的測試。

最後，自動化流水線本身也是需要持續的投資和提升的。