Mesos環境で検出サービスを実行するためのソリューションは12あります。
クライアントがサービスを見つける方法によって、それらを3つのグループに分けることができます。
- プロキシベース
- クライアントとサービスの間にプロキシが存在する場合(たとえば、HAProxy(marathon-lbはそれに基づいています)、fabio、traefik、nxy)、HTTPパス、ヘッダー、ドメインなどに基づいてサービスの負荷分散を処理します。このソリューションは開発が簡単で、要求に基づいて負荷分散を調整する機会を提供します。一方、ホップを追加し、プロキシとしてMitMの状況になります。
- DNSlike(サービスの場所については、よく知られている特別なエンドポイントに問い合わせてください)
- ソフトウェア定義ネットワーク-SDNでコンテナごとのIPを使用できるため、各コンテナは一意のIPで公開され、HTTPの場合はデフォルトポート80、HTTPSの場合は443などを使用してサービスを提供します。これは最も高度で比較的新しい技術ですが、サービスIPを見つけるために単純な古いDNSを使用しています。プロキシよりも誘導するのは難しいかもしれませんが、あらゆるタイプのトラフィックで機能します。
- サービスレコード-すべてのコンテナがグローバルDNSに登録され、クライアントがDNSSRVクエリを使用してそのIPとPORTを取得します。 Consul Mesos DNSは、このタイプのDNSサーバーを提供します。また、他のいくつかのプロトコルはこのアイデアに基づいています(Bonjureを見てください)。 SDNとプロキシの両方を最大限に活用しようとします。セットアップは比較的簡単で、プロトコルに依存しません。
- その他
- 他のタイプに適合しないもの(例:自社開発ソリューション等、ユーレカ。いくつかの最適化を提供するインフラストラクチャとアプリケーションとの緊密な関係になる可能性があります。 DHTベースのディスカバリーサービスを使用する試みがいくつかあることは言及する価値があります-メタサービスディスカバリー
DiscoveryServiceの作成に使用できるツールの詳細についてはこちらをご覧ください
ディスカバリーサービスは、サービスエントリが入力される方法で分割できます:
- プーリング
- Mesos / Marathonは、状態について定期的に照会されます。これがMesosDNSの仕組みです。これは最も簡単な方法ですが、サービスの開始/停止と変更がサービス検出に入るまでに大きな遅延が発生します。これは、ヘルスチェックを使用することで最小限に抑えることができます。
- イベントベース
- Marathonには、状態の変化に関する情報を含むイベントをプッシュする機能があります(イベントバスint Mesosも含めるようにイニシアチブがあります—設計ドキュメント。このようにmarathon-lbが機能します。同様のジョブはmarathon-consulによって実行されますが、データはに渡されます。領事。
- アプリ/コンテナ内
- 上記のソリューションは非同期であるため、サービス検出の状態が古くなっている場合があります。サービスが開始されましたが、リクエストを処理する準備ができていないか、サービスが停止しました。 healtcheckを使用しても、ダウンタイムが0の場合にすべてが発生するとは限りません。ダウンタイムを最小限に抑えるための解決策は、リクエストを処理する準備ができたときにアプリケーションを登録し、停止する前に登録を解除することです(別名、グレースフルシャットダウン)。