SaaS服务的私有化部署,这样做最高效|云效工程师指北
簡介:為了能夠有效且高效地同時管理SaaS版本和私有化版本的發布過程,云效團隊也結合云原生的基礎設施和標準化工具(比如helm)進行了一系列的探索和實踐,并將其中一些通能的能力進行了產品化。本文從問題本身出發,講解解決問題的思路,及如何通過“DIY”的方式來實現這套思路。
大家好,我是崔力強,我在云效負責Flow流水線的開發工作。近年來,SaaS化部署形態的產品的私有化部署需求越來越多,比如云效自身就有私有化部署的版本。為了能夠有效且高效地同時管理SaaS版本和私有化版本的發布過程,云效團隊也結合云原生的基礎設施和標準化工具(比如helm)進行了一系列的探索和實踐,并將其中一些通能的能力進行了產品化。本文會從問題本身出發,講解解決問題的思路,及如何通過“DIY”的方式來實現這套思路。最終講解云效AppStack產品是如何對這些實踐進行產品化,并使其更容易規模化。
SaaS服務在版本化上的先天不足
軟件交付有兩種基本場景:面向大版本的交付和面向SaaS的升級更新。
通常來講,提供本地或私有化部署的軟件都屬于第一種。比如Jenkins剛剛發布了2.319.2版本,那么這個版本里包含了什么樣的特性就是明確的。你拿著這個安裝包在任何一臺機器上都可以從頭安裝得到這些功能。
而互聯網產品很大一部分是SaaS化的,即只有一套部署,供所有用戶使用。軟件的維護者更關心的并不是我的產品是否可以在任何一個數據中心從頭搭建出來,而是如何在現有的這個運行中的系統上通過更新某個組件或者服務來快速的交付一個特性。
圖1:SaaS服務交付和大版本交付的交付節奏
從上述的示意圖,可以形象地看到兩種交互方式的差異。
面向大版本的交付會明確該版本中包含的特性以及交付時間, 版本的發布時間間隔通常比較長,需要對版本的全新安裝以及不同版本之間的升級安裝進行詳盡的測試。
面向SaaS的升級更新,交付的頻率比較高,可以快速響應市場上的需求,但相應的規劃性比較差。同時因為“可重復安裝能力”的優先級要低于“快速利用已有的服務和能力交付新特性”,因此在架構上可能會逐步產生復雜的依賴,從而進一步地使得全新部署這套服務變的越來越困難。
然而現實并不是非黑即白的。有可能一套互聯網產品在發展了若干年之后有了進軍海外的需求,就需要同時部署海外站, 或者需要做私有化部署。此時該怎么辦呢?是犧牲效率全部改成版本化的交付,還是以SaaS服務的交付節奏為主?如果是后者,那么每個私有化大版本發布前的幾天,團隊需要從紛亂的SaaS部署中厘清需要將哪些服務的什么版本(比如鏡像版本)納入到這個大版本中,進行版本驗證,以及潛在的可能要對代碼和配置進行調整。
圖2:同時兼顧SaaS服務和大版本交付兩種交付方式
假設一個月出一個大版本,那么在上圖的2月1號到2月7號這七天里都可能發生了什么呢?
其中:
1和2屬于版本規劃和測試左移的問題。本文暫時不聊。
3和4就是可以通過技術來解決的問題了,本文接下來的部分會重點討論如何高效的解決這兩類問題。
統一版本格式
解決上述問題的核心技術就是要有一個統一的版本格式,無論是SaaS版本還是大版本都應該使用相同的版本格式。
在此基礎之上,要做到
1、版本應該是一個完整的系統描述,包含了所有的鏡像,配置等一切啟動服務所需要的描述。從而能夠實現基于某個版本,就可以一鍵拉起一個新的可用的環境。
2、每個環境有一個基線的概念,也就是和環境的當前運行態保持一致的那個版本。
圖3:版本中包含的內容
3、在環境中,每個服務還是可以獨立更新的。每一次某個服務在某個環境上(比如服務A的生產環境)的發布,盡管只修改了系統中的一個服務,但也應該自動生成整個環境的一個新的版本。
4、每個環境的配置應該集中化起來,而不是在各個服務中分別維護。在服務數量比較多的情況下,這種方式可以大大地降低版本維護的成本。尤其是在新建環境的場景下,由于配置集中化了,需要修改什么就更加的一目了然。通常在配置項集中化之后,還會看到另一個好處,那就是重復配置少了,因為一個系統中的不同服務多多少少都會共用一些配置,如果要單獨在服務中維護,就不可避免的出現重復。
圖4:任何制品和配置的變更都引起大版本的更新
5、對環境的任何變更都應該最終反映在版本中。只有這樣才能保證你做的變更,可以原樣的在另一個環境,另外一家客戶的機房中被正確的執行,比如DDL和DML。
6、所有的日常發布行為,本質上就是針對版本變更這個動作的一些場景化封裝。比如對某一個服務做變更,那就可以創建一個獨立的CD流水線進行鏡像構建,創建臨時版本,更新環境,將臨時版本寫入基線。而進行某個配置變更,就是修改基線,然后應用基線到環境。
圖5:圍繞版本構建日常構建發布等工作流
圍繞Helm進行版本管理和構建部署
在不同的基礎設施之上,上述的思路可以有不同的實現方式。
而在K8S基礎設施上,Helm Chart就是版本格式的不二之選。
Helm的核心概念包括:
下面看一個典型的例子:
圖6:基于Helm構建版本
得益于K8S資源的強大描述能力,形成一個“版本”的各種組成部分都可以很好的描述,比如:
在此之上,再加上helm提供的模板化能力,就可以清楚的將對一個環境的描述分為兩個部分:
因此上圖中的藍色的框內的就是“測試環境”的一個版本。
helm chart作為版本,可以看到,本質上就是一堆描述文件。這些描述文件可以以目錄的形式存在,也可以以tgz包的形式存在。因為面向SaaS的交付的變更頻率會非常高,因此每次打一個tgz包就會顯得非常的臃腫。所以筆者會采取目錄的形式,那么什么是承載目錄,并且還能實現版本序列技能力的技術呢,很顯然就是Git啦。
我們把上面思路中的那個圍繞版本進行一系列研發活動那種圖翻譯到Helm和Git上,就是這樣:
圖7:圍繞helm chart構建日常構建發布等工作流
至此,利用現成的一些標準化工具,就實現了一套版本機制,及圍繞版本機制的開發流程。
在這套流程下:
一些小細節
在實際使用這套方案的時候,其實還是很多小細節,需要慢慢優化。這里就簡單列兩個:
規模化的采納最佳實踐
上述方案最大的好處,就是采納的都是標準的組件,具有很大的靈活性,和可定制性。
但這同時也是這個方案的壞處,就是太靈活了,各種最佳實踐也需要慢慢摸索和調整。在調整的過程中可能會發現很多類似上面提到的“小細節”,需要進行規范或者封裝。如果進行規模化的推廣,那么就要求每個團隊都有一個很熟悉這些工具的同事。如果無法找到這么多熟悉工具的同是,那就可以考慮對上述的思路進行產品化,使得大部分的開發人員都可以低成本的follow最佳實踐。
云效的AppStack,就著眼解決這個問題,通過白屏化應用編排、版本管理、以及企業級應用編排模板等產品能力幫助降低開源工具使用門檻,提供了開箱即用的最佳實踐。
原文鏈接
本文為阿里云原創內容,未經允許不得轉載。?
總結
以上是生活随笔為你收集整理的SaaS服务的私有化部署,这样做最高效|云效工程师指北的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: DevOps 能力提升模型
- 下一篇: 阿里巴巴 DevOps 工具体系