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

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

軟件交付的終態(tài)是提供穩(wěn)定可預期的系統(tǒng)，要做到這一點，我們需要確保：一、軟件制品的一致性；二、運行環(huán)境的一致性。

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

運行環(huán)境一致性的目標是環(huán)境可預期、穩(wěn)定、低成本。其中低成本比較關(guān)鍵，因為環(huán)境資源的成本一般比較高。

我們可以將運行環(huán)境分為3部分：制品、執(zhí)行引擎和編排規(guī)則。

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

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

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

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

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

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

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

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

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

環(huán)境管理的3個階段

階段一：說明書

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

階段二：命令

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

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

階段三：聲明

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

以k8s為例，我們以一個例子來看，如何做環(huán)境聲明

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

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

通過sidecar分離關(guān)注點

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

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

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

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

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

環(huán)境相關(guān)的配置太多，該怎么管理好呢？

通過IaC來定義環(huán)境

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

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

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

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

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

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

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

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

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

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

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

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

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。