容器環境應用一鍵拉起實踐

應用的開發和整合測試環境：透過版本化的環境定義，自動建立環境和應用以及相關資料服務和Mock服務，從而實現元件自動化測試中的全自動化部署。

軟體專案的生命週期自動化的一部分：將實際測試環境管理建立工作從開發和測試團隊工作中分離出來。開發測試只需要定義軟體相關依賴和配置，各種環境完全根據配置創建出來，並且在專案結束後自動回收。作為整體專案週期，實現從專案建立開始，關聯程式碼repo和分支，程式碼質量，部署配置，自動化測試，軟體部署環境以及專案結束週期。

基於Noah雲的整體CI/CD流程關鍵支撐：透過將版本化的環境定義作為單一資料源，實現研發測試流程中環境的建立測試驗證過程中配置資料的管理標準化，進而打通測試完成釋出上線步驟的配置變更自動識別生成對比，實現和推動全CI/CD流程自動化。

測試開發分離，需要更多的溝通和協調；

可用環境有限，提測需要排隊，多個不同功能分支無法併發執行測試；

反饋週期長，開發階段不能發現的問題需要等到提測合併到釋出分支後才能得到反饋。

類似單元測試，但是依賴資料庫/快取和簡單mock服務執行：共享外部資料庫資源，沒有隔離，容易發生衝突，需要協調；

AutoV整合測試，需要本地啟動資料庫/快取以及依賴的服務或mock來執行：本地資源佔用大，執行和除錯比較費時，速度和體驗不佳。

測試環境應該儘量只包含待測應用和相關基礎服務依賴，如資料庫、快取等，其餘需要依賴的服務儘量以mock形式配置，減少不確定性和環境複雜性；

測試環境可以隨時可重覆的建立和銷毀，保證環境和測試的可重覆性以及有效利用資源，更多的執行測試；

應用的行為可以透過引數化的方式來配置或者實時控制（例如透過配置中心下發配置改變應用行為）。

應用啟動需要的環境變數配置；

應用在配置中心的各種變數配置；

應用需要建立的訊息佇列；

應用需要消費的訊息佇列；

應用對於資料資源服務的要求：MC，Redis，MySQL以及透過資料中介軟體接入的配置；

應用對資料庫Schema/初始資料的配置。

環境基礎服務的依賴；

環境資源服務：是否有公用資源服務，還是需要單獨拉起資源使用，資源如何分配給每個應用；

環境需要部署的應用，版本，系統資源分配；

環境依賴資訊：額外的域名解析配置，對其他環境服務的依賴，Mock服務依賴。

環境基礎服務依賴：預先配置好可用的基礎服務集合，部署只需要宣告需要哪一組服務；

系統資源分配：按應用型別預設值或者使用應用最低要求；

資源服務的拉起：按應用描述要求收集彙總，拉起共享服務供應用使用；

環境依賴：需單獨宣告，和環境相關。

透過流水線生成收集版本化的應用描述模板，生成應用目錄；

基於應用目錄，結合軟體專案，定義每個專案的環境部署需求，生成環境部署描述；

基於應用描述和環境描述自動構建獨立部署環境和應用配置：

• 自動關聯環境依賴的各項基礎服務；

• 自動建立所需資料服務資源，並且與特定應用自動系結；

• 自動部署應用整合版本到環境，自動處理環境更新；

• 自動處理應用對環境的各項依賴。

Kubernetes Events：資料基礎服務容器和應用容器的啟動監控

服務呼叫完成事件：各基礎服務初始化，資料初始化等事件

流程管理事件：比如取消流程執行等處理

SQL指令碼；

從集中的資料Schema治理系統獲取資料Schema；

基於Flyway的資料自動初始化和資料遷移管理工具。

多個應用域（7~20個），需要在同一個環境部署實現端到端的驗證；

資源服務配置複雜，目前維護了眾多的虛擬機器：

• 訊息佇列服務眾多，往常需要逐條Channel/Queue進行配置；

• MySQL，多達128個分庫。初始資料多達18000行SQL；

• Redis：單實體/Sharding/Cluster配置並存；

資料庫中介軟體：不同應用多項服務註冊使用，並且有不同應用共用同一服務的情況。

環境變數配置工作繁重：包括多個MySQL分庫，Redis實體的配置資訊；

經常需要切換各個應用配置適應不同測試場景。