3

私たちは puppet/Hiera を使用して 20 台のサーバーを管理する 2 人のチームです。これまで、マニフェストの開発中に VCS を使用したことはありません。

puppetmaster でリモート Git リポジトリを構成し、マニフェストとモジュール フォルダーを master ブランチ (開発に使用) にプッシュし、同一の production ブランチをプッシュしました。リモートリポジトリには、ブランチ名 (または存在する場合は更新) に基づいて新しい環境を構成するリリース後のフックがあり、puppetmaster にはこれが機能するように構成された動的環境があります。この設定については、パペット ブログで詳しく説明されています。

私たちのワークフローは、各自がローカル マスター ブランチで開発するためのものです。テストの準備が整ったら、コミットしてからプッシュし、リリース後のフックで開発環境を更新します。次に、puppetd --test --environment development. すべてが期待どおりに機能する場合、どちらかが開発ブランチを本番環境にマージし、本番環境を再度更新するプッシュを行うことができます。

質問

  1. これは Git と Puppet を使用するための最適なワークフローですか?
  2. 開発環境を実際にテストする方法。使用できる予備のサーバーがありますが、ノード宣言で指定された本番サーバーと同じホスト名でそれらを構成しますか? これを行うと、IP アドレスなどの Hiera からのノード固有のデータが正しくなくなります。それとも、実稼働サーバーで --environment 開発スイッチを使用して --noop を使用してテストしますか?

アドバイスをいただければ幸いです。

4

2 に答える 2

1

実行したいことの1つは、ステージングVMを使用することです。変更をプッシュする前に、VMでテストして、すべてが正常に機能するかどうかをテストしてから、変更をプッシュします。

puppetでのVCSの使用は、コードでの使用とは少し異なります。時々あなたのプッシュは、いわば「ビルドを壊すかもしれない」。したがって、Gitタグを使用して、すべてが正常に機能したコミットを記述します。これにより、「悪い」コミットの1つに戻らないようにすることができます。

于 2012-08-22T14:41:02.693 に答える