分散パペットアーキテクチャの長所と短所

現在、Puppetmasterサーバーに接続している約300のRHELサーバーがあります。ただし、パフォーマンスのボトルネックに気づき、システムの障害点になります。私は一般的にパペットにかなり慣れていないので、PuppetクライアントをPuppetmasterサーバーに接続する代わりに、分散パペットアーキテクチャの作成を検討しています。パフォーマンスの向上や、新しいマシンのSSL証明書への署名と交換の欠如など、私が起こると思われることとは別に、分散アーキテクチャをセットアップすることの長所と短所は何ですか？

分散化してください。

証明書に署名する代わりに、sshキーを作成します。非管理者にキーを渡さないでください

Subversionの代わりにGitをトランスポートとして使用し、さまざまなマシン/ロールに分岐して、変更をバージョン管理し、...を許可することができますが、この時点でDVCSのスピルを知っている必要があります。

それはより速く、セットアップするのがより面倒ではありません。健全性チェック用のいくつかのコミットフックを追加します。

さて、この時点で、puppetmasterを、そのクライアントサーバーモデル、sshとgitで置き換えました。どちらもpuppetmasterよりも優れています。

現在、組織には階層が必要な場合があります。問題ありません。決定的なブランチを含むgitリポジトリを安全な場所に保存するだけです。

ボーナス：

git blame

誰が変更を行ったかを確認できます。

http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control

https://www.braintreepayments.com/braintrust/decentralize-your-devops-with-masterless-puppet-and-supply-drop？

パッセンジャーでパペットを実行していますか？構成の保存？基本的なセットアップの問題を処理する限り、300ノードのスケーラビリティの問題はまったくありません。

分散化は、各クライアントがマニフェストソースのローカルコピーから独自のマニフェストをコンパイルするための最善の方法です。これは、say gitサーバーから更新をプッシュするたびに更新されます。クライアントが実行のたびにパペットマスターに連絡する必要がないので、帯域幅のはるかに効率的な使用。また、クライアントはどこからでも更新できるため、単一障害点がなくなります。