簡介：80%的軟件環境管理問題，根因都在這里，云效云原生應用管理平臺AppStack正是基于OAM的應用交付平臺，企業在云效AppStack，可以通過應用編排、占位符、變量等聲明式定義，實現一套編排多環境差異化部署，同時基于版本和基線實現環境一鍵拉起、一鍵回滾。

專欄策劃｜雅純
志愿編輯｜jimmy、呂瑞星

軟件交付的終態是提供穩定可預期的系統，要做到這一點，我們需要確保：一、軟件制品的一致性；二、運行環境的一致性。

第3講我們分享了如何保證軟件制品的一致性，這一講我們來談談如何保證環境的一致性。

運行環境一致性的目標是環境可預期、穩定、低成本。其中低成本比較關鍵，因為環境資源的成本一般比較高。

我們可以將運行環境分為3部分：制品、執行引擎和編排規則。

要保證制品的一致性，第一是保證代碼及其依賴的一致性；第二是保證構建環境的一致性；最后是保證構建腳本的一致性。保證環境的一致性，也包含了三點：

應用的一致性，比如一致的容器鏡像；

容器運行所需的上下文的一致性，比如一致的數據配置等；

編排規則的一致性，需要保證編排執行相同的規則，比如相同容器部署規則、相同節點分布規則、相同備份規則等。

保證這3點，部署完成之后才會形成一致的可運行環境。但是現實當中，環境還是會有很多其它的問題，比如：

• 配置文件中有好多監控之類的配置，對于使用者來說，不知道配置的具體作用，需要修改時不知如何設置。
• 測試的時候依賴的環境經常發生問題，耗費大量等待和排查時間。比如說依賴的API經常出問題，排查修復可能需要等待依賴方很久，導致測試工作無法繼續進行。
• 新環境的搭建很耗時。搭建一個新的環境是很痛苦的事情，比如國際化團隊，經常要搭建新的站點，而每搭一個新的環境就要耗費一整天的時間是很痛苦的。
• 應用在本地無法運行。比如因為缺某個資源導致應用無法正常運行。
• 配置環境需要小心翼翼，可能出現配置遺漏。每次配環境的時候需要很小心，特別是當環境配置由多人配合時，會出現配置沖突，導致程序無法運行，需要全鏈路排查解決。

這里我們簡單列了五個常見的問題，它們的根源都是環境缺乏清晰的定義：不清楚環境的具體內容、對環境搭建過程的認知模糊。

環境的清晰定義，包括環境包含什么制品、這些制品如何部署等。那么環境管理的終態是什么呢？

當制品相同、運行上下文相同，并且資源數據是一樣的情況下，基于相同的編排規則，環境就應該是一致的。同時，環境可以由軟件來定義和聲明。這是我們認為的環境管理的終態，簡單來說，即軟件定義的不可變環境。軟件定義的不可變環境，可以納入版本管理，保證環境首先是定義明確的，其次是有明確版本的。

環境管理的3個階段

階段一：說明書

環境管理的第一個階段是說明文檔，這點相信很多人都經歷過。當我們在做一個項目或產品時，會寫整個產品的部署說明書、說明文檔、升級文檔等各種文檔。但文檔很難保證實用，也不一定是最新的、準確的。每次我們去現場交付時，都會遇到一些文檔里沒有描述的問題。這時候還得打電話確認，是否有遺漏什么。用文檔或說明書去管理環境，存在很大的弊端，所以我們想到了用命令的方式去管理。

階段二：命令

第二階段，我們通過命令的方式，寫了各種shell、Python腳本，把相關命令組合在一起。之前我們在做一個產品的私有化交付的時候，一開始的做法就是用腳本去管理環境，因為開啟一個新環境實在太痛苦了，需要花很多時間改參數、找包、配IP等，效率太低。所以我們寫了腳本來管理，用腳本代替了文檔。

但是用腳本管理環境也存在很多問題。我們要應對各種各樣的環境，同一個任務在不同的場景里，命令組合可能是不一樣的，所以腳本會越來越多，維護腳本的成本也越來越高。

階段三：聲明

為了解決命令腳本的維護和穩定性問題，我們進入了第三個階段，聲明式——通過配置的方式表達環境，把環境定義出來。聲明式的描述提供了環境的確定性表達。

以k8s為例，我們以一個例子來看，如何做環境聲明

上圖是K8S的簡單架構，左上角是K8S的master，左下角是node，master有好幾個組件：scheduler、ControllerManager、APIserver，以及Etcd。Etcd是一個分布式存儲，配置信息都在Etcd里面。Node是物理機或者虛擬機，在每一個Node上面會有多個pod，上面會運行很多的容器。

我們知道K8S的最小單元是pod，里面有容器，還有各種網絡存儲等，通過pod聲明去描述。聲明被apply后，具體的事情在controller里面處理。

通過sidecar分離關注點

