一千萬個為什麽

搜索

使用Chef進行多節點操作



我有一個應用程序,我想使用跨越多個節點的Chef進行配置。假設這樣做的過程包含

  1. 在節點A上捕獲輸出
  2. 使用該輸出在節點B上執行另一件事
  3. 現在返回節點A進行一些操作
  4. 現在再次在節點B上
  5. ...

一種方法是編寫一個配方,將每個節點上存放的舞臺存儲起來,然後在兩個節點上反復運行,直到最終有機會在所有節點上執行所有操作。但這是笨拙的,如果有節點C,D等,就不會擴展。我知道通知來對單個節點內的依賴關系進行排序,但這不適用於多個節點。我不能成為唯一需要這樣的人,那麽這種活動方式是否有機制或設計模式/最佳實踐/ TTP?

轉載註明原文: 使用Chef進行多節點操作

一共有 3 個回答:

總之,廚師可能不是在這裏使用的工具。

廚師是一個收斂模型,所以你必須以冪等的方式編寫你的食譜,例如在一些運行之後,根據周圍的其他節點,它將處於期望的狀態。

您關於存儲狀態的方法聽起來很順利,您必須使用外部協調器來安排A和B上的主廚客戶端運行。
如果你有一個廚師服務器,推送作業可能是繼續留在廚師生態系統中的一種方式,與其他協調員相比,我看到的主要優勢是不需要傳入管理端口和目標節點上的ssh的拉模式。

這是服務器編排的教科書示例,並且是廚師本質上不打算去做。正如Tensibai指出的那樣,一個運行Chef的服務器是一個融合系統,它根據配方,屬性,數據包等設置的配置設置實現自己想要的狀態。在沒有深入了解基礎設施的具體細節的情況下,您可能會采取一些方法能夠承擔的是:

創建獨立的冪等操作

正如您在您的問題中所述,創建一個操作狀態,您的節點可以重復運行,直到所有任務完成為止都不會很好地擴展。不過,重新設計節點可能無關緊要。如果節點a和b運行任務並行輸出其日誌,並且b在a之前完成,則它可以運行節點a通常運行的任務,反之亦然。

Use an external orchestrator for delegation

如果你打算有許多節點進行編排,使用委托節點肯定會好得多。但是,這可能會與您的廚師客戶端在由委托人管理的節點上運行產生沖突。驗證你的節點配置和委托節點任務不會相互沖突是非常困難的。一個聰明的方法來管理這可能是將任務合並到每個節點的配置中,並讓委托人在服務器的數據包或屬性中設置一個值,以指示應該如何配置自己(即,它需要執行哪些任務)。

結合您的基礎設施

如果每個節點根據其他節點順序運行任務,並且您不需要在不同節點上運行任務的成本/技術依賴性,則可能需要考慮將您的節點配置組合到一個節點中。這可以消除任何節點之間的配置沖突。我想在不同的節點上運行你的任務有明確的意圖,但這絕對是一個可以考慮的選擇(甚至可能會花時間重寫不同節點的任務)。

使用SaltStack編排您的廚師跑步。

Your cross-node orchestration logic goes here https://docs.saltstack.com/en/latest/topics/orchestrate/orchestrate_runner.html#more-complex-orchestration

And you can declaratively https://docs.saltstack.com/en/latest/ref/states/all/salt.states.chef.html

or imperatively https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.chef.html

將廚師節點驅動到所需的狀態。