複数のサーバー構成ファイルにgitを使用する

多くのソースコードをgitに移行しており、現在のソリューションに非常に満足しています。サーバー構成ファイルを同じシステム上でバージョン管理したいと思いますが、希望どおりに動作しないものがいくつかありますので、ここで彼の経験を共有してください。

この質問は、サーバー構成ファイルのリビジョン管理の使用に似ていますか？、ただし、その質問に関する提案では機能しない特別な要件がいくつかあります。

現在のセットアップでは、構成ファイルにsubversionを使用しています。対応するリポジトリは次のようになります

 /＃リポジトリのルート
 +-www.domain.com/＃wwwの構成
 | \ - 等/
 | \-apache2 /
 +-dev.domain.com/＃devの構成
 | +-etc /
 | \-opt /
 | \-app1 /         
 | \-conf /＃devのapp1の構成
 \-staging.domain.com/＃ステージングの構成

Subversionでは、リポジトリのサブディレクトリをチェックアウトするだけでよいため、これは問題なく機能します。さらに、svn：externalsを使用して、いくつかの異なる構成セットアップの1つの共通構造を指すことができます。バージョン管理されたすべてのディレクトリにある.svnファイルのみを処理する必要がありました。一方、Gitにはsvn：externalsがなく、スパースチェックアウトでは常にルートから実際のディレクトリへのパスが同じである必要があります。

gitへの移行について議論するとき、サーバー構成のバージョン管理の主な要件を書き留めようとしました。

• 単一のリポジトリのみが必要です
• 変更を中央のリモートに簡単にプッシュできる必要があります
• 変更セットには実際の著者が含まれている必要があります

すべての構成を1つのリポジトリに配置し、作業コピーとしてサブパスのみを使用する良い方法はありますか？現在、私は2つのアプローチを検討していますが、最初にここでこの質問をしたかったです

1. 場合は.gitリポジトリが固定位置、例えば内のどこかにあるの/ var、我々は作業ディレクトリ「ターゲット」からサブパスにリンクすることも可能です。主な問題：単一のファイルのシンボリックリンクを除いて、コンテンツのみをインポートするために/ etcから別のディレクトリに「リンク」する方法を知りません
2. 私はこのSOの質問に別の選択肢を見つけ、1つのリポジトリに複数のブランチを置くことを提案しました。これにより確かに複雑さが増しますが、この方法を試してみることができます。

構成ファイルの管理に1台のマシンでgitを使用することは問題なく機能しますが、使用したい方法でgitを使用している人がいるはずです。

ありがとう
カリーム

以前にこのようなものを使用しました。これがどのように機能したかです。

リポジトリ設定

1. gitリポジトリ「etc_files」を作成します。
2. 「server / www」、「server / dev」など、マシンの種類ごとにブランチを作成します。
   • gitは、ブランチ名のスラッシュをサポートしています。これにより、枝を頭の中でまっすぐに保つことができます。
   • 十分な数のマシンがない場合は、代わりに個々のマシンごとにブランチを作成できます。
3. 「modules / apache」、「modules / cups」など、共有インフラストラクチャごとにブランチを作成します。
   • これらのブランチは、すべてのマシン間で同じファイルを保持するためのもの/etc/resolv.confです。これらは、現在「svn：externals」リポジトリに保持しているファイルになります。

新しいマシンの構築

1. 新しいマシンで、gitリポジトリのクローンを作成し、そのマシンタイプのブランチをチェックアウトします。
   • これを読み取り専用クローンにして、テストせずに本番マシンから変更をコミットしないようにします。
2. git pull毎日自動的にリポジトリを作成するようにcronジョブを設定します。

マシンブランチの変更

単一のマシンブランチでコードを変更するのは簡単です。git checkout開発環境の適切なブランチのみを変更し、変更を加えて、中央リポジトリにコミットします。そのブランチ内のすべてのマシンは、次にcronジョブが実行されるときに自動的に変更を取得します。

モジュールブランチの変更

モジュールブランチのコードを変更するのは、次の2つの手順を含むため、少しだけ注意が必要です。

1. git checkout 適切なモジュールブランチ
2. 変更を行い、それらを中央サーバーにコミットします。
3. git checkoutそのモジュールブランチを使用する各マシンブランチ、およびモジュールブランチをそれにマージします。gitは、そのモジュールブランチを以前にマージしたことを把握し、最後の共通の親以降に発生した変更のみに注目します。

この方法には利点と欠点の両方があります。利点の1つは、モジュールブランチに変更を加えて、それを必要とするマシンブランチに適用できることです。これにより、準備ができるまで古いバージョンにとどまらないマシンブランチが可能になります。欠点は、モジュールブランチを使用している可能性のある各マシンブランチに忘れずにマージする必要があることです。コミットツリーを走査し、自動的にこのマージを行うスクリプトを使用しますが、それでも面倒なことがあります。

代わりに、gitの新しいバージョンは「サブモジュール」と呼ばれるものをサポートします：

サブモジュールを使用すると、常に特定のコミットを指す、ソースツリーの専用サブディレクトリ内に外部リポジトリを埋め込むことができます。

これにより、「svn：externals」ツリーのようなものを少し構築できるようになります。これは、今とほぼ同じ方法で更新できます。

ここでは少しばかりですが、ポスト受信フックが仕事をする可能性があります

リポジトリマスターは/ var / masterに格納され
、フックは/ var / localcloneにクローン
を作成し、ホスト固有の詳細をコピーし
ます。各サーバーで.git / post-receiveフックをローカルに設定する必要があります（適切な設定で）

また、これはgitよりもpuppetやchefのようなものが欲しいようです。これにより、gitを実行して構成とモジュールを一元管理し、puppet \ chefで展開と検証を管理できます

ここに私が考えた簡単な作業があり
ます。1。に中央リポジトリ/var/repo
を用意します。2。そのディレクトリにすべてのドメインに対してグローバルなファイルを置きます。
すべてのサブドメインの枝を作成します。3. /var/repo/subdomain1、/var/repo/subdomain2など
のブランチへのプッシュがマスターにマージされた後のフックを作成します。4.。

そのため、設定を変更/var/repo/subdomain2するとすぐにマスターにマージされるため、レポジトリを完全にプルし、すべての設定ファイルを保持できます。
個々のサブドメイン設定をプルする場合は、適切なブランチをプルするだけです。

構成ファイルをどのように配置するか/var/repo/*はまったく別の問題です（cronタブ、私は考えることができます）

〜$