構成管理ツールのフェイルオーバー動作
私は現在、「DevOps」を管理者に販売しようとしています。調査していることの1つは、構成管理ツールです。私たちにとって重要なことの1つは、高可用性と優れたフェイルオーバー動作を備えたシステムがあることです。
- CF-Engineの場合、これは問題ではありません。すべてのノードをサーバーとして実行するように構成でき、サーバーが使用できない場合でも実行が続行されるためです。
- Puppetの場合、マスター/マスターレスモードとその長所と短所を選択できます。
- Chefの場合、最初の実行ではマスターサーバーがポリシーをフェッチする必要がありますが、その後、マスターが使用できない場合、実行はその現在のポリシーで続行されます。
- Saltの場合、マスターサーバーがダウンした場合、すべてのアクションがマスターで実行されるため、構成は強制されません。
- Ansible（saltなど）の場合、マスターサーバーがダウンすると、すべてのアクションがマスターサーバーによって実行されるため、構成は強制されなくなります。
現在のユーザーケースでは、PowerShell DSCを使用して、全体的な管理ツールとしてPuppet、Chef、Ansible、Salt、またはCF-Engineのいずれかを使用してWindowsシステムの管理を支援するため、このリストにはWindows PowerShellDSCを含めていません。
私の控えめな表現がツールのそれぞれについて正しいかどうか、そしてそうでないかどうかを知りたいですか？
そこでまず、jscott、Fredi、user378016、およびcoderangerにすべての回答を感謝したいと思います。
私自身の質問に答えるために
- CF-Engineの場合、これは問題ではありません。すべてのノードをサーバーとして実行するように構成でき、サーバーが使用できない場合でも実行が続行されるためです。
これはすべてCF-EngineのWebサイトに詳しく記載されており、例は次の場所にあります。 https://cfengine.com/learn/how-cfengine-works/
- Puppetの場合、マスター/マスターレスモードとその長所と短所を選択できます。
Puppetにはさまざまなモードがあり、Frediが示しているように、モードはどちらか一方です。ただし、さらに掘り下げた後、Puppetは非常に柔軟性があり、マスターモードとマスターレスモードの両方でサポートできる優れた機能を備えています。
- Chefの場合、最初の実行ではマスターサーバーがポリシーをフェッチする必要がありますが、その後、マスターが使用できない場合、実行はその現在のポリシーで続行されます。
したがって、これは完全には正しくありませんでした。実行がサーバーモード（chef-soloを使用しない）の場合、実行には実行ごとにマスターへの接続が必要です。すでに述べたように、フォールバックキャッシングを行う方法はいくつかあり、興味深い可能性があり、さらに調査する価値があります。
- Saltの場合、マスターサーバーがダウンした場合、すべてのアクションがマスターで実行されるため、構成は強制されません。
確認してくれたuser378016のおかげで、提供された答えはこれに非常にうまく答えていると思います（パーマリンク： https://serverfault.com/a/805791/22538 ）
- Ansible（saltなど）の場合、マスターサーバーがダウンすると、すべてのアクションがマスターサーバーによって実行されるため、構成は強制されなくなります。
したがって、Ansibleはトリッキーなものです（Frediの回答に感謝します）。 1台のサーバーにAnsibleソフトウェアをインストールするだけでよいという大きなメリットがあります。この「マスター」に保存されているプレイブックは、必ずしもマスターで実行されるとは限りませんが、SSHを介して他のユーザーに適用できます。もちろん、これには、SSH経由でアクセス可能であり、特定の前提条件（プレイブックに概説されている）を満たすように構成するこれらすべてのボックスが必要です。場合によっては、必ずしもそれほど望ましいとは限りません。
編集：Ansibleを、管理対象のノードにインストールすることで、puppet-masterless、chef-soloと同様の方法で実行できることを追加する必要があります。 gitのような場所から構成をプルしてから、ローカルに構成を適用するようにします。
私がCF-Engine、Chef、またはPuppetを推奨する方向に興味がある人のために。 AnsibleとSaltはどちらも興味深いものですが、私のユーザーケースでは、SSHが常に利用可能であるという信頼は、実際にはオプションではありません。 （もちろん、すべてのボックスにサーバーコンポーネントをインストールしたり、何らかのスケジューラーをインストールして構成を強制したりすることはできますが、これは元のアーキテクチャーとは正反対のようです）。
これらの製品はすべて非常に優れており、長所と短所が異なります。この場合、AnsibleとSaltは理由だけでなく適切ではないと感じました。上記だけでなく、他のさまざまな理由もあります。
私が経験したもの、つまりPuppetとAnsibleについてのみコメントします。そして、私はいくつかの詳細を省略しています。
どちらも、必要な場合にのみエージェントレスまたはローカルで実行するように設定できます。それらをローカルでのみ使用するには、必要なマニフェスト/プレイブックをターゲットマシンに転送し、そこで実行するための何らかの方法が明らかに必要です。
マスターでのPuppetの使用法について言えば、実際のマスターを背後に置いたロードバランサーを使用して冗長性を持たせることができます。
代わりにAnsibleにはマスターの概念はなく、プレイブックにアクセスする方法があれば、ssh/powershellを使用して管理対象マシンに接続できる各マシンで接続できます。おそらく、操作にDBを使用するAnsible Towerを意味し、必要に応じてクラスター化できます。
これにより、どちらの場合も実際の冗長性、つまり実際のスクリプトが得られます。ほとんどすべての場合、私はそれらがgitリポジトリにとどまるのを見たので、本質的に冗長であり、クローンを作成するだけで、必要な量の「マスター」コピーを持つことができます。
お役に立てれば。
ソルトを見ると、マスターとミニオンの間の機能的な接続を構成する唯一の情報は次のとおりです。
- ミニオンがマスターIPをなんとかして解決できるという事実
- / etc/salt/pki/masterディレクトリにあるミニオンの公開鍵
ソルトマスターが死んだ場合、システムは効果なしで実行を続けます。しかし、その通りです。マスターがなくなっている間は、構成に変更を加えることはできません。だから問題は、どれだけ早くそれを取り戻すことができるかということです。
マスターを再インストールして起動するだけです。ミニオンキーを再度受け入れる（または潜在的なバックアップを再インストールする）ことができ、古いマスターで中断したのと同じ場所にいます。同じマシンを再利用できない場合は、ミニオンを新しいマスターに向ける必要があります。
破損または消失している可能性のある状態データはデータベースにありません。それは私にとってそれの美しさです。そのオーバーレイであり、押し込まれません。他の方法の例として、データベースがなくなるとシステムがヘッドヘッドのように動作し、再インストールする必要があるjujuのようにはなりません。
また、Saltには Multimaster and Syndic があります-高可用性は、その開発における長年のトピックです。
上記で締めくくるために、Chef（chef-clientを使用している場合、chef-soloは純粋にローカルであり、失敗する可能性のあるサーバーコンポーネントがありません）は、実行のたびにサーバーを必要とします。停止が発生した場合にキャッシュデータを使用する方法はいくつかありますが、デフォルトの動作ではなく、簡単でもありません。 Chef Serverは、障害ゾーンごとに1つのクラスターを持つ冗長/クラスター化システムで実行することをお勧めします。クラスタリング用のchef-backend製品と、マルチサーバー同期用のFacebookのGroceryDeliveryを確認してください。