2

CentOS6.2 マシンの OpenStack クラスターでプロジェクトを実行しています。プロジェクトは約 10 個の git リポジトリで構成されています。サービスの 1 つのリポジトリ。サービスは、いくつかの役割に基づいて 20 の異なるノードで実行されています。したがって、サービスとロールの間である種のマッピングを行うことができます。手動で行っている場合、クラスターを介して変更を配信するのは面倒です。現在、各ノードでいくつかの構成変更と組み合わせて git pull を使用しています。人的要因が関与しているため、手動エラーのためにクラスターをオフラインにしたくありません。

ソースを更新した後に何かを構成する機能を備えたクラスターに変更を配信するソリューションを探しています (db migration または構成ファイルの更新を実行します)。それに関する良い解決策はありますか？

更新: 以下のプロジェクトは適合するようです。これらの実際の経験はありますか？

4

3 に答える 3

1

Springloops を使用してデプロイを管理しています。各リポジトリのブランチごとに異なるサーバーを構成できます。中央リポジトリにプッシュし、そこから展開を管理するだけです。展開は自動または手動で行うことができます。

カスタム コールバックの実行がサポートされているため、カスタム スクリプトをトリガーできるプッシュが行われたという通知を受け入れる URL エンドポイントをクラスター内のどこかに設定できます (プロジェクトごとに設定できます)。

サーバーからソース管理の責任を負うため、これはうまく機能します。新しいサーバーへの新しい展開が必要な場合、git リポジトリを複製するのではなく、Springloops に新しいサーバーを追加してプッシュするのは非常に簡単です。新しいサーバーごとに、いくつかの cron またはトリガーされたタスクを構成して、レポを更新します。

コマンド ライン ツールとサード パーティのマネージド サービスの組み合わせは他にも多数考えられますが、いくつか試してみましたが、Springloops は、現在取り組んでいる数十のプロジェクトの展開を管理するのに十分です。

調べる価値があります。

于 2012-03-24T07:29:38.370 に答える
0

あなたが取り組んでいる規模では、chefまたはのようなものをうまく利用できるかもしれませんpuppet。

于 2012-03-24T07:23:36.720 に答える
0

これらのプロジェクトはより適しているようです:

現在、構成ストレージ \ マスター選出メカニズムとしてFabricスクリプトを考えています。Dozzerd

于 2012-03-24T18:46:18.073 に答える