Docker の名前解決ネットワークの問題 - チュートリアル

願わくば、あなたがこの記事を読む必要がまったくないことを願っています。あなたがたまたまここにたどり着いたのは、退屈しているか、間違った種類の検索をしたからです.または、Docker コンテナーがインターネットにアクセスできなくなったという問題に実際に直面している可能性があります。以前は正常に機能していたのに、最近になって、環境に変更を加えていません。

これは非常に漠然とした問題ステートメントのように聞こえますが、これは私が突然直面していたことです。 URL を解決する一時的なエラーのようなエラーで、コンテナーにネットワーク アクセスがありませんでした。これは名前解決の問題のように見え、発生するはずがなかったので、さらに悩まされました。しかし、私たちは先を行っています。テスト ホスト:systemd を使用した Ubuntu - 後者にとって重要です。ゆっくり進みましょう。

問題の詳細

システムで Docker を構成しました。うまくいっています。複数のイメージ、複数のコンテナーがあり、高度なネットワーク ルールも使用しており、すべてが完璧に整っているように見えます。次に、更新やパッケージのインストールなど、コンテナーで特定のアクティビティを実行できなくなったことに気付きます。これをデバッグする最善の方法は、イントロ ガイドで説明したように、実行中のコンテナー インスタンスにシェルをアタッチすることです。実際、実行中のコンテナー内では、次のようなものが表示されます:

# apt-get update
Err:1 https://archive.ubuntu.com/ubuntu bionic InRelease
'archive.ubuntu.com' を解決中の一時的な障害
0% [セキュリティに接続しています。 ubuntu.com]

これは DNS の問題 (名前解決) のようです。コンテナーはドメイン名を IP アドレスに解決する方法を理解できないため、サーバーに接続して更新などのデータを取得することができません。ここには 2 つの問題があります。一つは、なぜ問題が突然発生したのですか？ 2 つ目は、実際にネットワークを修正する必要があることです。それでは、これをエレガントな方法でトラブルシューティングする方法をお見せしたいと思います.

解決策

まず、問題が発生した理由を理解しましょう。ここにすぐに答えはありませんが、確認すべき事項には、身近な環境だけではありません。たとえば、ホストは変更されていない可能性がありますが、ネットワークにはルーター、ネットワーク ポリシー、DNS サーバー自体が変更されている可能性があります。通常、直接のセットアップ以外で何が起こっているかを制御することはできないため、問題がどこにあるかを把握する最善の方法は、問題を段階的に切り分けることです。

• ホスト システムにネットワークがあり、URL を解決できない場合は、最初にそれを整理する必要があります。ホストと宛先の間、およびその間に存在するネットワーク インフラストラクチャに問題がある可能性が最も高いです。
• ホスト システムにネットワークがあり、URL を正しく解決できる場合、特に Docker コンテナが URL を解決する方法に問題があります。ここに次に注力する必要があります。
• Docker ネットワーク インターフェイスが稼働しているかどうかを確認します (ip や ifconfig などのコマンドを使用)。そうでない場合は、次のステップに進む前にまずそれを修正します。

ifconfig docker0

• コンテナ インスタンスに IP アドレスがあるかどうかを確認します。そうでない場合は、修正する必要があります。

docker inspect <コンテナ名または ID> | grep -i "ipaddr"

• 可能であれば、コンテナ内で同じ結果が得られるかどうかを確認します (ip または ifconfig)。結果が前のコマンドで表示されたものと一致しない場合は、修正する必要があります。
• 外部からコンテナーに ping を実行できるかどうかを確認します (ping コマンドが使用可能な場合は、その逆も可能です)。 ping が機能する場合、ネットワークが正しく構成されており、トラフィックをブロックするファイアウォール ルールがないことを示している可能性があります (ほとんどの場合)。

名前解決

これらのすべてのチェックで奇妙な問題やエラーが返されない場合、次のステップは DNS 解決に集中することです。そのための構成は、/etc/resolv.conf 構成ファイルで利用できます。これは、Linux の物理インスタンスと仮想マシンおよびコンテナーの両方に当てはまります。コンテナが次のようなものを使用していることにおそらく気付くでしょう:

...
# サポートされているモードの詳細については、man:systemd-resolved.service(8) を参照してください。
# /etc/resolv.conf の操作。

検索 xyz

ネームサーバー X.Y.Z.W
...

