專欄策劃｜雅純
志愿編輯｜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這樣的工具，現在整個環境都是通過基礎設施來描述出來的，所以整個環境包括中間件的資源都是基礎設施了，在范圍上比原先要廣的多，
從配置的角度，我們有應用配置、運維配置、基礎設施運維配置，甚至軟體生產程序的配置，我們把應用代碼和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，可以通過應用編排、占位符、變數等宣告式定義，實作一套編排多環境差異化部署，同時基于版本和基線實作環境一鍵拉起、一鍵回滾，感興趣的同學點下方鏈接即可免費使用，
https://www.aliyun.com/product/yunxiao/appstack?channel=yy_rccb_36
下篇預告：環境管理的目標是希望有一個穩定、可預期、低成本的環境，在軟體開發中，我們會涉及到開發、測驗、生產各種環境，如何保證這些環境的穩定、可預期、低成本呢？下一節我們將進一步展開，敬請期待，
閱讀上篇：這樣才是代碼管理和 Commit 的正確姿勢！
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/431440.html
標籤：其他