Centos Docker ブリッジ モードでホスト Redis サービスにアクセスできないというトラブルシューティングの経験

背景：

以前、コンテナ内のホストが提供する Redis サービスにアクセスする必要があるプロジェクトを実行したことがあります (これは一般的なアプリケーション シナリオです)。従来のソリューションは次のとおりです。

① ホストネットワーク（ docker run --network=host ）：ホストネットワークスタックを完全に適用し、コンテナ内のlocalhostはホストマシンを参照します。

② docker run --network=bridge bridge）：これもdockerコンテナのデフォルトのネットワーク通信モードです。コンテナ内のlocalhostはコンテナ自体を指します。localhostを使用して、ホスト上のlocalhost:6379でホストされているRedisサービスにアクセスすることはできません。

Docker はデフォルトで docker0 ブリッジを確立します。

ブリッジにはゲートウェイ IP とサブネット セグメントがあります。ブリッジ内のコンテナは、サブネット セグメントからコンテナ IP (IP アドレス eth0) を決定します。ブリッジ内のコンテナは、サービス名を通じて相互にアクセスできます。

ブリッジ内のコンテナは、docker0 Getway を介して外部ネットワークにアクセスできます。

特別な操作は必要ありません。一般的な ② ブリッジ モードを使用するだけです。

ステップ1: ブリッジをカスタマイズして適用する

docker ネットワーク作成 --gateway 172.16.1.1 --subnet 172.16.1.0/24 app_bridge

docker run --network=app_bridge --name ......

# 以下は docker-compose.yml ファイルから取得したものです......
ネットワーク:
 デフォルト：
 名前: app_bridge
 外部: 真

デフォルトの docker0 ブリッジを使用しないのはなぜですか?

この記事の冒頭で述べたように、docker0はデフォルトのブリッジであり、新しく作成されたコンテナはデフォルトでこのブリッジに参加するため、このプログラム専用のブリッジapp_bridgeを作成する必要があります。

ステップ2: コンテナ内のホストに対応するエイリアスを作成する

コンテナ内でブリッジ モードでホスト マシンの localhost:6379 サービスにアクセスするには、Docker が提供する --add-host オプションを使用する必要があります (docker-compose.yml 内の対応する構成は extra_host です)。

docker run の --add-host オプションは、コンテナの /etc/hosts ファイルに行を追加し、その名前を使用して他のネットワークにアクセスしやすくなります。

docker run -it --add-host dockerhost:172.16.1.1 ubuntu cat /etc/hosts
172.17.0.22 09d03f76bf2c
fe00::0 ip6-ローカルネット
ff00::0 ip6-mcastプレフィックス
ff02::1 ip6-全ノード
ff02::2 ip6-オールルーター
127.0.0.1 ローカルホスト
::1 ローカルホスト ip6-ローカルホスト ip6-ループバック
172.16.1.1 ドッカーホスト

次に、プログラム構成ファイルで dockerhost:6379 を使用して、ホスト Redis サービスにアクセスできます。

------------------------------------------ docker ネットワーク モデルに少し詳しい友人であれば、上記の操作を理解して完了できるはずです-----------------------------------------------------

状況:

上記の操作を社内の CentOS7 マシンで実行したところ、コンテナがホストマシンに接続できなくなりました（コンテナ同士は正常にアクセスできました）。

問題のテストを簡素化します。新しいコンテナを作成し、コンテナ内の docker0 ゲートウェイに ping を試みます。なんと、会社の 4 台のマシンすべてが docker0 ゲートウェイに ping できませんが、外部ネットワークは正常にアクセスできます。

すると、次のような問題が発生します。デフォルトの docker0 ブリッジを使用すると、コンテナ内から docker0 ゲートウェイに ping できず、ホスト マシンにアクセスできなくなります。

ああ、それはおそらく会社のマシンの設定の問題でしょう。 。 〜

同社の運用・保守担当者に尋ねたところ、次のことがわかりました。

チェーン INPUT (ポリシー DROP)

上記の INPUT チェーンのデフォルト ポリシーは破棄です。コンテナーからホストにアクセスするための INPUT チェーン ルールは、リストされているもののいずれにも一致しないため破棄されるため、コンテナーから docker0 ゲートウェイに ping を実行してもスタックし、結果が返されません。

デフォルトのポリシーでは、リストされている INPUT チェーンのルールが満たされない限り破棄されます。

デフォルトで受け入れる転送および出力チェーンもあります

この戦略の本来の目的は、サーバーのセキュリティです (残念ながら、コンテナはホスト マシンにアクセスする基本的な機能を失ってしまいます!!!)。

運用・保守ソリューション:

① sudo service iptables stopを使用してiptablesをシャットダウンします

②使用するブリッジネットワークセグメントをINPUTチェーンに追加する

sudo iptables -I 入力 -s 172.17.0.0/16 -j 受け入れる

[docker0サブネット172.17.0.0/16 INPUTを受け入れ] ルール、ポータルを追加

OK、これですべてです。会社のネットワーク内のデフォルトのブリッジ コンテナー内のブリッジ ゲートウェイに ping できず、ホスト マシンにアクセスできないという問題が発生した場合は、この記事を参照してトラブルシューティングしてください。

要約する

以上がこの記事の全内容です。この記事の内容が皆様の勉強や仕事に何らかの参考学習価値をもたらすことを願います。123WORDPRESS.COM をご愛顧いただき、誠にありがとうございます。