配置管理在容器化世界中的角色
Docker已經作為基礎自動化工具被廣泛使用， 越來越多的開發者開始爭論 Docker是否將最終替代配置管理工具這一問題。隨著多數配置管理工具為Docker 提供支持 ，以上爭論的結論似乎是二者將在使用中共存，而不是其中一個代替另一個。
配置管理工具需要確保一組服務器全部成員的初始狀態與其所發生的結構變化都是一致的。配置管理所解決的問題還包括 結構變化 ，即運行中的服務器結構變得與初始狀態不一致。但前提條件是，每一項變化都必須通過配置管理工具實現。現代應用擁有成百上千的服務器，配置管理工具使得批量管理變得更便捷。
然而，在最近幾年，開發者的工作變得更加靈活，應用結構中也引入了API主導的服務導向架構。服務配置從整體到局部轉化、及時發現實時的服務需求、規模變化速度加快等特性，使得開發者開始面對一個新問題，即配置管理的邊界問題。
容器技術使得根據配置需求建立穩定服務器的過程更加快捷，同時使得每次更改中放棄舊版本、重建一個新版本的過程更加方便。對比配置管理，容器看上去更貼近工作實際需求
——只需要將鏡像與需求中的依賴關系相結合，輸出服務節點。Netflix早在其Amazon EC2系統的AMI中就 應用了這個模型 ，其中， AMI系統 （Amazon機器鏡像）是一個可以啟動服務器的鏡像，通常被稱作“ 金色鏡像 ”。
容器技術使得 子服務 的體系架構工作更為 便捷 。任何服務導向的應用架構都將包含內部的服務依賴關系——多服務的復雜依賴關系。在這些服務的業務流程的設計中，拓撲結構與依賴關系同樣重要。Docker就能夠很方便地 對這種服務進行建模 。 Ernest Mueller ，DevOps運動的長期成員、 敏捷管理博客 的合著者，說：
在服務依賴關系建立完成后，隨之出現的是對子服務進行調整的需求。一些工具，如 Etcd 和 Docker ，是通過將子服務緊密整合在容器環境中，來實現對其動態性的調整。在這些工具中，你可以定義一個多服務的環境，進而注冊并通過編程來控制那些正在運行中的服務。
這是與純配置管理相比較而言的，他還補充道：
你只需要改變軟件程序，其余大部分工作就可以通過推動完成了，不需要直接建模。
那么金色鏡像是否是一種“萬金油”？容器是否將最終代替配置管理？
Ben Schwartz ，BancVue的設計師、 博客主 ，并沒有認為這是個值得爭辯的問題。他認為配置管理與容器所解決的根本問題是不同的。
對“容器與配置管理”的不休爭論本質上就是錯誤的。我們從沒有試圖只通過使用一種技術就能解決全部的問題（你不會為了使用Puppet而放棄全部的Java庫，也不會將負載平衡器設置在Maven Central中）。那么為什么我們要討論容器與配置管理的問題呢？我建議我們應該集中精力去做我們經常做的事：選擇正確的工具去做正確的事。
配置管理的目的是部署和變化管理。容器是虛擬機的輕量版，相比虛擬機，容器能更容易地連接現代應用中松散的子服務結構。這是容器的一個很明確的優勢，但那并不意味著配置管理在這樣的架構中沒有價值。
配置管理能夠用于集成環境下的很多工作：
- 基礎鏡像創建和配置，比如 Chef與Docker ， Ansible與Docker ；
- 管理運行中的容器配置
Diego Zamboni 在 2014年UNIX用戶協會配置管理峰會 的 發言 中總結了二者的共存性：
在容器的時代，配置管理未來將是在那些小碎片中進行配置管理。
這里的“小碎片”指的是在容器化的系統中所構建的模塊——應用、容器鏡像與容器本身。他也提出警示，我們應該跳出“不變的基礎服務”這個思維定式。他希望容器中配置管理系統的屬性列表包括輕量化、分布式和彈性化，并牢記容器生命的短暫性。
查看英文原文： The Role of Configuration Management in a Containerized World