作者：焦振清
配置管理工具的定位
每次我提到配置管理工具，有些同學就會問類似的問題：容器化時代和Serverless時代，還需要配置管理工具嗎？我們先不去討論容器化之後是否需要配置管理工具，那什麼時候容器能夠在全球範圍達到100%的普及？什麼時候AWS僅提供容器而不再提供虛擬機呢？
之所以會有如上的問題，根源還在於配置管理工具的定位，到底要解決什麼問題？配置管理工具的廠商當然希望你什麼事情都通過它來實現，在很長時間內，因爲市面上沒有針對運維各類場景的細分產品，因此配置管理工具就承擔了多面手的角色，而隨着各類細分產品的逐漸成熟，那些本不適合配置管理工具解決的場景，必然會被逐步替換。舉個例子，你可以搜索到很多早期用配置管理工具進行服務部署的教程，但現在講服務部署，恐怕很少會有人建議你使用配置管理工具了。
那配置管理工具的定位到底是什麼呢？個人認爲是持續保證運行環境的一致性，主要針對符合冪等性的變更操作，具體解釋如下：
-
持續保證，是要在機器的整個生命週期中始終確保最終結果符合預期，不論是何種原因導致的不同，都能夠修正或者至少推送不一致信息出來。如果只是一次性的操作，那直接批量下去即可，哪裏需要配置管理工具。
-
一致性，主要是規模問題，如果只有一臺機器，那這臺機器就是標準，也就不會用到配置管理工具，因此配置管理工具主要是支持超大規模集羣的一致性管理。
-
符合冪等性的變更操作，也就是無論這些配置在該客戶機上執行多少遍，每次的結果都是相同的。舉例來說，維護JVM的版本爲x.x.x，這類操作，無論執行多少次，結果都是相同的。
-
運行環境，通俗點就是安裝完操作系統之後到部署服務之前這段環節的準備工作，比方說對系統參數進行優化，調整DNS/NTP等的配置，安裝一些常用的工具，部署通用的客戶端等等。大致的分類可以參考下圖。類似於JVM這種和服務強關聯的軟件，在有些公司會將其定位爲程序的一部分放在發佈包中，而有的公司則會視其爲運行環境的一部分，分類不同而已，起碼大家不會把NTP的配置歸入到程序包中進行管理而是交由運行環境保障。
市面上，配置管理工具的選擇有很多，號稱CAPS（ Chef 、 Ansible 、 Puppet 、 SaltStack ），我使用Puppet較多，通過在單機上的客戶端，可以做到”持續保證運行環境的一致性“。對於工具的選型，如果有幾個候選相差不大，那麼更適合你的或者說你更容易搞定的，選他就對了。
配置管理工具的解決方案
全球範圍內，筆者瞭解到的一些使用信息：
-
百度是使用Puppet規模最大的公司之一，其部署規模達到幾十萬物理機
-
Facebook 使用Chef (https://github.com/facebook/chef-cookbooks)
-
Google使用Puppet來管理辦公網設備
-
AWS提供Puppet和Chef （https://github.com/aws/opsworks-cookbooks）
-
Twitter使用Puppet，但近況未知
-
Uber使用Puppet，但近況未知
-
騰訊，阿里和京東沒有統一使用
那爲什麼還會有公司使用Puppet呢（接下來，我將把配置管理工具替換爲Puppet），其實剛剛的定位就可以回答這個問題，持續保證運行環境的一致性。在系統安裝階段，各大公司都會將一些定製化的內容置於安裝鏡像內，例如常用的軟件和工具，客戶端，一些調優參數，內核模塊等等，從而達到開機即用的要求。但存量問題，如何對已經裝機完畢的機器，新增/修改/刪除部分配置內容（例如新裝各種工具如iotop、iftop），以及說服務器存在安全漏洞，需要緊急修復，這個時候，其實鏡像模式都不能很好的解決問題，大部分情況下，還得找運維團隊通過Ansible這類批量操作的方式進行處理。
有同學會說，鏡像有問題，重新上線鏡像就好了，分分鐘就能搞定，但是下面的問題大家是否考慮了：
-
全量更新公司的上百萬個容器需要多久時間（這類場景數據一般都不需要移動）
-
運行容器的宿主機如果全量重裝就意味着其上的虛擬機要遷移數據
-
變更入口無法收斂時，服務器運行時間越久，不一致狀態的可能性越高
-
對於一致性狀態的收集和統計
綜合上述的原因看，不可變基礎設施對於全量上雲的公司來講，或許可以一試，也許有可能實現，但對於雲廠商本身或者大廠來講，追求所謂的不可變基礎設施，投入產出可能不成比例。退而求其次，零接觸配置（ZTP，Zero Touch Provisioning）其實也挺好的。
基於此，我提出的折中方案是：鏡像+Puppet+Grafana的組合
-
持續將Puppet維護的內容定期推送到鏡像當中，儘量減少Puppet的操作場景
-
Puppet的重點從配置管理轉變爲一致性檢查並輔助進行臨時性的配置變更
-
將一致性檢查的結果通過Grafana進行展示和監控
-
對運行環境的變更只能通過鏡像和Puppet方式進行
一些可落地的實踐
通過Puppet，我們能夠確保如下信息持續的一致性
-
定期收集服務器上的各類基礎信息用於一致性監控
-
各類Agent被成功部署並能正常運行且版本符合預期
-
系統服務版本、配置和運行狀態的統一維護（系統服務如NTP/DNS/YUM）
-
系統內核參數的統一維護
-
各類工具和軟件均被正確安裝且版本符合預期
-
信任關係的統一維護（避免違規的信任關係建立）
-
UID和GID的統一維護（避免不同機器同一賬號的UID不同）
-
密碼和密碼強度要求統一維護（提升安全性）
-
主機名的統一維護
-
/etc/hosts的統一維護，禁止添加任何記錄
-
定期清空Iptables策略
-
關閉SWAP分區
上述策略的具體配置，可以參考我們開源的內容：
https://github.com/cloud-op/puppet-public
而Puppet官方也給出了一些高頻場景（Top 5 Things to Automate Right Now with Puppet，詳見參考文檔的鏈接）
-
Task 1: Standardize service accounts
-
Task 2: Cron jobs and scheduled tasks
-
Task 3: Standardize NTP
-
Task 4: Disable Windows shutdown event tracker on non‑production systems
-
Task 5: Standardize MySQL deployments
對於各類信息的一致性監控，兩個頁面以供參考：
-
下面的截圖是全量服務器的硬件信息的統計
-
下面的截圖是全量服務器的內核參數配置的統計
從以上的截圖內容也可以看出，這類信息，不管是服務器還是Docker，隨着運行時間的推移，都有可能發生各種變化，在變更入口無法完全收斂的情況下，通過Puppet來維護和統計狀態，就變得極爲重要了。
最後，對於超大規模集羣，也可以參考Puppet官方提供的解決方案，後期我們也會提供國內互聯網廠商的解決方案的相關文章。
不一致的影響
問題定位耗時長
很多人都玩過”大家來找茬“，就是在兩張相似的圖片中將所有的不同點找出來。在工作中，大家來找茬的場景變成了在一萬臺機器中找出一個不同的機器來，難度和耗時可想而知。如果不巧遇到這類問題，加上支撐工具不完善，想要找出來這種小概率異常的問題，真的是要剝層皮。
缺少權威源
手錶定律是指擁有兩塊以上手錶，並不能幫人更準確的判斷時間，反而會製造混亂，讓看錶的人失去對時間的判斷。
筆者幾年前參加的一個case study（故障覆盤）大致情況如下，運維人員長期進行手工上線，有一次誤操作，將線上所有服務器的Nginx配置全部刪除，相關的配置也沒有版本管理，導致服務故障。只能從測試環境爲數不多的幾臺機器上找配置了，但測試環境的配置，每臺機器都不一樣，也無法判斷哪個配置是最新的完整的配置，只能一個個試試碰運氣，即使這樣，最後也只是勉強恢復服務，依然有很多二級和三級路徑的轉發規則丟失了。
廣義的不一致
除去文中已經提到的運行環境的各種配置可能導致的不一致外，還有一些廣義上的不一致的問題，可能會影響服務的可用性，同樣需要進行一致性檢查
-
硬件規格和批次不一致導致的性能不一致，如CPU型號不同，硬盤類型不同，陣列卡/網卡廠商不同
-
容器規格不同導致的性能不同，如2C4G和4C8G
-
同一個服務在多個AZ的實例數量不同
-
底層硬件的配置不同，如BIOS的設置，Raid卡的設置等
-
服務器所處的網絡設備型號不同，帶寬不同，延時不同，擁塞程度不同
-
兩個AZ的業務特點不同，如某AZ是下載類業務居多，某AZ是離線計算任務居多，在該AZ的業務都可能會受到不同的影響
參考文章
Facebook 引入 Chef 來管理其 web 層
-
https://www.infoq.cn/article/2013/02/facebook-chef
Twitter 的支撐架構：擴展網絡與存儲並提供服務
-
https://www.infoq.cn/article/2017/02/scaling-twitter-infrastructure
Puppet 監控速查手冊：問題 / 原因→解決方案
-
https://www.infoq.cn/article/q8V6bzCHQMzruOkQPKK9
Top 5 Things to Automate Right Now with Puppet
-
https://puppet.com/system/files/2019-09/puppet-top-5-things-to-automate-whitepaper%20%281%29.pdf