系統配置5大設計原則

原文  http://www.infoq.com/cn/news/2015/04/conf-design-principles

Fewbytes首席技術官和 DevOps Days 特拉維夫站的聯合組織者Avishai Ish-Shalom指出，當前定義和更新系統管理的困難是 不一致的配置 。他提出了五條設計原則，幫助解決這些問題。

多種格式的配置需要維護者具備更強的技能、配置結果缺乏驗證和反饋、特別是自定義格式的配置很難自動生成，這些都是配置管理所面臨的問題。Ish-Shalom表示，現代化的配置管理（CM）工具的流行加重了其中的某些問題，因為他們破壞了系統的自動化和標準化。

拿Linux下流行的conf.d模式（ popular conf.d pattern ）作為反例，Ish-Shalom提出，配置管理工具可以在一臺機器上自動應用某些配置，但是手動添加新文件（甚至只是改變它們的順序），卻可以改變最終的配置。配管（CM）工具對檢測這種偏差缺乏足夠的粒度和上下文。

此外，Ish-Shalom還說，刪除這些文件甚至不能保證實際的系統配置會被更新。應用系統配置的多種手段（例如，重新加載或者重新啟動）很難確保即使很小的配置變化能夠自動且一致地生效。即使是不變的基礎架構也不能解決所有場景，正如Ish-Shalom對InfoQ所說的：

即使使用不變的基礎架構和一次性實例，配置仍然是個大問題。在某種程度上說，這樣做的問題更大。配置就像應用程序里“狀態”的概念，雖然有些配置可以在VCS中進行改動，在構建時集成，在持續發布管道中測試，最后像代碼一樣部署到不可變的基礎架構 （這樣很好，如果可能肯定要這么做）——但其它許多配置不能這么處理，比如像數據庫地址這樣的環境配置——這是個只存在于生產環境中的動態值，任何時候都可能由于出現故障而產生改變。再比如功能開關標志，你可以在想將它們打開或關閉的時候切換，其全部意義在于避免再進行一次部署以激活這個功能。最后，盡管一些公司已經發展到不變的基礎架構和一次性組件，世界上大多數公司仍在使用傳統架構——事實上，即使在如今，使用傳統架構的公司依然比使用不變架構的公司數量更多。

Ish-Shalom提出的五大設計原則基于兩個核心思想：創建一個基于REST的配置API，以及按照系統更新需要的類型分離配置文件。

API分別通過標準的GET和POST方法支持讀、寫系統配置。這樣可以通過GET方法交叉檢查當前系統配置與CM工具中定義的是否匹配，以及通過POST方法應用新的配置。這兩大原則支持第三原則，那就是給配管（CM）工具管理配置更新的全部責任，從而避免了conf.d模式。

按照系統更新類型分離的配置文件一起工作（第四原則），這樣配管工具就可以為相同的更新類型，合并多個配置（文件），并使用POST方法向配置API請求變更，然后讀取檢查是否成功應用，并且沒有被修改。

最后，理想的配置格式應該是標準化和序列化的（例如JSON或YAML），可以由配管工具自動生成。如果不可能，那么最好的選擇是將配置視為一個插件，并提取變量到外部配置文件。

當InfoQ詢問，這樣的配置API是否會增加潛在的安全漏洞時，Ish-Shalom說：

配置API和任何其他控制API沒有什么不同。你可以對它進行加密，并要求高級別的身份驗證（如SSL客戶端證書），只在受信任的網絡的特殊端口公布，或者簡單地使用與你正在使用的REST API相同的身份驗證方法。公共云服務（PAAS和SAAS）是一個很好的例子，我們每天通過API配置它們，感覺自然舒適——安全性是內置的，來自 start.s。

Ish-Shalom將在下一個 DevOps日 盧布爾雅那站 討論 DevOps的工作定義 。

查看英文原文： 5 Design Principles for System Configuration