gitを使用して/ etcを管理していますか？
/etcがリモートgitリポジトリで追跡されているシステムについて考えています。私はgitワークフローについて考えています。そこでは、すべてのホストマシンが異なるブランチを持っています。
すべてのマシンの以前のすべてのバージョンを簡単に追跡、比較、マージできます。
/etcの変更を多くのマシンでコミットする必要がある場合、マージスクリプトによって簡単に行うことができます。
「不要な」/etc変更の場合、これはよく見える可能性があります（それを監視するようにアラームスクリプトを調整することもできます）。
誰かがすでにそのような構成を使用していますか？セキュリティ上の問題はありますか？
プログラムetckeeperはgitの/etcを管理します。デフォルトのvcsバックエンドをbzrからgitに変更するだけで、/etc/etckeeper/etckeeper.conf。
Ubuntu Linuxにデフォルトでインストールされ、自動的にコミットする一般的なケースを処理します。
コミットされていない手動の変更がある場合に備えて、パッケージをインストールする前、およびインストール後にコミットします。
git内の/etcの追跡構成の問題は、バージョン管理のみで実現できることです（ほとんどのgit初心者はtagとbranchは正しく、その時点ではほとんどありません）およびロールバックする機能（ここでも、taggingが適切でない場合は、人々を非難するためのログしか得られません。 ）;しかし、テンプレート（gitが提供していないため、テンプレートを傾斜できない）、およびスケールアウト（Elasticsearchなどの分散データベースを使用している場合は特に、構成を他の場所に適用することはできません）、および自動システム管理（これもgitはこれを提供しません）を失う）。
そうは言っても、おそらく探しているのは 構成管理 ;です。 templating 、git、および構成を管理するための基本的なスクリプトを結び付けます。もちろん、これはDevOpsと コードとしてのインフラストラクチャ の方向に向かっています。
これに追加するには; Ansibleにはansible-pullがあり、gitからプレイブックの最新のリポジトリを取得できます。同じことがシェフにも言えます。基本的に、最近のLinux管理者はetckeeperのようなものを使用すべきではありません。 Chefには、クライアントサーバーモードもあり、environment、roles、クックブックのバージョンに基づいて、chef-clientですべてのシステムを管理できます。 gitで単独で大規模に行うことはできません。