顯然，Chef 最好的事情之一是透過說明書，特別是透過包裝說明書方法，重新使用經過驗證的組件。
但是，您如何選擇要包裝的食譜？有些例子浪費了我大量的時間。
一本食譜，其配置 erb 帶有硬編碼的過時標記，而不僅僅是棄用標記。該服務拒絕設定檔。注意：據我了解，除非您複製並維護整個模板，否則包裝修正後的模板 erb 並不是一件小事。
一本檢查 Ubuntu 版本高達 9.0.4 的說明書，似乎沒有做任何高於此的事情，而是引用過時的 /etc/event.d/ 目錄。
食譜與 runit 或 bluepill 等流程監控工具有很強的耦合性。如果您喜歡的工具不在清單中並且您無法對此進行調整，這也是令人頭痛的一個原因。
到目前為止，我傾向於使用supermarket.chef.io 食譜，這些書大多有效。除了我想要的服務的食譜似乎沒有維護並且正在等待採用。
一些想法：
檢查最近的 github 提交/上次更新時間。但是，如果它有效呢？那就不應該更新了。
星星。但如果星星都是很久以前發布的，而食譜是最新的呢？
檢查 github 上是否有未關閉的問題。可能會更好。
提前查看食譜和屬性。不過，如果您已經知道目標軟體的設置，效果會更好。
查看貢獻者的數量，並評估它是否是一個快速的副項目，或者是否有可能繼續維護。
運行它並查看錯誤類型。我首先選擇的那些在我看來就像食譜，它們不追蹤作業系統或他們管理的程式的最新更新，但不具有基於屬性的靈活性來允許它。
有評級網站嗎？谷歌搜尋找到了我的食物烹飪網站
抱歉，我意識到這個問題本質上很廣泛。但可以肯定的是，如果重複使用是 Chef 生態系統的目標，那麼明智地選擇最好的社群食譜來包裝是最終用戶成功的關鍵因素。除了使用 Chef 本身的任何技術技能之外。
你怎麼做呢？你的啟發是什麼？
github 上大量的 me-too 食譜讓我覺得這是不是一個已解決的問題。
答案1
就我個人而言，我先看超市的下載量，然後直接看github頁面。如果原始程式碼不在公共版本控制中，我就會繼續。
在查看程式碼時，我實際上只是快速瀏覽了一下，問自己以下問題：
a）這本食譜只做一件事
如果它是一本安裝應用程式的食譜，那麼這就是我想要的。我不希望它與系統的其他部分混在一起。 （例如：觸摸實體磁碟、ebs 磁碟區等...）
b) 如果我使用這本食譜，它可以擴展嗎
如果它是一本公開資源的圖書館食譜，我希望這些資源能夠對其使用的任何子資源提供足夠的控制。我無法忍受為狹窄用例建立模板的資源，但又不允許我充分修改模板來源或模板變數。
如果它是基於食譜的食譜，那麼我希望大多數相關位元都可以透過屬性進行配置。我並不完全介意包裝食譜，但如果我可以設置一些屬性而不是必須過多地包裝其他資源，我會非常高興。