通過應用模型實現自動化交付
企業應用指的是支持企業、事業單位或者政府等機構各項業務運作的軟件系統。除了支持機構內部的協同工作之外,企業應用也支持企業與其供應商、業務夥伴和用戶的協作與協調。
每一套企業應用的複雜程度不盡相同,但往往可以細分出相互協作的多個組件。以輕量級的系統舉例,也要至少劃分成業務系統與數據庫兩個部分。大型的系統則有可能包含數十個組件,若干組件也可以形成模塊。這些組件或模塊之間還需要定義一些配置,來實現彼此之間的關聯依賴。如此複雜的場景,的確難爲到了 ToB 軟件廠商的實施交付人員。
企業應用在傳統模式下的實施部署與升級,其難度、成本都與企業應用自身的複雜性成正比。這是由於在傳統模式下,實施交付人員更多的通過人工的方式,手動部署服務組件、編輯配置文件。無法自動化處理的流程都具有低效與易錯的通病,企業應用的組件數量和複雜性會將這些通病疊加起來。
雲原生時代的企業應用交付都依靠各種容器化交付平臺落地,通過發揮容器化、平臺化的優勢,解決了環境一致性、自動化運維、故障自愈等問題。而在簡化應用交付與升級這一場景中,所選用平臺的能力就十分重要。
Rainbond 是開源的雲原生多雲應用管理平臺,兼具 Kubernetes 集羣自動化管理能力,以及企業應用一鍵安裝升級能力。Rainbond Application Model(RAM)是基於 Rainbond 提出的一種應用模型,通過將企業應用進行模型化的抽象,搭配 Rainbond 平臺的應用市場機制,最終實現了一鍵安裝/升級。高度自動化的交付體驗,提升了企業應用交付效率,降低交付成本。
RAM 模型的抽象,囊括了企業應用所包含的所有服務組件以及組件間的關聯關係。這一高級抽象無關乎企業應用內部包含多少服務組件,也無關乎組件間的關聯關係是否複雜。應用模版(RAM模型在應用市場領域的具體實現)可以發佈到 Rainbond 特有的應用市場中,發佈出的應用模版可以作爲企業應用的安裝包看待,無論原有架構多麼複雜、內部組件多寡,都可以完成一鍵安裝與升級。
爲了適應更廣泛的交付領域,RAM 模型正在努力向 Open Application Model(OAM)演進。OAM 是業界新提出的一種應用模型,其設計是爲了能夠以簡單的方式,在複雜環境中間交付更加健壯的企業應用。
使用Rainbond一鍵安裝企業應用
Rainbond的應用模版是應用模型的具體實現,是企業應用一鍵安裝的載體,如何製作應用模版可以參考下面的教程。
當製作好了應用模版,發佈到應用市場,就可以通過應用模版一鍵安裝,一鍵安裝過程可以將企業應用從開發環境中完美復刻到交付環境中。組件的特性、鏡像、插件、依賴關係都得以保持原樣。
就實際操作而言,點擊應用模版右側的安裝,選定團隊、集羣、應用、版本等必要信息後,確定即可開始安裝目標企業應用。
Rainbond本身能支持各類客戶環境,不管是服務器還是虛擬機,是聯網還是離線,X86還是國產CPU都能支持, 只要客戶環境能安裝Rainbond,就可以通過應用模版一鍵安裝。
製作一個可以一鍵安裝的應用模版
應用模版所承載的企業應用,藉助一鍵安裝能力已然可以快速的交付部署。然而交付完成的企業應用是否可以在安裝完成後自動進入可用的狀態,和應用模版的製作過程有很大的關係。接下來,我們來介紹下,一鍵安裝即可用的應用模版,應該具備怎樣的“自我修養”。
環境變量定義連接信息
可被訪問的地址,是組件之間的相互關聯調用的關鍵。通常情況下,可被訪問的地址會以 IP:Port
或域名的形式體現。然而 IP 的變更,在交付場景中是必然出現的,這嚴重影響了一鍵安裝即可用的能力。所以不要將連接地址寫成固定值,而是將其設計成爲可以通過環境變量的方式動態拾取並配置的形式。Rainbond 平臺提供非常強大的連接信息注入功能,專門用於處理組件間的訪問地址。
數據自動初始化
企業應用的持久化數據,應該與程序文件分離。所有需要持久化的數據,都應該具有獨立的目錄,這些目錄在容器啓動前,可以爲空。如果有多個目錄需要被持久化時,它們最好擁有相同的父級目錄。所有的數據庫中間件、業務持久化數據需要支持自動初始化。數據的初始化有多種方式可供選擇,開發人員可以根據實際情況自行選擇:
- 業務代碼管理數據版本(推薦)
由開發人員在企業應用程序內部添加邏輯,完成對數據庫表結構的初始化操作。這是一種非常通用的方法,企業應用在啓動時自動檢測可連接到的數據庫中是否存在指定的表結構,如不存在則進行一次初始化。這種方式更被推崇的原因在於開發人員也可以藉助這一方式完成數據庫表結構的升級操作。參考 源碼構建實現數據庫表結構自由升級回滾 可以瞭解一種基於 Liquibase 結合 Rainbond 源碼構建能力的數據庫版本解決方案。
- 官方鏡像提供的能力
對於市面上常見的各類數據庫中間件而言,其官方鏡像均具備數據自動初始化的能力。包括但不限於 Mysql、Mongo、Postgresql等常見數據庫。
- 針對非結構化數據製作初始化插件
對於更一般化的場景,平臺支持以插件機制來針對服務組件的指定持久化目錄進行數據初始化,這種方式藉助了外部的對象存儲來保持需要被初始化的數據。該插件的使用方式,參考 通用數據初始化插件 瞭解這一最佳實踐。
合理的解耦方案
爲了實現一鍵安裝企業應用的目標,需要劃分出可以被解耦的不同模塊,並且將模塊以應用模版的方式發佈出來。每一個模塊對應的應用模版,都應該是可以被獨立安裝並運行的。交付實施人員根據最終客戶的業務需求,按需一鍵部署出多個應用模塊,並在圖形化界面下進行拼裝,即完成了企業應用的整體交付。對於企業應用開發人員來說,合理的解耦方案,可以達成模塊化複用的效果,降低開發人員的重複工作量。
深入瞭解到如何合理劃分模塊:使用Rainbond打包業務模塊,實現業務積木式拼裝
使用Rainbond一鍵升級企業應用
由 RAM 實現而來的應用模版是具備版本控制機制的,這意味着在同個應用模版的不同版本之間可以快速的升級與回滾。
對於開發人員而言,在源應用一側作出需要的變更,無論是代碼的改動後構建,還是新加入其他組件,都會在下一次應用模版發佈過程中疊加到新版本的應用模版中去。開發人員務必注意發佈時定義的版本號,Rainbond 通過它來確定是否進行升級。
對於交付人員而言,只需要將不同版本的應用模版導入到交付環境中,Rainbond 會自動識別同個應用模版的不同版本,並執行一鍵升級操作。
而在已經交付完成,正在運行的應用頁面中,小 A 找到了升級的入口。Rainbond 識別到了最新的版本,而升級操作也是一鍵觸發,非常好用。
一鍵安裝和一鍵升級的實現原理
基於 RAM 模型實現的應用模版爲何能做到一鍵安裝複雜應用?首先需要了解應用模版內部構造。
應用模版由兩個部分組成:應用元數據、容器鏡像壓縮包。
應用元數據
應用元數據負責描述應用以及其內部組件的特徵。換句話說,應用元數據是對 RAM 模型的描述。這些元數據會保存在 Rainbond 數據庫中,Rainbond 通過拾取這些元數據,瞭解到需要安裝的是一個什麼樣子的應用。這些元數據主要包括的內容如下:
屬性 | 級別 |
---|---|
應用名稱 | 應用 |
應用版本 | 應用 |
組件間依賴關係 | 應用 |
網關策略 | 組件 |
組件名稱 | 組件 |
組件鏡像 | 組件 |
組件環境變量 | 組件 |
組件插件配置 | 組件 |
組件存儲 | 組件 |
組件端口配置 | 組件 |
組件部署方式 | 組件 |
組件健康檢查策略 | 組件 |
容器鏡像
業務容器鏡像的來源,應用模版一經導入後,容器鏡像會被裝載到 Rainbond 所引用的容器鏡像倉庫中。啓動每一個組件時,Rainbond 會根據元數據中記錄的鏡像地址拉取對應的鏡像。
經過應用元數據的解析插入,以及容器鏡像的導入,交付人員就可以在客戶環境中一鍵安裝企業應用了。
企業應用一鍵安裝完成後,Rainbond 可以保障讓其運行起來。如果希望能更進一步,確保企業應用內部的業務邏輯也能夠正常工作,則需要在應用模版的製作過程中注意更多的自動化改進。
升級
一鍵升級和一鍵安裝的原理類似,一鍵升級的過程實際上是分別對應用元數據和容器鏡像進行了版本的變更。
容器鏡像的升級很好處理,只需要引用不同的 tag 即可。而對於可升級應用內的所有組件而言,升級的過程中會覆蓋以下應用元數據變更。
屬性 | 級別 | 規則 |
---|---|---|
組件 | 應用 | 新增, 更新 |
插件 | 應用 | 新增 |
配置組 | 應用 | 新增 |
鏡像 | 組件 | 更新 |
啓動命令 | 組件 | 更新 |
環境變量 | 組件 | 新增 |
組件連接信息 | 組件 | 新增 |
端口 | 組件 | 新增,更新 |
存儲 | 組件 | 新增 |
配置文件 | 組件 | 新增,更新 |
健康檢測探針 | 組件 | 新增,更新,刪除 |
監控圖表 | 組件 | 新增, 更新 |
監控點 | 組件 | 新增, 更新 |
插件 | 組件 | 新增 |
組件依賴關係 | 組件 | 新增, 刪除 |
存儲依賴關係 | 組件 | 新增, 刪除 |
值得注意的是,基於應用模版的升級,僅包含了應用程序的升級。實際環境中,經常涉及到持久化數據的變更。最常見的一種情況,是企業應用所使用的數據庫的表結構,需要跟隨應用程序的升級而變化。前文中介紹的 源碼構建實現數據庫表結構自由升級回滾 方案,就可以處理這種表結構的版本控制。
企業應用的管理與運維
企業應用的安裝與升級都是一次性的,而管理與運維則是長久持續的。
當企業應用被交付到客戶環境之後,運維人員需要掌控管理運行環境的能力。現代 IT 基礎設施是非常複雜的,運維人員想要在物理機、虛擬機等不同環境之間統籌有度已屬不易,想要在公有云、私有云乃至混合雲之間遊刃有餘更是對其技術能力提出了挑戰。如果能有一款易用的平臺抹平不同基礎設施之間的差異,那就將極大的簡化運維人員的管理工作。
總結
本文重點講述了企業應用自動化安裝和升級的實現過程,這個過程非常適合企業產品沒有功能定製化的標準化交付,對接開發環境可以實現客戶的持續交付,提高10倍以上交付效率。 然而,標準化交付在企業產品交付過程中只能佔少數,對於需要功能定製化的個性化交付場景該如何提供交付效率呢?我們將在下一篇文章將詳細介紹。