Docker クロスサーバー通信オーバーレイソリューション (パート 1) Consul 単一インスタンス

目次シナリオタスクアイデア分析するコンセプトと選択ちょっとしたテスト環境説明予防実践テスト引用シナリオ会社のマイクロサービスがオンライン化しようとしています。マイクロサービスは Docker コンテナを使用してデプロイされます。同じホストに、すべてのサービスがデプロイされています。Nacos に登録されている IP と PORT は、Dockerfile で定義されたイントラネット IP とポート番号です。問題はないようです。ゲートウェイ経由で呼び出すこともできます。大きな前提があることに注意してください。すべてのサービスコンテナーは同じホストにデプロイする必要があります。サービスインスタンスが同じホストに展開されていない場合、たとえば、ゲートウェイサービスがサーバー A にあり、サービス a がサーバー B にあり、両方とも Nacos (または他の登録センター) に登録されている場合、報告される IP アドレスはすべてイントラネットからのものです。外部からの要求が届くと、ゲートウェイは Nacos のサービスリストからサービス a の対応するイントラネット IP アドレスを見つけますが、呼び出しは失敗します。 ps: イントラネットはどのように接続できるのでしょうか... タスクマイクロサービスコンテナは異なるサーバー上に存在し、相互に呼び出すことができるアイデア報告された IP はイントラネットからのものであるため、ホストマシンの IP とポートを報告するように依頼します。 Dockerのホストネットワークモードの使用シェル経由でコンテナをデプロイするときに、ホストIPと設定されたマッピングポート番号を取得するようにデプロイスクリプトを変更します。 Dockerネットワークを相互運用可能にする分析する以下は、上記の「アイデア」セクションに従って問題を説明するものです。 1. 公式ドキュメントと Github を確認した結果、2 つの解決策が見つかりました。 IPポートを固定し、ホストIPとポートを設定ファイルにハードコードする：解決したようだが、問題は水平方向に拡張できないこと - ほとんど使えない複数のネットワークカード環境により間違った IP ポートが報告されないようにネットワークカードを修正しました: 役に立たないです。コンテナーに入った後、 `ifconfig`内部ネットワークカードが`eth0`と`lo`の 2 つしかないことを検出しました。対応するネットワークカードの IP は内部ネットワーク IP です。それでも役に立たないです。 2. Dockerのホストネットワークモードを使用すると、今回報告されたIPは確かにホストIPですが、ポート番号が間違っていることがわかります... Javaパラメータを使用して、シェルを介してマップされるポート番号を渡すと、理論的には可能です。唯一の欠点は、 `docker ps`ポート番号を直接確認できなくなり、 `docker inspect`追加で使用しなければならないことです。 3. マッピングされたポート番号は取得できますが、ホストのネットワークカード名が異なり、ハードコードされた後は柔軟性がありません。一部が`eth0`で一部が`ens33`の場合はどうなるでしょうか。予測できない状況は他にもたくさんあります！ ——使えるかもしれない 4. 成熟したDockerコンテナネットワークを介して共有しますが、パフォーマンスの低下は多少あります - 完全に利用可能ですコンセプトと選択最も信頼性の高い方法は、Docker ネットワーク共有を使用することです。検索エンジンの助けを借りて、オーバーレイを使用して効果を実現することにしました。 Overlay の簡単な説明は次のとおりです。コンテナが 2 つのホスト間で通信する場合、オーバーレイネットワークモードを使用して通信を行います。ホストを使用する場合は、物理 IP アドレスを直接使用してホスト間通信を実現することもできます。オーバーレイは、IP アドレス 10.0.2.3 などの仮想ネットワークを作成します。このオーバーレイネットワークモードでは、サービスゲートウェイに類似したアドレスがあり、パケットを物理サーバーのアドレスに転送し、ルーティングとスイッチングを通じて最終的に別のサーバーの IP アドレスに到達します。オーバーレイネットワークを実装するには、ネットワーク、エンドポイント、IP などのネットワークステータス情報を保存する KV データベースを導入する必要があります。 Consul、Etcd、ZooKeeperはすべてDockerでサポートされているKVデータベースです。ここではConsulを使用しています。他のKVデータベースと比較して、Consulが提供するインターフェースは管理に便利なので、ここではOverlayを実装するためにConsulを使用しています。各サーバーの Docker デーモンが独自の IP アドレスを Consul に登録することで、Docker イントラネットを共有できます。ここで共有されるイントラネットはオーバーレイネットワークモードです。登録された Docker 環境内で同じオーバーレイネットワークを使用しているコンテナのみが相互に通信できます。 ps: 作成後、オーバーレイネットワークを使用しないクロスサーバーコンテナはpingできませんちょっとしたテストシングルノード Consul は Docker イメージを使用してオーバーレイネットワークを実装します環境説明

シナリオ

会社のマイクロサービスがオンライン化しようとしています。マイクロサービスは Docker コンテナを使用してデプロイされます。同じホストに、すべてのサービスがデプロイされています。Nacos に登録されている IP と PORT は、Dockerfile で定義されたイントラネット IP とポート番号です。問題はないようです。ゲートウェイ経由で呼び出すこともできます。大きな前提があることに注意してください。

