一千萬個為什麽

搜索

配置管理工具



我是IT公司的員工,為許多客戶提供解決方案,大約有100個站點位於我們產品代碼的頂部,所有這些站點都在公司的DC中托管。

問題是,我們有一個很長的XML配置層次結構,用於每個站點設置不同的變量,以啟用/禁用功能,傳遞值以及其他許多用法,層次結構類似於頂級父級缺省值XML,然後是特定env中的站點的另一個XML,然後是站點本身(實際上比它長)。

我們已經定制了註冊表模塊來讀取這個配置和層次結構,每個站點使用該模塊查詢任何配置並通過XPATH傳遞目標功能並將其分配給變量,但問題在於配置越來越多大多數站點的最終配置集超過500個值,而不是提及任何XML更改都需要重新啟動產品以再次獲取配置,因為它們是在初始化時加載的。

我需要知道是否有其他人面臨這種​​情況,以了解是否有更好的解決方案來處理這個問題,因為XML樹現在非常復雜,我需要提出更好的解決方案,特別是DevOps團隊可以做這種頻繁的配置因為DC中不同env的XML文件是DevOps的責任。

是否有這種問題存在的工具?

如果不是,那麽我有一個想法。

我現在的想法是將配置分離為一組功能,每個功能都有自己的json對象和一組相關的值。將從產品代碼中取出註冊模塊並創建該站點從其配置中為每個功能讀取的nodejs API。該API將讓開發人員創建新的功能JSON配置並設置每個值的類型。 AM將看到開發人員創建的功能,並在那裏設置配置以啟用/禁用或分配任何其他值。

所以對於這麽好,但這是裏程碑式的變化,它在平臺級別,所以我需要知道:

有沒有經歷過這種情況,以及他們如何處理它?任何人都可以給我他對我上面提出的建議的看法嗎?

轉載註明原文: 配置管理工具

一共有 3 個回答:

這聽起來像你有一些嚴重的應用程序配置的架構問題。這聽起來像1)XML文件或SOAP請求是管理應用程序配置的一種可怕方式; 2)應用程序不是非常靈活,每次需要更改時都需要重新啟動,這是中斷性的。

使用JSON是管理應用程序配置的更好方式 - 尤其是如果此更改將允許在不使用REST API重新啟動的情況下動態更新配置。

您會發現配置管理工具無論使用哪種方式都需要一些集成編碼 - 用於Chef和Puppet的Ruby,或者用於SaltStack和Ansible的Python - 用於REST API調用。

盡管您可以使用Ansible這樣的軟件來管理XML文件,但這並不是實現這一目標的最佳方式,並且會讓您的應用程序帶來幾個問題。以所描述的方式重新構建您的應用程序絕對是正確的選擇。

如果現有的工具已經能夠執行此操作,請避免編寫自定義代碼。

我會選擇Ansible,因為它能夠輕松讀取和寫入json,yaml和xml,並且易於使用。

易用性是至關重要的,因為它可以讓您使用初級員工,否則您可能會面臨被超載的風險。

關於API等等......聽起來像是功能匍匐在我身上,這對於管理者來說很好銷售,但在實踐中從未被證明是行之有效的。

配置管理在GIT中保持得很好,使用審查過程訪問變更,並使用CI自動化來測試和應用它。

Config is a configuration file management tool that can help you. You will have the typical Dev, QA, Prod environments, and for your Prod environment, create 100 instances. You can start with the SaaS solution and you can grow into the on-premise setup. Config supports XML, JSON and other configuration file formats. It won't help your restart to reload issue, as that is something in your application you need to fix. I'm part of the team so feel free to ask questions.

您的開發人員可以訪問Dev環境,並且您的開發人員可以訪問所有環境。同步公共值和使用環境變量是所有核心功能。您有所有更改的歷史記錄,可以查看它們,並可以按版本或標記部署配置文件。是的,有一個部署步驟,類似於從Git中提取文件。