☰

Puppet によるマルチサイト高可用性のオプション

tag-icon • tag-icon puppet high-availability
Puppet によるマルチサイト高可用性のオプション

私は 2 つのデータセンターを管理していますが、重要なインフラストラクチャの多くが Puppet 経由で制御されるようになると、プライマリ サイトに障害が発生した場合に 2 番目のサイトで Puppet マスターが機能することが重要になります。

さらに良いのは、2 番目のサイトのサーバーが WAN 経由でポーリングしないように、アクティブ/アクティブ セットアップのようなものを用意することです。

マルチサイト Puppet の高可用性を実現する標準的な方法はありますか?

答え1

Puppet は実際にはマルチマスター環境に非常に適していますが、いくつか注意点があります。主な注意点は何でしょうか? Puppet の多くの部分は集中化されることを好みます。 証明機関、インベントリおよびダッシュボード/レポート サービス、ファイルバケット、保存された構成など、これらすべては、通信する場所が 1 つだけあるセットアップで最も効果を発揮します (または、単に 1 つの場所だけが必要なセットアップです)。

ただし、プライマリ サイトが失われたときに一部の機能が失われても問題ない場合は、これらの可動部分の多くをマルチマスター環境で動作させることは十分に可能です。

まず、ノードがマスターにレポートするための基本機能から始めましょう。

モジュールとマニフェスト

この部分は簡単です。バージョン管理を行います。分散バージョン管理システムの場合は、集中管理して同期し、必要に応じてフェイルオーバー サイトでプッシュ/プル フローを変更します。Subversion の場合は、フェイルsvnsyncオーバー サイトにリポジトリを配置する必要があるでしょう。

証明する機関

ここでの 1 つのオプションは、マスター間で証明機関ファイルを単純に同期し、すべてが同じルート証明書を共有して証明書に署名できるようにすることです。これは、常に「間違ったやり方」のように思われてきました。

  • あるマスターは、別のマスターからの着信接続のクライアント認証で提示された自身の証明書を本当に有効と見なすべきでしょうか?
  • それは在庫サービスやダッシュボードなどで確実に機能しますか?
  • 将来的に有効な DNS 代替名を追加するにはどうすればよいでしょうか?

正直言って、このオプションはひどいので、徹底的にテストしたとは言えません。しかし、Puppet Labsはこのオプションを推奨するつもりはないようです。ここ。

したがって、残るのは中央 CA マスターです。すべてのクライアントと他のマスターが CA 証明書と CRL をキャッシュするため (CRL は必要な頻度で更新されませんが)、CA がダウンしてもすべての信頼関係は機能し続けます。ただし、プライマリ サイトを復旧するか、フェールオーバー サイトでバックアップから CA マスターを復元するまで、新しい証明書に署名することはできません。

CA として機能するマスターを 1 つ選択し、他のすべてのマスターではそれを無効にします。

[main]
    ca_server = puppet-ca.example.com
[master]
    ca = false

次に、証明書に関連するすべてのトラフィックをその中央システムで取得する必要があります。これにはいくつかのオプションがあります。

  1. 3.0の新しいSRVレコードサポートを使用して、すべてのエージェントノードをCAの適切な場所にポイントします。_x-puppet-ca._tcp.example.com
  2. すべてのエージェントca_serverの で設定オプションを設定しますpuppet.conf

  3. エージェントからの CA 関連リクエストのすべてのトラフィックを適切なマスターにプロキシします。たとえば、すべてのマスターを Passenger 経由で Apache で実行している場合は、非 CA でこれを設定します。

    SSLProxyEngine On
# Proxy on to the CA.
ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
# Caveat: /certificate_revocation_list requires authentication by default,
# which will be lost when proxying. You'll want to alter your CA's auth.conf
# to allow those requests from any device; the CRL isn't sensitive.

そして、それで完了です。

付帯サービスに移る前に、補足事項があります。

マスター証明書の DNS 名

これが 3.0 に移行する最も説得力のある理由だと思います。たとえば、ノードを「任意の作業マスター」にポイントするとします。

2.7 では、 のような汎用 DNS 名が必要でpuppet.example.com、すべてのマスターの証明書にこれが必要です。つまり、dns_alt_names構成で設定し、マスターとして構成される前に持っていた証明書を再発行し、リストに新しい DNS 名を追加する必要があるときに証明書を再度再発行する必要があります (複数の DNS 名を使用してエージェントがサイトでマスターを優先するようにしたい場合など)。これは面倒です。

3.0 では、レコードを使用できますSRV。すべてのクライアントにこれを提供してください。

[main]
    use_srv_records = true
    srv_domain = example.com

その後、マスターに特別な証明書は必要ありません。RR に新しいレコードを追加するだけSRVで、グループ内のライブ マスターとして設定できます。さらに良いことに、マスター選択ロジックを簡単により洗練されたものにすることができます。つまり、異なるサイトに対して_x-puppet._tcp.example.com異なるレコード セットを設定することで、「どの古い作業マスターでも構いませんが、自分のサイトにあるマスターを優先します」というロジックです。必要ありません。SRVdns_alt_names