ネームサーバーの IP アドレスは、ほとんどの場合、外部 IP アドレス (ISP など) またはローカルホスト (127.0.0.X) になります。問題は、これらがホストの /etc/resolv.conf ファイルと一致するかどうかです。

答えは、ほとんどの場合、ホストの /etc/resolv.conf ファイルに localhost が定義されているということです。それでは、コンテナでそれを試してください。 resolv.conf ファイルを編集し、nameserver 行の IP アドレスを、ホストの値 =localhost と一致するものに置き換えます。これで問題が解決した場合は、すばらしいことです。しかし、ほとんどの場合、そうはなりません。

ただし、この時点では、ホストのネットワーク接続に問題はありません。そのため、環境内の DNS サーバーの実際のアドレスを把握する必要があります。そして、最新の Linux ディストリビューションのほとんどが systemd を使用しているという事実によって、これはさらに複雑になります。プロットが厚くなります。

systemd で DNS を調べる

あ、はい。ネームサーバーが何であるかを把握する必要があり、そのために systemd コマンドを使用する必要があります。ほとんどの場合、システムに systemd がある場合は、ネットワーク名解決マネージャーおよびサービスである systemd-resolve も使用しています。設定は /etc/systemd/resolved.conf に保存されます。ただし、systemd-resolve コマンドを使用して、コマンドラインで結果を取得することもできます:

systemd-resolve --status

リンク 3 (wlp59s0)
現在のスコープ:DNS
LLMNR 設定:はい
MulticastDNS 設定:いいえ
DNSSEC 設定:いいえ
サポートされている DNSSEC:いいえ
DNS サーバー:10.50.34.1
2001:64c:1462:b023::1
DNS ドメイン:dedoimedo

ここには何がありますか？興味深いものがたくさんあります。しかし、本当に重要なのは、DNS サーバーを読み取る行です。これが私たちが望むものです。この IP アドレスをコンテナーの /etc/resolv.conf ファイルに配置して、再試行してください。ネットワークが再び機能するはずです。

では、なぜこの問題が生じるのでしょうか?

ここで、もう一度理由を説明できます。 systemd-resolve のドキュメントを見ると、システムになんらかの変更があった可能性があります (通常の更新が原因である可能性もあります)。これにより、選択した操作モードが名前解決との競合を引き起こします。特に、/etc/resolv.conf の処理方法を見ると、最初のモードは次のように述べています。

systemd-resolved は、従来の Linux プログラムとの互換性のために /run/systemd/resolve/stub-resolv.conf ファイルを維持します。このファイルは、/etc/resolv.conf からシンボリック リンクされている可能性があります。このファイルには、127.0.0.53 DNS スタブ (上記を参照) が唯一の DNS サーバーとしてリストされています。また、systemd-resolved で使用されている検索ドメインのリストも含まれています。検索ドメインのリストは常に最新の状態に保たれています。 /run/systemd/resolve/stub-resolv.conf は、アプリケーションで直接使用するべきではなく、/etc/resolv.conf からのシンボリック リンクを介してのみ使用する必要があることに注意してください。このファイルは、ローカル DNS API をバイパスするすべてのローカル クライアントを正しい検索ドメイン設定で systemd-resolved に接続するために、/etc/resolv.conf からシンボリック リンクされている場合があります。この操作モードをお勧めします。

この方程式のリンクの 1 つが壊れているか、何かが変更されている場合、Docker サービスが実際に何が得られるかを判断できず、名前解決ができなくなる可能性があります。したがって、解決策 [sic] は、コンテナーが理解して使用できる実際のネットワーク DNS アドレスを提供することです。これは私の側では少し憶測ですが、かなり正しいと思います。

結論

では、別の謎が解明され、別のフロントガラスが解明されました。か何か。私は半分魔法のような解決策は好きではありませんが、非常に複雑で階層化されたシステム インフラストラクチャがある場合、解決策が問題と同じくらい悪い場合があります。彼らが問題を解決しないということではありません。しかし、それが Linux の未来であり、IT のすべてである無限の抽象化です。

トピックについて言えば、この小さなガイドが、コンテナーの冒険を比較的迅速かつ簡単に修正できることを願っています。 Docker を使用していて、コンテナー インスタンス内で名前解決が機能しなくなった場合は、おそらく上記のヒントとコツをテストしてから、適切な修正を行って独自のイメージを構築する必要があります。これでまた戦う。以上で終わりです。

乾杯。