我們寫一個應用，這個應用里面大量的代碼其實與業務無關，而是包含很多服務治理的代碼，例如日志、監控、限流、熔斷等。這些代碼占了很大的比重，而且這些代碼的維護者和應用開發者不一定是同一批人。服務治理相關的代碼，在很多企業會有專門的團隊負責維護和升級，類似阿里的中間件團隊。傳統的情況下，我們需要升級并重新部署應用才能升級服務治理能力。但是在云原生時代，應用開發者希望僅關注應用業務代碼，服務治理相關的代碼放在其他的容器里面，業務容器和服務治理容器通常會編排在同一個pod里面，但是服務治理容器的管理、開發、發布都跟應用開發者沒有關系，這些就是sidecar容器。sidecar容器實現了關注點的分離，應用的開發者和中間件的開發者以及運維相關的開發者，都可以有自己的關注點。

我們以兩個角色為例，一是業務的開發者，關注的是應用的容器，所以發布的時候，他的關注點都在應用容器這一塊。二是企業的SRE，他的關注點往往在sidecar的各種服務治理容器上，比如logagent的日志級別和采樣率是否合理等。

通過sidecar，業務開發者和SRE的關注點就分離了。這樣分離還有一個好處，就是中間件下沉，都以sidecar的方式管理。一旦遇到相應的中間件需要升級，業務代碼不需要做任何的改變和發布，只需要做sidecar的發布就好了。

我們前面提到，一致的環境需要有3個組成部分：相同的制品、相同的運行上下文以及相同的編排規則。相同的運行上下文，本質就是里面的配置要一致。最早我們是用文檔告訴我們怎么把環境管理起來，之后用腳本，最后用環境聲明。

然而，用聲明式的方式定義環境也并不完美。舉個具體的例子，在應用運行的時候需要有一些相應的配置，中間件、基礎資源、CPU、存儲等都需要配置，這樣會面臨一個很大的問題——環境相關的配置太多了。

環境相關的配置太多，該怎么管理好呢？

通過IaC來定義環境

為了解決這個問題，業內采用了IaC的概念（InfrastructureasCode）。早期在云機房上架的時候會用到IaC，比如有一個新的機器過來，要裝成centos7的系統，里面要配特定的DNS服務等等。這是就會定義一個聲明文件，發送給saltstack這樣的工具?，F在整個環境都是通過基礎設施來描述出來的，所以整個環境包括中間件的資源都是基礎設施了，在范圍上比原先要廣的多。

從配置的角度，我們有應用配置、運維配置、基礎設施運維配置，甚至軟件生產過程的配置。我們把應用代碼和IaC代碼，放在兩個庫里面（也有放到一個庫里面的，各有利弊，在此我們不展開也不評價）。

比如上圖中，在IaCRepo里我們放了動態配置（即運行時的配置）、BaaS配置（基礎設施，如數據庫、中間件存儲、消息隊列等）、監控配置（如監控粒度、采樣頻率）、發布配置等。所有的配置都聲明在代碼庫里面，基于該聲明編排的所有環境就都是一致的了。

任何事情都是有利有弊，用IaC的方式管理環境又會帶來什么新的挑戰呢？

首先是“靈活的代價”。因為所有的配置都是松散的文本，缺少統一的聚合根，導致修改者需要自己理解這些配置背后對應的依賴關系。比如某個配置項設置為on會開啟限流，但是必須配合特定的configMap一起使用；比如開啟了一個Ingress插件，但如果另一個Rollout插件沒有開啟，會無法正常工作；再比如HPA和CronHPA無法同時使用，會產生沖突。由于編寫的靈活性，會導致無窮的組合形式，其組合產生的后果往往在運行時才會發現。

其次是知識的成本。IaC將一個環境所有的配置都以文本的界面給到了開發者，但是很多配置項是需要專業背景的，比如運維相關的策略、比如監控的配置方式等等，價值IaC本身的學習成本，往往讓很多開發者望而生畏。

為了解決這個問題，阿里聯合微軟一起發布了OAM模型，以應用為統一維度，將IaC包含的各類資源和角色進行了分類和聚合。

首先，OAM引入了應用（Application）的概念，將應用的各類IaC配置都聚合在一起，解決其依賴問題。

其次，OAM將IaC的使用者分離為：應用開發者、應用運維、基礎設施運維三大角色，彼此的關注點進行了分離。

OAM抽象和簡化了IaC的定義和維護方式，降低開發者的學習和使用成本。

總結一下，我們認為，環境管理的終態是軟件定義的不可變環境，而當下，它的最佳實踐我們認為是基于OAM模型的、以應用為核心的IaC聲明。

云效云原生應用管理平臺AppStack正是基于OAM的應用交付平臺，企業在云效AppStack，可以通過應用編排、占位符、變量等聲明式定義，實現一套編排多環境差異化部署，同時基于版本和基線實現環境一鍵拉起、一鍵回滾。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的80%的软件环境管理问题，根因都在这里的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。