Chef 集成任務最佳實踐
我是新來的廚師（使用託管廚師伺服器），並且我很糊塗，基本上了解如何配置單個伺服器。我遇到的麻煩是弄清楚如何將各種配置的伺服器集成到功能集群中。
在我目前的案例中，我使用的是 Amazon EC2。我正在使用帶有幾個清漆伺服器的負載平衡器，這些伺服器將請求傳遞給連接到 RDS 伺服器的多個前端應用程序伺服器。我還有一個後端實用程序伺服器，它必須偶爾將一些文件同步到 FE 應用程序伺服器。
你將如何將所有這些粘合在一起？FE 伺服器需要了解 rds 實例和 redis 伺服器，但後端實用程序伺服器和 varnish 節點必須了解 FE 應用程序伺服器。理想情況下，應用程序伺服器將實現某種自動縮放，根據需要配置更多節點。
最後，再加上還需要有開發和階段環境，其中清漆伺服器通常與應用伺服器位於同一虛擬機上。
您是否使用標記來註冊 FE 節點，然後在最後在 varnish 和 BE 伺服器上執行配方時查詢這些值？
我只是在尋找一些我認為是相當常見的 n 層 Web 集群案例的最佳實踐。
您的問題沒有具體說明您使用的是 chef-client 還是 chef-solo，所以我將假設前者。
兩個 Chef 構造與您的問題特別相關：search和environment。
因為 Chef 伺服器正在索引節點的所有已知屬性，所以您可以使用搜尋來根據任何屬性定位節點，例如它們的執行列表的內容或您分配給節點的任何標籤。假設您有一個設置您的 redis 伺服器的配方（或角色），一個配置您描述的 FE 應用程序伺服器的配方可以搜尋在其執行列表中具有該 redis 配方的節點，並使用該節點的屬性來填充應用程序的配置文件。同樣，配置您的 Varnish 伺服器的配方可以搜尋您的應用伺服器並使用它們的地址填充 Varnish 配置文件。
環境可以被認為是一種特殊的標籤，當您只想了解屬於同一邏輯集的節點時，可以使用它來限制搜尋查詢的範圍。除了充當標籤之外，Chef 環境還可用於覆蓋節點屬性並強制執行說明書版本鎖定。
這些構造都不能直接應用於發現您的基礎設施的部分，例如 RDS，您不能直接執行 Chef，但是因為您可以在您的食譜中使用“原始”紅寶石，所以像霧或right_aws 之類的庫將允許您查詢 AWS API 以獲取詳細資訊您提供的資源（例如，存在哪些 RDS 實例以及它們的地址是什麼），您可以使用您應用的任何標籤過濾結果。
通過將諸如霧之類的庫與 Chef 的搜尋功能相結合，您應該能夠搜尋到通往雲集成自動化必殺技的道路。直到下一次美國東部的重大停電。