私のマイクロサービス システムでは、docker swarm と Consul を使用する予定です。Consul の高可用性を確保するために、3 つのサーバー エージェント (ノードごとにクライアント エージェント) のクラスターを構築しますが、ローカルの Consul エージェントの障害からは救われません。
何か不足していますか?そうでない場合、複数の領事エージェントを認識するように swarm を構成するにはどうすればよいですか?
私のマイクロサービス システムでは、docker swarm と Consul を使用する予定です。Consul の高可用性を確保するために、3 つのサーバー エージェント (ノードごとにクライアント エージェント) のクラスターを構築しますが、ローカルの Consul エージェントの障害からは救われません。
何か不足していますか?そうでない場合、複数の領事エージェントを認識するように swarm を構成するにはどうすればよいですか?
Consul は、swarm の使用中に複数のエンドポイントをサポートしない唯一のサービス ディスカバリー バックエンドです。
Zookeeper と etcd は両方とも、Swarm の使用中にディスカバリー バックエンドの「クラスター」に複数の IP を提供する etcd://10.0.0.4,10.0.0.5 形式をサポートします。
複数の領事 (サーバー) をサポートするように Swarm を構成する方法についての質問に答えるには、決定的な答えはありませんが、方向性とテストできるものを示すことができます (保証はありません)。
テストする価値のある 1 つの提案 (本番環境では推奨されません) は、Swarm マネージャーからの要求を 3 つの consul サーバーのいずれかに渡すことができるロード バランサーを使用することです。
そのため、swarm マネージャーを起動するときに、consul://ip_of_loadbalancer:port を指定できます。
ただし、これにより LB がボトルネックになります (ダウンした場合)。
私は上記をテストしておらず、うまくいくかどうか答えられません。これは単なる提案です。