レポート / ダッシュボード

これは集中管理すると最も効果的ですが、プライマリ サイトがダウンしたときにこれがなくても問題ない場合は問題ありません。すべてのマスターを、レポートを配置する適切な場所に構成するだけです。

[master]
    reports = http
    reporturl = https://puppetdash.example.com/reports/upload

..これで準備完了です。レポートのアップロードに失敗しても、構成の実行には致命的ではありません。ダッシュボード サーバーの TOAST でレポートが失われるだけです。

事実の目録

ダッシュボードに組み込むと便利なもう 1 つの機能は、インベントリ サービスです。ドキュメントで推奨されているようfacts_terminusに設定するrestと、中央インベントリ サービスがダウンしたときに構成の実行が実際に中断されます。ここでの秘訣は、inventory_service非中央マスターでターミナスを使用することです。これにより、正常な障害処理が可能になります。

facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140

中央インベントリ サーバーを ActiveRecord または PuppetDB のいずれかを使用してインベントリ データを保存するように設定し、サービスが利用可能なときは常に最新の状態に維持する必要があります。

したがって、復元されるまで新しいノードの証明書に署名するためにCAを使用することさえできない、非常に基本的な構成管理環境であっても問題ない場合は、これで問題なく動作します。ただし、これらのコンポーネントの一部が配布に少し親しみやすい。

答え2

Ladadadada が説明している「マスターレス パペット」アプローチは、私が最もよく知っているアプローチです (これは基本的に、私の会社で radmind を使用して行っていることです)。より正確には、これは「外部プロセスによって同期された複数のマスター」であり、任意のサーバーが (理論上) 緊急時に宇宙全体にサービスを提供できるものだと思います。

私たちの場合、radmind の性質上、rsync承認されたマスターからのトランスクリプトとデータ ファイルを各リモート サイトの radmind サーバーに単純に送信し、クライアントは短いホスト名を持つサーバーから更新を取得しますradmind(resolv.confこの評価結果はradmind.[sitename].mycompany.com常にローカルの radmind サーバーに送られます。ローカル サーバーがダウンしている場合は、オーバーライドして他のサイトのサーバーを指定するのは簡単です)。

この種の rsync プロセスはおそらくあなたの状況でも機能しますが、バージョン管理ベースのソリューションと比較すると最適ではない可能性があります。

Puppet または Chef の場合、バージョン管理ベースのシステムは、いくつかの理由から単純な rsync よりも理にかなっています。大きな理由は、バージョン管理が Puppet スクリプトに対して行われることです (radmind のように OS イメージ全体に対して行われるのではありません)。
バージョン管理ベースの管理の追加の利点として、複数の人が同時にリポジトリで作業できること (並列処理の大きな利点)、基本的に無料でリビジョン履歴を取得できること、誰かが Puppet 環境を壊した場合に簡単にロールバックできること (パッケージに記載されているとおりの機能をgit果たす も使用している場合) などがあります。 クリエイティブなブランチとマージにより、バージョン管理フレームワーク内で主要な OS アップグレードやその他の移行を処理することもできます。いったん正しく実行したら、新しいブランチに切り替えるだけで、(うまくいけば) 本番環境へのプッシュが問題なく機能します。git blame

ここでこれを実装する場合、おそらく Git の pre-commit フックと post-commit フックを利用して、コミットされる Puppet 構成が正常であることを確認し (クライアント側の pre)、正常であればそれを他の場所にプッシュします (サーバー側の post - デプロイメント ポリシーでそのような動作が許可されている場合は、環境の更新もトリガーされる可能性があります)。

各サイトで新しい puppetmaster サーバーを起動するには、各リモート puppetmaster に puppet 環境をチェックアウトし、上で説明した resolv.conf/hostname ハッキング、または Michuelnik が提案したようにローカル システムにリダイレクトされる anycast サービス IP (後者は、1 つのサイトの puppetmaster がクラッシュした場合に自動フェイルオーバーが必要な場合に便利です) を使用して、各サイトが「正しい」 puppetmaster を認識し、更新を取得しようとして WAN リンクが詰まらないようにします。

ブレインツリーペイメントのスタッフバージョン管理とrsyncソリューションを組み合わせたようですいくつかのカスタム Capistrano タスクとともに、彼らのソリューションは、まだ手動のワークフロー要素に依存しているという意味で中途半端に思えますが、あまり手間をかけずに適応および自動化できます。
私の中に潜む偏執的な強迫観念的なテスターは、彼らの健全性チェックのステップに愛着を感じますnoop。私の中に潜む手動プロセス嫌いは、その周りである程度自動化されることを望んでいます...

関連情報