Puppetを使用したマルチサイト高可用性のオプション

私は2つのデータセンターを維持しており、重要なインフラストラクチャの多くがパペットを介して制御され始めているため、プライマリサイトで障害が発生した場合、パペットマスターが2番目のサイトで動作することが重要です。

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

マルチサイトパペットの高可用性の標準的な方法はありますか？

Puppetは実際、マルチマスター環境に非常に適していますが、注意事項があります。主なものは？ Puppetの多くの部分は集中化するのが好きです。 認証局、インベントリおよびダッシュボード/レポートサービス、ファイルバケット、および保存された構成-これらはすべて、通話する場所が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. SRV3.0の新しいレコードサポートを使用して、すべてのエージェントノードが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

その後、主人のために必要な特別な本命は-ちょうどあなたに新しいレコードを追加しないSRVでRR _x-puppet._tcp.example.com、あなたしているセットは、グループ内のライブマスターです。さらに良いのは、マスター選択ロジックをより洗練されたものにすることです。SRVサイトごとに異なるレコードセットを設定することにより、「すべての古い作業マスターですが、サイト内のマスターを優先します」。dns_alt_names必要ありません。

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

これは一元化された最適な方法ですが、プライマリサイトがダウンしたときにそれなしで生きていれば問題ありません。すべてのマスターにレポートを配置する正しい場所を設定するだけです。

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

..そしてあなたはすべて設定されています。レポートのアップロードの失敗は、構成の実行にとって致命的ではありません。ダッシュボードサーバーのトーストがあれば失われます。

事実目録

ダッシュボードに貼り付けたもう1つの良い点は、インベントリサービスです。facts_terminusセットrest中央インベントリサービスがダウンしたときにドキュメントで推奨されているように、これは実際にコンフィギュレーションの実行を破りますよ。ここでのコツはinventory_service、非中央マスターで終端を使用することです。これにより、正常な障害が可能になります。

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

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

ですから、CAを使用して新しいノードの証明書に署名することさえできず、復元されるまではかなりベアボーンな構成管理環境に問題がなければ、これはうまく機能します-それは本当にいいことですがこれらのコンポーネントのいくつかが分配されるのに少しより友好的であったなら。

ラダダダダが説明する「マスターレスパペット」アプローチは、私が最もよく知っているアプローチです（基本的には、私たちの会社でradmindを使ってやっていることです）。より正確に言うと、「外部プロセスによって同期された複数のマスター」であり、特定のサーバーが（理論上）緊急時に全宇宙にサービスを提供できます。

なぜならradmindの自然の我々の場合では、単にrsync各リモートサイトのradmindサーバへの承認マスターからの転写産物とデータファイルは、クライアントは短いホスト名を持つサーバから更新を引っ張るradmindの魔法を通じて（resolv.confこの評価さradmind.[sitename].mycompany.com常にローカル- radmindサーバー：ローカルサーバーがダウンしている場合は、他のサイトのサーバーをオーバーライドしてポイントするのは簡単です。

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

人形やシェフの場合、バージョン管理ベースのシステムは、いくつかの理由で単純なrsyncよりも意味があります。大きな理由は、人形スクリプト（radmindのようにOSイメージ全体ではなく）をバージョン管理していることです。
バージョン管理ベースの管理の追加の利点として、一度に複数の人がリポジトリで作業できるようになり（並列処理に大きなメリットがあります）、本質的に無料で変更履歴を取得でき、誰かがPuppet環境を壊した場合、簡単にロールバックできます（あなたがgitあなたが再使用することは、git blameそれが錫で言うことをするものも持っています）。
クリエイティブな分岐とマージにより、バージョン管理フレームワーク内での主要なOSのアップグレードやその他の移行を処理することもできます。いったん正しくなったら、新しいブランチに切り替えるだけで（できれば）本番プッシュが機能します。

ここでこれを実装していた場合、おそらくgitの事前コミットフックと事後コミットフックを利用して、コミットされるパペット設定が正常（クライアント側の事前）であることを確認し、それらが他のユニバースにプッシュされるようにしますare（サーバー側の投稿-展開ポリシーでそのような動作が許可されている場合は、環境の更新もトリガーされる可能性があります）。

各サイトで新しいpuppetmasterサーバーを起動するという点では、各リモートpuppetmasterにpuppet環境をチェックアウトし、上記のresolv.conf / hostname hackeryを使用するか、Michuelnikが提案するようなローカルシステムにリダイレクトされるエニーキャストサービスIPを使用できます（後者は、あるサイトのパペットマスターが破裂した場合に自動フェイルオーバーが必要な場合に便利です。各サイトが「正しい」パペットマスターを確認し、更新を取得しようとしてWANリンクを詰まらせないように処理します。

Brain Tree Paymentsの人々は明らかに、バージョン管理とrsyncソリューションをいくつかのカスタムCapistranoタスクと組み合わせています -彼らのソリューションは手動のワークフロー要素に依拠しているという意味で中途半端なようですが、それなしで適応および自動化できます働き過ぎ。
私の妄想強迫テスターは、noop健全性チェックのステップが好きです-私の手動プロセスの嫌いは、その周りのある程度の自動化を望みます...