私は、システム構成ファイルをバージョン管理し、2 台のマシン (ライブとバックアップ、両方とも「本番」とみなす) 間のデプロイメント (所有権とモード) を管理するための最適な方法 (私の目的と状況に適した方法) を探しています。このシステムを使用して、バックアップ マシン (EC2 インスタンス) 上の関連する指定された構成を自動的に (ただし選択的に) 複製して管理できるようにしたいと考えています。
現在、これらのマシンは主に Web サーバーと SMTP サーバーとして使用されています (ユーザーのメールボックスは保存していません)。しかし、プロジェクトは成長しており、将来どのような要件が課されるかは誰にもわかりません。たとえば、将来的にはラジオや Web ベースのチャットを実装する可能性があります。
私は、サーバーを従来の方法で管理し（つまり、必要に応じてライブサーバーに変更を加え）、その変更を（確定したら）管理システムに保存することを好みます。（正直に言うと、有機的に: ニーズや状況に応じて柔軟に対応できる能力を失いたくありません。) 他の場所で調整およびテストされた構成を展開するよりも、このアプローチの方が予測可能で、予期せぬ事態も少なくなると思います (ライブ システムで構成を台無しにする可能性は別として)。
哲学的に言えば、これは逆であり、リソース (テスト インフラと、さらに重要な人材) があれば、おそらく逆のことをするだろうと認識しています。現状では、手元にあるもので間に合わせるしかありません。構造は十分に気に入っていますが、過剰なインフラは独り歩きし、ある時点でその価値が失われます。
下調べをして、いくつかのオプションを検討しましたが、どれも私が望んでいることを本当に実現してくれないようなので、現在は独自のソリューションを作ろうと考えています。この質問の目的は、私が考えていなかったことを調べ、間違った方向に進んでしまう前に妥当性をチェックすることです。
オプション
Puppetのような宣言型メタ構成システム、とりわけは、多くのサーバーが関係し、それらのサーバー間の区別がほとんどまたはまったくない場合、特に構成がどのようなものになるかが事前に明らかな場合には、おそらく良い選択です。ステージング インフラストラクチャなしでこのようなツールを使用するのは賢明ではないと思います。
また、これは少し重くて複雑すぎます。私は唯一の管理者であり、空き時間にこれを行っています。私に何かが起こった場合、私が残すものは、私の後を継ぐ幸運な男性/女性にとって、かなり理にかなったものでなければなりません。
etckeeperはおそらく使えるだろうが、私が見た限りでは、/etc以外のものを管理するのにはあまり向いていない。つまり、伝統的に/usr/local/binにあるカスタムスクリプトを保存するのには適していない。また、etckeeperはおそらく以下を管理できる。全て/etc では、特定のもの (例: postfix、apache、fail2ban、ssh、場合によっては munin) のみをバージョン管理したいと考えます。
単純な git または svn リポジトリでは確かに不十分です。git は権限を追跡しますが、所有権は追跡せず、svn はどちらも追跡しません。
svn は、
.svn追跡されているすべてのディレクトリにサブディレクトリを保持しますが、 は.git作業コピーのルート ディレクトリにのみ存在します。どちらの場合も、利点と欠点があります。.svn特定の場所にディレクトリが存在することは、一部の場所 (例: /etc/apache2/sites-enabled) では問題ないかもしれませんが、他の場所では機能しないスクリプトやツールを混乱させる可能性があります。(以前何か読んだことがあるのですが、cron は.svn/etc/cron.d 内のディレクトリでは問題ないが、depmod は /lib/modules では問題ない、というものでした。)一方、
.git/内の場合、gitはすべて追跡の候補、さらには（おそらく）他の Git リポジトリも追跡できます。
カスタムソリューション
私が提案するのは、プライマリマシン（/usr/local/sc-repoなど）に保存されたSubversionリポジトリと、ピスヴン以下を実装します。
追加します (ただし、デフォルトでは再帰的ではありません)。これにより、ファイルのモードと所有権がカスタム プロパティとして保存されます。また、私は
$Id$設定ファイルにタグを付けたいので、これにより適切に設定されるようになりますsvn:keywords。専念
更新は、ファイルが書き込まれた後に所有権とモードを適用します。
元に戻す、同上
権限は diff と同様ですが、所有権とモード用で、必要に応じて修正するための修正フラグが付いています。
バックアップ マシンは、ssh 経由でリポジトリにアクセスし、毎晩更新操作を実行します。(メイン マシンのバックアップ リポジトリ (S3) からサイトの SQL とアプリケーション ファイル システムを復元するなどの他の操作も実行します。また、メイン マシンに追加された新しいパッケージを探してバックアップ マシンに追加するハッキングを記述する必要がある可能性もありますが、これらはすべてこの質問の範囲外です。)
なぜ転覆なのか?
私は知っている、好きだ、そして多くの私は git よりも svn に詳しいです。はい、私はおそらく恐竜です。
Pysvn は簡単で、以前にも使用したことがあります。
svnはバージョン管理されたカスタムプロパティをサポートしていますが、gitはサポートしていないようです
これは分散開発ではありません。分散リポジトリは、メリットなく問題を複雑にします。リモート マシンからのコミットはまれなので、リモート リポジトリの可用性は無関係です。
フィードバックをいただければ幸いです。私はこの件についてできる限り考えましたが、何か見落としていることがあるはずです。
答え1
車輪の再発明はしないでください。必要なことを行うためのツールが存在します。bcg2 さん特に、構成ファイルに重点を置かれているようです。サービスについても考えてみましょう。運用サーバーとの関係で、中央リポジトリはどこに置く必要がありますか?
中間的な選択肢としては、出力を慎重に変更することが考えられます。青写真ツール。私は既存のシステムをリバースエンジニアリングするためにブループリントを使用しています。ブループリントの実行の出力は、シェルスクリプト、Puppet モジュール、または Chef クックブックを作成できます...実稼働サーバーで検証済みの構成ができたら、このツールを使用してシステムの状態をキャプチャし、結果にタグを付けてバージョンを付けることができます。例を通してこれがあなたのユースケースに適合していると思われる場合は、報告してください。
答え2
Puppet のような宣言型メタ構成システムは、多数のサーバーが関係し、それらのサーバー間の区別がほとんどまたはまったくない場合、特に構成がどのようなものであるべきかが事前に明らかな場合には、おそらく良い選択です。ステージング インフラストラクチャなしでこのようなツールを使用するのは賢明ではないと思います。
私は Puppet を使用しています (ただし、Chef、Ansible、Salt なども存在します)。マシンを 1 台だけセットアップする場合も、事前にマシン構成がどうなっているかが明確にわかっている状況にはまだ遭遇していません (おそらく、後になってから構成がどうなっているかが明確でない人も多いでしょうが、これはまったく別の問題です)。
「ステージングインフラ」については、浮浪者そしてバーチャルボックス（または他の仮想化技術） - 開発マシンで実行して、費用を一切かけずに実行します。私はこれなしでPuppetマニフェストの開発は行いません。また、自動化されたテストもトラビスCI
また、これは少し重くて複雑すぎます。私は唯一の管理者であり、空き時間にこれを行っています。私に何かが起こった場合、私が残すものは、私の後を継ぐ幸運な男性/女性にとって、かなり理にかなったものでなければなりません。
これを言った後に、豊富なドキュメント、例、既存の「ライブラリ」、活発な開発を伴う既存のソリューションではなく、自社開発のソリューションを計画していることを説明するのは、矛盾しているように思われます。