13

週末にdocker's IRCでこの質問をしましたが、答えを熟考する前に立ち去らなければなりませんでした:

コンテナ内で多数のアプリケーションを実行している場合 (ここでは、それらがすべて同じ物理ハードウェア上で実行されていると仮定しますが、そうである必要はありません)、それぞれがそれぞれを見つけられるようにしたいと考えています。その他は自動的に。

ある種のレジストリ ( etcdや DNS-SD/Bonjour など) を使用して、サービスと関連する詳細をアナウンスし、他のアプリケーションにそれらを見つけて、それに応じてトラフィックをルーティングさせることができます。

ここでの問題は、アプリケーションはコンテナー内でサービスを提供しているホスト名/ポートを認識できますが、これはアクセス可能なポートまたはアドレスである必要はないということです。結合する必要がある 2 つの情報があります。

  • サービスにアクセスできる場所。コンテナの外からアクセス可能
  • サービスの機能 (バージョン番号、サービスの種類); コンテナ内からアクセス可能

コンテナの壁を越えてこの情報を取得する方法を教えてください。

  1. TCP 経由で docker をコンテナーに公開することで、アプリはその表示場所を照会できますが、これは関心の分離に違反しているようです。
  2. アナウンスの準備のためにコンテナが開始された後、ホスト システムが照会するファイル/ポートをコンテナで開くことができますが、これは WSDL を再発明しているように感じます。

この問題をどのように解決すべきかについての考えやガイダンスはありますか?

4

2 に答える 2

4

おそらくコンテナ起動後にサービスの登録を行うというアプローチだと思います。その後、他のコンテナーはレジストリ ルックアップを実行して、これらのサービスを検出できます。

アップデート

maestroプロジェクトは、コンテナーが外部で構成され、その後、コンテナーの協調ネットワークをセットアップするために起動される方法の例を示しています。

于 2013-08-13T22:41:37.760 に答える
3

私もこれで悩んだことがあります。あなたの考えの間違いは、コンテナー自体がそれが何をするかを知っている唯一のものであるということだと思います。

コンテナーは、現在 MySQL にサービスを提供している自己認識型のエンティティではなく、明日はキュー プロセッサになることを決定します。

代わりに、コントローラー (自動化されたシステム、またはコマンド ラインのユーザー) があり、そのコントローラーは、特定のアプリを実行する必要があること、このアプリを実行するために特定のサービス セットが必要であること、およびそれを認識します。そもそもコンテナが開始される理由です。

コントローラーは、MySQL サービスが必要であること、および MySQL サービスが接続先の単一のホスト: ポートを表すことを認識しています。その場合、サービスが 2 つまたは 3 つのポートで構成されていることも認識できます。

したがって、ホスト/コントローラーがコンテナーに登録するアドレスを伝えるか、コンテナーがサービスを提供しているローカルポートを要求する (または、コンテナー定義に基づいてポートを知る可能性が高い) ことは、アーキテクチャ的に正しいことです。

実際には、ホストはコンテナーに「この特定のポートの LAN インターフェイスでサービスを実行し、登録します」、「この LAN インターフェイスの任意のポートでサービスを自分で実行し、自分で登録します」または「このポートでサービスを開始し、それを host:port に登録します。マッピングをセットアップして、そこで利用できるようにします。」

これらはすべてアーキテクチャ的には問題ありません。最終的に決定するのは常にホスト/コントローラーです。なぜなら、実行中のサービスとアクセス可能な場所の両方を把握しているのはホスト/コントローラーだけだからです。

docker でのこれに関する実際的な問題は、コンテナーの IP とホストにマップされたポートが動的に割り当てられ、コンテナーが実行されるまで実際にはどちらの情報も取得できないことです。これが、 Flynnが Docker に自動的に行わせるのではなく、ホスト ポート マッピング自体を選択する理由です。

これについての私の考えをいくつか書きました。

于 2014-02-05T12:25:51.383 に答える