ホーム>source

Windowsマシンで正常に動作するService Dockerコンテナを作成しましたが、Linuxマシンで同じように実行しようとすると、挿入されたサービスをサービスが見つけられないという問題が発生します。

詳細:

  1. サービスdocker composeファイルを使用して作成されたコンテナ。
  2. 環境変数を使用してサービスAコンテナーに挿入されたサービスBコンテナー
  3. サービスAコンテナーは正常に機能し、サービスBコンテナーも正常に機能します。
  4. サービスAコンテナーがサービスBコンテナーにアクセスしようとすると問題が発生します。サービスBコンテナーに到達できません。サービスBの内部DNSをサービスAコンテナーで解決できませんでした。
  5. サービスAとサービスBのコンテナーは、Docker構成ファイルの一部として手動で作成された内部ネットワークに接続されています。これらのLinuxコンテナーをWindowsホストOSで実行すると、サービスBのDNSは簡単に解決されますが、LinuxホストOSで実行すると、同じことが失敗します。

私はいくつかのことを試しましたが、 -サービスBの内部DNSは、WindowsホストOSではサービスAによって解決できましたが、Linux OSでは解決できませんでした。

DockerCompose(メインファイルの一部)

<前>ウィズウィズ

注:ServiceAおよびServiceBは参照用です

サービスにログを書き込んだので、Windowsの場合はDNSが解決されているがLinuxの場合は解決されていないことを確認できます。 なぜLinuxの動作が異なるのかが大きな問題です。

Linuxマシンのログ: 以下は、サービスBにアクセスしたときに受け取る応答です。

私のWindowsとLinux環境で見られる唯一の違いは、Linux環境がネットワーク上にプロキシを持っているのに対し、Windows環境にはプロキシがないことです。

編集1: 私は何度も検索しましたが、問題はプロキシネットワークでのみ発生することがわかりました。セットアップはプロキシネットワークのないマシンで正常に機能しているため、これを確認できました。  /etc/systemd/system/docker.service.d/proxy.confファイルにプロキシを設定しましたが、Dockerコンテナ内で実行されます。

services: serviceb: container_name: serviceb image: serviceb restart: always ports: - "30041:80" networks: - internal-network servicea: container_name: servicea image: servicea restart: always ports: - "30091:80" networks: - internal-network environment: ConnectionString__Service: http://serviceb:80 depends_on: -serviceb networks: internal-network: driver: bridge name: test
あなたの答え
  • 解決した方法 # 1

    問題は確かにネットワークに存在するプロキシのせいでした。私は ~/.docker/config.json を変更しました  プロキシ値を使用して、コンテナを作成しました。プロキシ値もコンテナ内に設定され、サービスを検出させようとしたときにDNSが失敗しました。

    問題:サービスAからサービスBにアクセスするために作成されたHTTPクライアントがプロキシ値を使用していました。コンテナ内のプロキシ値がサービスの検出を妨げていました。

    解決:

    コンテナ内にプロキシ値を設定しないでください。つまり、config.jsonを変更しないでくださいOR

    useProxy=false でHttpクライアントを作成する

  • 解決した方法 # 2

    リンク設定をserviceaに追加し、次に serviceb を使用します。  servicebのDNS名として。

    <前>ウィズウィズ servicea: links: - serviceb

関連記事

  • 前へ java - JPAクエリ:サブクエリをグループ化条件に結合する
  • 次へ PowerShellを使用して特定のノードXMLの内部テキストを更新する方法