云原生 DevOps,模型化应用交付能力的重要性
撰稿:溪洋
審核校對:天元、海珠
編輯&排版:雯燕
云原生正在成為企業業務創新和解決規模化挑戰的加速器。
云原生帶來的變革絕不限于基礎設施和應用架構等技術層面,更是對于研發理念、交付流程和 IT 組織方式的變革,也在推進企業 IT 組織、流程和文化的變革。在云原生架構漸為普及的背后, DevOps 文化及其支撐其落地實踐的自動化工具與平臺能力,發揮了關鍵的價值。
云原生帶來的研發與運維協作界面
相較于云原生,DevOps 并不是什么新鮮的事情,其實踐早已深入企業現代應用程序架構。DevOps 強調團隊間的溝通和快速反饋,通過構建自動化的持續交付(Continuous Delivery)及流水線的應用發布方式,達到快速響應業務需求、交付產品和提高交付質量的目的。隨著容器技術在企業的規模化應用,云計算可編程基礎設施和 Kubernetes 聲明式的 API 等能力加速了開發和運維角色的融合。
云原生的大勢所趨使上云成為企業標配,圍繞云原生去定義下一代研發平臺成為必然,也倒逼著 IT 組織方式進一步發生變化——新的平臺工程團隊開始浮現。在這樣的背景下,如何在云原生的環境下更高效地實踐 DevOps 成為一個新的課題和訴求。
下一代 DevOps 平臺演進趨勢
伴隨著 Kubernetes 生態從底層到應用層能力的逐步完善,平臺工程團隊可以更方便地基于業務場景和終端用戶實際需求來構建不同的應用平臺,卻也為上層應用開發者帶來了挑戰和困擾。
Kubernetes 生態本身的能力池固然豐富,但是社區里卻并沒有一個可擴展的、方便快捷的方式,為云原生架構下混合、分布式的部署環境引入一致的上層抽象來為應用交付進行建模。應用交付過程上層抽象能力的缺失,使 Kubernetes 的復雜性無法做到向應用開發人員屏蔽。
下圖展示了一個云原生下的 DevOps 流水線的典型流程。首先是代碼的開發,代碼托管到 Github,再接入單元測試的工具 Jenkins,此時基本研發已完成。再接著到鏡像的構建,涉及到配置、編排等。云原生中可以用 HELM 打包應用。打包好的應用部署到各個環境中。但整個過程中會面臨很多挑戰。
首先,在不同的環境需要不同的運維能力。其次,配置的過程中要創建云上數據庫,需要另外打開一個控制臺來創建數據庫。還需要配置負載均衡。在應用啟動以后還需要配置額外的功能,包括日志、策略、安全防護等等。可以發現,云資源和 DevOps 平臺體驗是割裂的,里面充斥著借助外部平臺創建的過程。這對新手來說是非常痛苦的。
在容器出現之前的傳統的 DevOps 模式需要不同的流程和工作流。容器技術是以 DevOps 的視角構建的。抽象的容器所提供的功能會影響我們如何看待 DevOps,因為隨著微服務的出現,傳統的架構開發將發生變化。這意味著要遵循在 Kubernetes 上運行容器的最佳實踐,并將 DevOps 的理念向 GitOps、DevSecOps 擴展,使云原生下的 DevOps 更加高效、安全、穩定、可靠。
OAM(Open Application Model) 試圖提供一種云原生應用的建模語言,以實現研發和運維的視角分離,使 Kubernetes 的復雜性無需透傳至研發,運維通過提供模塊化、可移植、可擴展的特性組件,支撐各種復雜的應用交付場景,從而實現云原生應用交付的敏捷性和平臺無關性。其在 Kubernetes 上的完整實現 KubeVela,已經被業界認為是構建下一代持續交付方式及 DevOps 實踐的核心工具。
最近,阿里云在 2021 云棲大會上發布了云效應用交付平臺 AppStack ,旨在進一步加速企業云原生 DevOps 規模化落地。據云效應用交付平臺 AppStack 研發團隊介紹,其在設計之初就全面支持原生 Kubernetes 和 OAM/KubeVela ,以實現對應用部署架構無綁定、無侵入,使企業不用擔心遷移以及技術改造成本。這也標志著 KubeVela 正在成為云原生時代應用交付領域的重要基石。
基于 KubeVela,構建以應用為中心的交付系統
在云原生理念迅速普及的今天,混合環境部署(混合云/多云/分布式云/邊緣)已經成為了大多數企業應用、SaaS 服務、應用持續交付平臺的必然選擇,而云原生技術的發展趨勢也正在朝著“一致的、跨云、跨環境的的應用交付”不斷邁進。
KubeVela 作為一個開箱即用、面向現代微服務架構的應用交付與管理平臺,已經正式發布 1.1 版本。在此版本中,KubeVela 更加聚焦面向混合環境的應用交付流程,帶來了多集群交付、交付流程定義、灰度發布、公有云資源接入等多個開箱即用的能力和更加友好的用戶體驗,幫助開發者從“靜態配置、模板、膠水代碼”的初級階段,直接升級至“自動化、聲明式、統一模型、天然面向多環境”的下一代以工作流為核心的交付體驗當中。
基于 KubeVela,用戶可以非常輕松地處理以下場景:
多環境、多集群應用交付
面向 Kubernetes 的多環境、多集群交付已是一個標準性需求。從 1.1 版本開始,KubeVela 不僅實現了多集群的應用交付,并且既可以獨立工作直接納管多個集群,也可以集成 OCM、Karmada 等各類多集群管理工具來進行更復雜的交付動作。在多集群交付策略的基礎上,用戶還可以通過定義 Workflow 來控制交付到不同集群的順序、條件等工作流步驟。
定義交付工作流(Workflow)
Workflow 的具體使用場景則很多,比如在多環境應用交付場景中,用戶可以定義不同的環境交付的順序和前置條件等 。KubeVela 的工作流是面向 CD 過程的,同時也是聲明式的,所以它既可以作為 CD 系統直接同 CI 系統(比如 Jenkins 等)對接,也可以嵌入到現有 CI/CD 體系中作為增強和補充,落地方式非常靈活。
在模型上,Workflow 是由一系列 Step 組成的,而在實現上,每一個 Step 則是一個獨立的能力模塊,由其具體的類型和參數來決定其具體步驟的能力。在 1.1 版本中,KubeVela 內置的 Step 已經比較豐富,也非常容易擴展,幫助用戶輕松對接已有的平臺能力,做到無縫遷移。
以應用為中心的云資源交付
KubeVela 的設計是從“以應用為中心”的視角出發,因此可以幫助開發者以完全 Serverless 的方式更好、更方便的管理云資源,而不是疲于應付各種不同的云產品和控制臺。在實現上,KubeVela 內置集成了 Terraform 來作為云資源的編排工具,并且能夠以統一的應用模型支持各個云廠商上百種不同類型云服務的部署、綁定和管理。
在使用上,目前 KubeVela 將云資源分為以下三類:
- 作為組件:比如數據庫、中間件、SaaS 服務等。比如 KubeVela 中的 Alibaba-RDS 服務就屬于這種
- 作為運維特征:比如日志分析、監控可視化、監控報警等服務
- 作為應用運行基礎設施:比如 Kubernetes 托管集群、SLB 負載均衡、NAS文件存儲服務等
更容易落地的 GitOps 持續交付實踐
KubeVela 作為一個聲明式的應用交付控制平面,天然就可以以 GitOps 的方式進行使用(可單獨使用,也可配合 ArgoCD 等工具),并且能夠為 GitOps 場景提供更多端到端的能力和增強、幫助 GitOps 理念以更加親民和解決實際問題的方式在企業中落地。這些能力包括:
- 定義應用交付工作流(CD 流水線)
- 處理部署過程中的各種依賴關系和拓撲結構
- 在現有各種 GitOps 工具的語義之上提供統一的上層抽象,簡化應用交付與管理過程
- 統一進行云服務的聲明、部署和服務綁定
- 提供開箱即用的交付策略(金絲雀、藍綠發布等)
- 提供開箱即用的混合環境/多集群部署策略(放置規則、集群過濾規則、跨環境Promotion 等)
- 在多環境交付中提供 Kustomize 風格的 Patch 來描述部署差異,而用戶無需學習任何 Kustomize 本身的細節
- ……
KubeVela 1.2 版本即將重磅發布
持續打造天然面向混合環境的企業應用操作系統、讓開發者享受交付應用的過程,這是 Kubevela 項目的目標和愿景。在接下來的 1.2 版本,KubeVela 將帶來以應用為中心的控制面板 UI,實現便捷的企業應用組裝、分發、交付流程,提供給開發者更簡單的應用交付體驗,同時覆蓋邊緣應用交付等更多的使用場景。
KubeVela 1.2 版本將在 2021 年 12 月舉辦的 KubeCon China 上重磅發布,敬請持續關注 KubVela 社區以及阿里巴巴云原生動態!
您可以通過如下方式了解更多關于 KubeVela 以及 OAM 項目的細節:
1)項目代碼庫:
github.com/oam-dev/kubevela
歡迎 Star/Watch/Fork!
2)項目官方主頁與文檔:
kubevela.io/
從 1.1 版本開始,已提供中文、英文文檔,更多語言文檔歡迎開發者進行翻譯。
3)項目釘釘群:23310022;Slack:CNCF #kubevela Channel
4)加入微信群:請先掃碼添加以下 maintainer 微信號,表明進入 KubeVela 用戶群:
總結
以上是生活随笔為你收集整理的云原生 DevOps,模型化应用交付能力的重要性的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 数字原生,创新生长|企业如何打造数字创新
- 下一篇: 今年双 11,阿里业务 100% 上云,