すべてのサービスコンテナーは同じホストにデプロイする必要があります。

サービスインスタンスが同じホストに展開されていない場合、たとえば、ゲートウェイサービスがサーバー A にあり、サービス a がサーバー B にあり、両方とも Nacos (または他の登録センター) に登録されている場合、報告される IP アドレスはすべてイントラネットからのものです。外部からの要求が届くと、ゲートウェイは Nacos のサービスリストからサービス a の対応するイントラネット IP アドレスを見つけますが、呼び出しは失敗します。

ps: イントラネットはどのように接続できるのでしょうか...

タスク

マイクロサービスコンテナは異なるサーバー上に存在し、相互に呼び出すことができる

アイデア

報告された IP はイントラネットからのものであるため、ホストマシンの IP とポートを報告するように依頼します。
Dockerのホストネットワークモードの使用
シェル経由でコンテナをデプロイするときに、ホストIPと設定されたマッピングポート番号を取得するようにデプロイスクリプトを変更します。
Dockerネットワークを相互運用可能にする

分析する

以下は、上記の「アイデア」セクションに従って問題を説明するものです。

1. 公式ドキュメントと Github を確認した結果、2 つの解決策が見つかりました。

IPポートを固定し、ホストIPとポートを設定ファイルにハードコードする：解決したようだが、問題は水平方向に拡張できないこと - ほとんど使えない
複数のネットワークカード環境により間違った IP ポートが報告されないようにネットワークカードを修正しました: 役に立たないです。コンテナーに入った後、 ifconfig内部ネットワークカードがeth0とloの 2 つしかないことを検出しました。対応するネットワークカードの IP は内部ネットワーク IP です。それでも役に立たないです。

2. Dockerのホストネットワークモードを使用すると、今回報告されたIPは確かにホストIPですが、ポート番号が間違っていることがわかります... Javaパラメータを使用して、シェルを介してマップされるポート番号を渡すと、理論的には可能です。唯一の欠点は、 docker psポート番号を直接確認できなくなり、 docker inspect追加で使用しなければならないことです。

3. マッピングされたポート番号は取得できますが、ホストのネットワークカード名が異なり、ハードコードされた後は柔軟性がありません。一部がeth0で一部がens33の場合はどうなるでしょうか。予測できない状況は他にもたくさんあります！ ——使えるかもしれない

4. 成熟したDockerコンテナネットワークを介して共有しますが、パフォーマンスの低下は多少あります - 完全に利用可能です

コンセプトと選択

最も信頼性の高い方法は、Docker ネットワーク共有を使用することです。検索エンジンの助けを借りて、オーバーレイを使用して効果を実現することにしました。

Overlay の簡単な説明は次のとおりです。

コンテナが 2 つのホスト間で通信する場合、オーバーレイネットワークモードを使用して通信を行います。ホストを使用する場合は、物理 IP アドレスを直接使用してホスト間通信を実現することもできます。オーバーレイは、IP アドレス 10.0.2.3 などの仮想ネットワークを作成します。このオーバーレイネットワークモードでは、サービスゲートウェイに類似したアドレスがあり、パケットを物理サーバーのアドレスに転送し、ルーティングとスイッチングを通じて最終的に別のサーバーの IP アドレスに到達します。

オーバーレイネットワークを実装するには、ネットワーク、エンドポイント、IP などのネットワークステータス情報を保存する KV データベースを導入する必要があります。 Consul、Etcd、ZooKeeperはすべてDockerでサポートされているKVデータベースです。

ここではConsulを使用しています。他のKVデータベースと比較して、Consulが提供するインターフェースは管理に便利なので、ここではOverlayを実装するためにConsulを使用しています。

各サーバーの Docker デーモンが独自の IP アドレスを Consul に登録することで、Docker イントラネットを共有できます。ここで共有されるイントラネットはオーバーレイネットワークモードです。登録された Docker 環境内で同じオーバーレイネットワークを使用しているコンテナのみが相互に通信できます。

ps: 作成後、オーバーレイネットワークを使用しないクロスサーバーコンテナはpingできません

ちょっとしたテスト

シングルノード Consul は Docker イメージを使用してオーバーレイネットワークを実装します

環境説明

サーバーOS	ホストIP	Dockerバージョン	ネットワークカード名
Ubuntu サーバー 18.04 LTS	192.168.87.133	18.09.6	ens33
Ubuntu サーバー 18.04 LTS	192.168.87.139	18.09.7	ens33

使用する Consul のバージョンは 1.5.2 で、これは現在 Docker Hub 上で最も脆弱性が小さいバージョンです。

このテスト環境はSystemdで管理されるLinuxディストリビューションに適しています
Consul は非公式の progrium/consul を使用しませんでした。主な理由は、このイメージが古すぎるためです。4 年前に脆弱性があった場合、間に合うように修正できなかったため、<hub.docker.com> にアクセスして、公式の落とし穴をすべて調査しました。 💔

予防

Dockerを実行する各ホストは異なるホスト名を持つ必要があります。

$ sudo hostnamectl set-hostname 新しいホスト名

