2016-03-28 7 views
2

私は、dnsmasqを実行するドッキングコンテナを実行しているCoreOSインスタンスを持っています。現在、dnsmasqの設定では、すべてのクエリをログに記録し、デバッグモードで実行するように設定されているだけなので、キャッシュするだけです。ドッキングコンテナ間でのdnsmasqの奇妙な動作

私はと別のコンテナからこれを使用しようと、nslookup、または単に私が戻ってBad hostname: google.comを取得し、私は再試行されているかのように、要求は複数回に来ているログクエリで見ることができますping google.comを実行しています。

CoreOSを実行しているホストマシンから同じコマンドを実行しようとすると、すべて1回の試行で問題は解決されません。

私の計画では、クラスタ内の各CoreOSマシン上でdnsmasqを実行し、confdでバックアップして、すべてのサービスが適切な対応を解決できるようにします。

私は自分のベースイメージにAlpine linuxを使用していますが、同じ結果を持つUbuntuとDebianイメージの中でそれらのコマンドを実行しようとしました。

+0

"すべてのサービスが適切な相手を解決できるように";ドッカー1.9では、同じネットワーク上の他のコンテナを名前で直接解決できることに注意してください。 (例えば、「他の容器にpingする」)。 Docker 1.10にはこれに対する追加の拡張機能があり、コンテナの "コンテナスコープ別名"と "ネットワークスコープ別名"を設定することができます。 – thaJeztah

+0

しかし、私はそれがCoreOSクラスタの一部になることは承知しているので、Dockerが複数のホストにどのように通信するのかは分かりません。私たちはCoreOS + Flannelを実行する予定であるため、各コンテナはルーティング可能なIPアドレスを取得します。このメカニズムもDockerの範囲外です。 –

+0

私は答えに近づいています。私はコンテナの中で 'strace'を通して' nslookup'を実行しました.1行は特に面白かったです - '予期しない出所からの返信:172.17.42.1#53、expected 10.137.64.102#53'基本的に' 10.'アドレス'--dns'のようにコンテナに渡されます。しかし、応答はホストの 'docker'ネットワークアダプタから来ているので、破棄され、再試行されています。内部のドッカーネットワーク上のリゾルバをIPとして設定すると、正常に動作します。 –

答えて

0

行うには正しいことは次のスレッド(Setting Up Docker Dnsmasq)に存在した

それが明示的に(私たちの場合は、内部)ホストのIPアドレスにバインドする必要があるポートを露出させたとき。

コンテナの呼び出しは、次のようなものになります。

source /etc/environment 
docker run -d --cap-add NET_ADMIN \ 
    -p "$COREOS_PRIVATE_IPV4:53:53" \ 
    -p "$COREOS_PRIVATE_IPV4:53:53/udp" \ 
    -e COREOS_PRIVATE_IPV4="$COREOS_PRIVATE_IPV4"\ 
    someorg/dnsmasq 

を次に--dns "$COREOS_PRIVATE_IPV4"で走っているすべてのコンテナが正しくマシンレベルのdnsmasqのを経由して解決してもらいます。