執行 chef-server 而不是 chef-solo 有什麼好處？
我正在為我的團隊尋找自動化部署解決方案，並且在過去的幾天裡一直在使用 Chef。我已經能夠使用 chef-solo 從基本的 Red Hat VM 上執行一個簡單的 Web 應用程序。
我們的最終目標是使用 Chef（或其他系統）在我們執行建構時自動將應用程序拓撲部署到雲中。我們的流程基本上是這樣執行的：
- 我們的網路應用程式碼、依賴項和廚師食譜儲存在 SCM 中
- 執行建構並為要獲取和測試的圖像創建單個包
- 然後，建構引擎部署新的雲鏡像，執行 Chef 客戶端以安裝軟體包。
- 圖像從 SCM 或 Chef 伺服器獲取說明書並安裝一切以啟動和執行
執行 Chef Server 有哪些好處和/或案例？
擁有 Chef Server 並從 SCM 獲取食譜與使用 chef-solo 並擁有一個將從 SCM 中提取食譜的腳本有什麼主要好處嗎？
我將把這個答案定位為好像問題是“chef-solo 的優勢是什麼”，因為這是我所知道的涵蓋方法之間差異的最佳方式。
我的總結建議與其他人一致：如果您需要管理一個動態的、虛擬化的環境，您將經常在其中添加和刪除節點，請使用廚師伺服器。如果您需要，廚師伺服器也是一個很好的CMDB 。如果您有一個動態性較低的環境，其中節點不會經常更改但角色和食譜會更改，請使用 chef-solo。您的環境的大小和復雜性或多或少無關緊要。兩種方法都可以很好地擴展。
如果您部署 chef-solo，請使用帶有 rsync、“git pull”或其他一些冪等文件傳輸機制的 cronjob，以在每個節點上維護 chef 儲存庫的完整副本。cronjob 應該很容易配置為 (a) 根本不執行和 (b) 執行，但不同步本地儲存庫。在您的 chef 儲存庫中添加一個 nodes/ 目錄，其中每個節點都有一個 json 文件。在辨識正確的節點文件方面，您的 cronjob 可以像您希望的那樣複雜（儘管我建議只需 $(hostname -s).json。您還可能希望創建一個操作碼帳戶並使用託管廚師配置客戶端，如果除了能夠使用刀下載社區食譜和創建骷髏之外，別無其他原因。
除了明顯的“不必管理伺服器”之外，這種方法還有幾個優點。您的原始碼控制將是所有配置更改的最終仲裁者，儲存庫將包括所有節點和執行列表，並且每個伺服器完全獨立，便於一些方便的測試場景。
Chef-server 引入了一個漏洞，您可以在其中使用“刀上傳”來更新食譜，並且您必須自己修補這個漏洞（例如使用 post-commit 鉤子），否則可能會被“刀上傳”的人默默地覆蓋站點更改這是他筆記型電腦上過時的本地儲存庫中的過時配方。chef-solo 不太可能發生這種情況，因為所有更改都將直接從主記憶體儲庫同步到伺服器。這裡的問題是紀律和合作者的數量。如果你是一個單獨的開發者或者一個很小的團隊，通過 API 上傳食譜的風險不是很大。在更大的團隊中，如果您沒有實施良好的控制，可能會出現這種情況。
此外，使用 chef-solo，您可以將所有節點的角色、自定義屬性和執行列表作為 node.json 文件儲存在主 chef 儲存庫中。使用 chef-server，角色和執行列表可以使用 API 動態修改。使用 chef-solo，您可以在版本控制中跟踪此資訊。這是可以清楚地看到靜態和動態環境之間的衝突的地方。如果您的節點列表（無論它可能有多長）不經常更改，那麼在修訂控制中擁有這些數據非常有用。另一方面，如果您經常產生新節點並銷毀舊節點（再也看不到它們的主機名或 fqdn），則將其全部保存在修訂控制中只是不必要的麻煩，並且擁有一個 API 來進行更改非常方便。Chef-server 還具有用於管理動態雲環境的完整功能，例如“knife bootstrap”上的名稱選項，它允許您替換 fqdn 作為辨識節點的預設方式。但是在靜態環境中，這些功能的價值有限，尤其是與在版本控制中擁有角色和執行列表以及其他所有功能相比。
最後，配方測試環境可以即時設置，幾乎不需要額外的工作。您可以禁用在伺服器上執行的 cronjobs 並直接對其本地儲存庫進行更改。您可以通過執行 chef-solo 來測試更改，您將確切地看到伺服器在生產中將如何配置自己。測試完所有內容後，您可以簽入更改並重新啟用本地 cronjobs。但是，在編寫食譜時，您將無法使用“搜尋”API，這意味著如果您想編寫動態食譜（例如負載均衡器），您將不得不繞過這個限制，從 json 文件中收集數據您的節點/目錄，這可能不太方便，並且會缺少完整 CMDB 中的一些可用數據。再一次，更動態的環境將有利於數據庫驅動的方法，對於本地磁碟上的 json 文件，動態環境較少。在廚師執行必須對中央數據庫進行 API 呼叫的伺服器環境中，您將依賴於管理該數據庫中的所有測試環境。
最後一個也可以在緊急情況下使用。如果您正在對生產伺服器上的關鍵問題進行故障排除並通過配置更改來解決它，您可以立即在伺服器的儲存庫上進行更改，然後將其推送到上游主伺服器。
這些是 chef-solo 的主要優勢。還有一些其他的，比如不必管理伺服器或為託管廚師付費，但這些都是相對次要的問題。
總結一下：如果您是動態且高度虛擬化的，則 chef-server 提供了許多出色的功能（在其他地方有所介紹），並且 chef-solo 的大部分優勢將不那麼明顯。然而，chef-solo 有一些明確的、通常未被提及的優勢，尤其是在更傳統的環境中。請注意，部署在雲上並不一定意味著您擁有動態環境。例如，如果您不能在不發布新版本軟體的情況下向系統添加更多節點，那麼您可能不是動態的。最後，從高層次的角度來看，CMDB 可以用於許多僅與系統管理和配置相關的事情，例如會計和團隊之間的資訊共享。僅憑該功能，使用 chef-server 可能是值得的。