同じホスト名の場合、同じ名前のホストDockerは相互に通信できなくなります。

実践

イメージを使用して133サーバー上でConsulを起動できるように準備します。まず、Dockerデーモンの起動パラメータを133サーバーを指すように構成します。

サーバー133と139のdocker.serviceをそれぞれ変更します。

$ ifconfig
#干渉するネットワーク カードは削除され、ネットワーク カードの名前は ens33 です
ens33: flags=4163<UP、BROADCAST、RUNNING、MULTICAST> mtu 1500
        inet 192.168.87.133 ネットマスク 255.255.255.0 ブロードキャスト 192.168.87.255
        inet6 fe80::20c:29ff:fe02:e00a プレフィックス長 64 スコープID 0x20<リンク>
        ether 00:0c:29:02:e0:0a txqueuelen 1000 (イーサネット)
        RXパケット 156739 バイト 233182466 (233.1 MB)
        RXエラー 0 ドロップ 0 オーバーラン 0 フレーム 0
        TX パケット 45173 バイト 2809606 (2.8 MB)
        TXエラー 0 ドロップ 0 オーバーラン 0 キャリア 0 衝突 0

$ vim /etc/docker/daemon.json

保存して終了します。

cluster-store : 設定された Consul のリーダーアドレス。単一のユニットは直接書き込むことができます。他のソフトウェアはプロトコルに注意する必要があります。
cluster-advertise : リスニングネットワークカードとポートを指定し、サブスクリプションメッセージを受信するためのIP:PORTも指定します。

別の方法としては、次に示すように、docker.service を直接変更します。

$ cd /etc/systemd/system/multi-user.target.wants
$ sudo vim docker.service

ExecStart=という単語を見つけて、この行の末尾に次のコードを追加します。

--cluster-store=consul://192.168.87.133:8500 --cluster-advertise=ens33:2375

効果は以下のとおりです。

操作効果は上記の方法と一致している

次にコマンドを実行してdockerサービスを再起動します。他のサーバーの操作方法も同様です。ネットワークカードの名前に注意してください。

$ sudo systemctl daemon-reload && sudo systemctl dockerを再起動します

133サーバーでConsulサービスを開始する

docker run -d --network ホスト -h consul --name=consul --restart=always -e CONSUL_BIND_INTERFACE=ens33 consul:1.5.2

ホストモードを使用する理由は、一部のポートがマップされないのを防ぐためです。Consulに外部ネットワークカードを認識させる唯一の方法はホストモードです。以下は非ホスト方式です。

$ docker run -di -h consul -p 8500:8500 --name=consul consul:1.5.2

Dockerオーバーレイ共有ネットワークを作成する

$ docker ネットワーク作成 -d オーバーレイ my_overlay

通常のネットワークを作成する場合との違いは、オーバーレイモードネットワークが指定されていることです。 -d --driverと書くこともできます。

Consulのページにアクセスしてください。私の場合は192.168.87.133:8500です。

設定はキー/値で行います。

docker -> ノードをクリック

上記の2つのノードは、2つのdockerデーモンによって登録された値です。

テスト

先ほど作成したオーバーレイネットワークを使用して、2つのサーバーに2つの新しい Centos コンテナを作成します。

133 サーバー

$ docker run -di --network my_overlay --name mycentos1 centos:7

139 台のサーバー

$ docker run -di --network my_overlay --name mycentos2 centos:7

--netは--networkと表記されます。 --で始まるものは省略できます=

133サーバー上のmycentos1コンテナのIPを表示する

$ docker 検査 -f "{{ .NetworkSettings.Networks.my_overlay.IPAddress}}" mycentos1
10.0.1.2

139サーバー上のmycentos2コンテナのIPを表示する

$ docker 検査 -f "{{ .NetworkSettings.Networks.my_overlay.IPAddress}}" mycentos2
10.0.1.3

サーバー133からサーバー139のmycentos2のイントラネットIPにそれぞれpingを実行します。

Pingは逆の場合と同じですが、外部からアクセスすることはできず、同じオーバーレイネットワーク上のコンテナを介してアクセスします。信じられない場合は、次のように試してみましょう。

133 サーバー

$ docker exec -it mycentos1 bash
# 10.0.1.3にpingする

アクセスは成功し、パケット損失はなく、逆も同様です。スペースが限られているため、テストは行いません。

これは、少なくとも現在のサービスが実際に相互接続されていることを示しています。次の記事では、本番環境向けのクラスタリング方法を開発します。

引用

テクニカルトーク | Docker オーバーレイネットワークの実装

Dockerコンテナオーバーレイネットワーク

Docker クロスホストネットワーク - オーバーレイ

22 日目: Docker ネットワークの紹介 (パート 3)

領事KV

Docker ハブ領事

Github docker-library/ドキュメント

Github ドッカーコンスル

この記事はHellxzによる学習・実践記事です。BubukouやMamiなどのサードパーティのクローラーWebサイトのクロールは禁止されています。

これで、Docker クロスサーバー通信オーバーレイソリューション (パート 1) - Consul 単一インスタンスに関するこの記事は終了です。関連する Docker オーバーレイネットワークコンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: