Linux系統設定管理：版本控制與部署

Question

我正在尋找最好的方法（針對我的目的和情況）來對系統設定檔進行版本控制並管理兩台機器（即時和備份，兩者都應被視為「生產」）之間的部署（所有權和模式）。我希望能夠使用該系統自動（但選擇性地）複製和管理備份電腦（EC2 實例）上的相關和指定配置。

目前，這些機器主要是 Web 和 SMTP 伺服器（我們不儲存使用者郵箱），但我們的專案正在成長，誰知道未來的需求可能是什麼。例如，我們有可能在未來的某個時候實現廣播和基於網路的聊天。

我更喜歡以傳統方式管理伺服器（即，根據需要進入即時伺服器並進行更改），然後將這些變更（一旦解決）儲存在管理系統中。 （好吧，如果我誠實的話，我應該說有機地：我不想失去根據需要和情況要求做事的靈活性。配置的可能性就是這樣！

我意識到，從哲學上講，這是從後到前的，如果我有資源（測試基礎設施，更重要的是，人力），我可能會以相反的方式來做。事實上，我必須用我所擁有的東西來湊合。我非常喜歡結構，但是過多的基礎設施會自行消失，並且在某些時候它的價值就會消失。

我已經做了一些作業並審查了幾個選項，但它們似乎都沒有真正達到我想要的效果，所以我目前很想推出自己的解決方案。這個問題的目的是看看我沒有想到什麼，並在我胡思亂想之前進行健全性檢查。

選項

1. 聲明性元配置系統，例如 Puppet，除其他外，可能是不錯的選擇，其中涉及許多伺服器，它們之間幾乎沒有或沒有區別，特別是當提前明確配置應該是什麼樣子時。我認為在沒有臨時基礎設施的情況下使用這樣的工具是不明智的。

   它也有點重且過於複雜。我是唯一的管理員，我在業餘時間做這件事，如果我發生什麼事，無論我留下什麼，對於在我之後介入的幸運男孩/女孩來說都需要相當理智。

2. etckeeper 可能可以，但據我所知，它並不真正適合管理 /etc 之外的任何內容。即，它不適合儲存傳統上位於 /usr/local/bin 中的自訂腳本。另外，etckeeper 大概管理全部/etc，我想我更願意只對特定的東西進行版本控制（例如 postfix、apache、fail2ban、ssh 和可能的 munin）。

3. 一個簡單的 git 或 svn repo 肯定不行，因為雖然 git 追蹤權限，但它不追蹤所有權，而 svn 也不追蹤。

   svn.svn在每個追蹤目錄中保留一個子目錄，而.git僅存在於工作副本的根目錄中。這兩種情況都有優點和缺點。.svn某個位置中存在的目錄在某些地方可能沒問題（例如 /etc/apache2/sites-enabled），但在其他地方會擾亂腦死亡腳本/工具。 （我確信我不久前讀過一些東西：cron 是否可以使用.svn/etc/cron.d 中的目錄，但 depmod 不能使用 /lib/modules ？）

   另一方面，對於.gitin /，git 認為一切追蹤的候選者，甚至（大概）其他 git 儲存庫！

客製化解決方案

這是我建議要做的：儲存在主電腦上的 subversion 儲存庫（例如 /usr/local/sc-repo）和編寫的管理腳本pysvn實現以下內容：

• add（但預設不是遞歸），它將檔案的模式和所有權儲存為自訂屬性。另外，我喜歡$Id$設定檔中的標籤，因此這將確保svn:keywords正確設定。

• 犯罪

• 更新，在檔案寫入後套用所有權和模式

• 恢復，同上

• 權限，與 diff 類似，但針對所有權和模式，如果需要，可以使用修復標誌進行更正。

備份機將透過ssh存取repo並每晚執行一次更新作業。 （它也會做其他事情，例如從主機的備份儲存庫（S3）恢復網站 SQL 和應用程式檔案系統，我可能需要編寫一些駭客技術來查找主機上新增的新套件並將它們新增至主機上備份機——但所有這些都超出了本問題的範圍。

為何顛覆？

• 我知道，喜歡並且是很多我對 svn 比對 git 更熟悉。是的，我可能是一隻恐龍。

• Pysvn 很簡單，我以前用過。

• svn 支援版本化的自訂屬性，而 git 似乎不支持

• 這不是分散式開發：分散式儲存庫使事情變得複雜而沒有任何好處。遠端儲存庫的可用性是無關緊要的，因為來自遠端電腦的提交很少。

我將不勝感激您的回饋。我已經盡可能地思考了這一點，但我肯定錯過了一些東西。

Answer 1

不要重新發明輪子。這些工具的存在可以滿足您的需求。您可能想看看BCFG2，特別是因為您似乎特別關注配置文件。還要考慮一下服務。中央儲存庫需要與生產伺服器相關聯在哪裡？

也許中間選項可以是仔細修改輸出藍圖工具。我使用藍圖對現有系統進行逆向工程。藍圖運行的輸出可以建立shell 腳本、Puppet 模組或Chef Cookbook...一旦您在生產伺服器上獲得了經過驗證的配置，您就可以使用此工具來捕獲系統的狀態，然後對結果進行標記和版本控制。讀透過例子並報告這是否適合您的用例。

Answer 2

尤其是，像 Puppet 這樣的聲明性元配置系統可能是不錯的選擇，其中涉及許多伺服器，它們之間幾乎沒有或沒有區別，特別是當提前明確配置應該是什麼樣子時。我認為在沒有臨時基礎設施的情況下使用這樣的工具是不明智的。

即使對於單機設置，我也使用 Puppet（但是，Chef、Ansible 和 Salt 等都存在）。我還沒有遇到這樣的情況：任何人都提前清楚機器配置應該是什麼樣子（可以說，很多人事後都不清楚配置應該是什麼樣子，但這完全是一個不同的問題）

至於“分階段基礎設施”，那就是流浪漢和虛擬盒子（或其他一些支援虛擬化技術） - 在您的開發機器上運行它以實現零支出。如果沒有它，我不會進行任何 Puppet 清單開發。還可以進行自動化測試崔維斯·西爾

它也有點重且過於複雜。我是唯一的管理員，我在業餘時間做這件事，如果我發生什麼事，無論我留下什麼，對於在我之後介入的幸運男孩/女孩來說都需要相當理智。

這麼說，然後描述如何規劃一個本地解決方案，而不是具有大量文件、範例、現有「庫」和積極開發的現有解決方案，這似乎不一致。