次の設定のデバッグについてサポートを求めています:
ホスティング会社から 3 つの VPs Cloud インスタンスを取得しています。(VPS は VMWare だと思いますが、ホスト会社のサイトでドキュメントが見つかりません。)
- すべてUbuntu 18.04を実行しています。
- 3つすべてにdockerをインストールしました。
すべての docker バージョンは同じです。
Client: Docker Engine - Community
Version: 19.03.5
API version: 1.40
Go version: go1.12.12
Git commit: 633a0ea838
Built: Wed Nov 13 07:29:52 2019
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.5
API version: 1.40 (minimum version 1.12)
Go version: go1.12.12
Git commit: 633a0ea838
Built: Wed Nov 13 07:28:22 2019
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.2.4
GitCommit: e6b3f5632f50dbc4e9cb6288d911bf4f5e95b18e
runc:
Version: 1.0.0-rc6+dev
GitCommit: 6635b4f0c6af3810594d2770f662f34ddc15b40d
docker-init:
Version: 0.18.0
GitCommit: fec3683
1 つのノード 1 で次の init コマンドを実行しました。
docker swarm init --advertise-addr NODE_1_IP --data-path-port=7789
そしてノード2と3で次のjoinコマンドを実行しました
docker swarm join --token XXX -advertise-addr NODE_2/3_IP NODE_1_IP:2377
トークンはノード1から与えられた値から取得されます。私はデータパスポートを指定することで以前の問題を解決しました。これはVPSがVMWareであり、標準データポートと競合するためだと思います。
私のクラウド プロバイダーは、個々の VPS にファイアウォール ルールを適用するための UI を提供しています。ファイアウォール グループを使用して、3 つのサーバーすべてに次のルールを適用しました。
TCP ACCEPT to dest ports 80, 443, (and my SSH port)
ICMP ACCEPT any
TCP ACCEPT 2376
TCP, UDP ACCEPT 7789
UDP ACCEPT 7789
TCP ACCEPT 2377
ESP ACCEPT
これをテストするために、ノード1で次のコマンドを実行しました。
docker network create --driver=overlay --attachable testnet
docker network create --opt encrypted --driver=overlay --attachable testnet_encrypted
docker service create --network=testnet --name web --publish 80 --replicas=5 nginx:latest
クラスター全体でサービスが実行されたら、次の操作を実行します。
docker run --rm --name alpine --net=testnet -ti alpine:latest sh
apk add --no-cache curl
次に、カールを 5 回繰り返します。
curl web
5 回とも応答が返されます。そのまま続けると、応答が返され続けます。これは、すべてのコンテナーがトラフィックを取得していることを意味していると思います。
次に、サーバーを暗号化されたネットワークに切り替えて、同じテストを繰り返します。
docker service rm web
docker service create --network=testnet_encrypted --name web --publish 80 --replicas=5 nginx:latest
docker run --rm --name alpine --net=testnet_encrypted -ti alpine:latest sh
apk add --no-cache curl
もう一度 curl を 5 回実行します。
curl web
時々は動作しますが、Ctrl + C を押すまでそのまま停止したままになることもあります。
これを 5 回実行すると、動作と中断のパターンが繰り返されます。これは、一部のコンテナーが NODE_1 で実行されていて、これらは動作するものの、ノード 2 および 3 への通信が機能していないためだと思います。
この問題について調査した後、ESP ACCEPT ルールがクラウド プロバイダーのファイアウォール ルールセットに追加されました。
クラスターを再起動しようとしましたが、うまくいきませんでした。
今、行き詰まっています。デバッグを進める方法について何かアドバイスはありますか。ありがとう、ロバート
アップデート1
デバッグするために、Web サービスが NODE_3 の単一のインスタンスでのみ実行されるようにテストを変更しました。次に、ノード 3 の 2 つのコンソールをロードし、次のコマンドを実行しました。
sudo tcpdump src NODE_1_IP and dst NODE_3_IP and port 7789
sudo tcpdump src NODE_3_IP and dst NODE_1_IP and port 7789
1 つのコンソールには NODE_3 へのトラフィックが表示され、もう 1 つのコンソールには NODE_3 からのトラフィックが表示されます。
その後、暗号化されていないテストを再度実行しました。受信コンソールに約 7 行、送信コンソールに 5 行が表示されました。つまり、NODE_3 に入るトラフィックと NODE_3 から出るトラフィックがあり、テストは機能しています。
次に、暗号化されたテストを実行しました。今回は、着信コンソールに 1 行が表示され、発信コンソールには何も表示されません。つまり、1 つのパケットが NODE_3 に到達しています。それが復号化されてコンテナーに送り返されているかどうかはわかりません。
アップデート2
私が言及しなかった設定の 1 つの領域は、次の /etc/docker/daemon.json セットアップがあることです。
{
"hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2376"],
"tlscacert": "/var/docker/ca.pem",
"tlscert": "/var/docker/server-cert.pem",
"tlskey": "/var/docker/server-key.pem",
"tlsverify": true
}
これは、SSL クライアント証明書を使用してリモート接続できるようにするためです。このファイルは、Swarm を作成する前にすべてのノードに設定されていました。
パケットの復号化が原因の可能性があると思われるため、daemon.json を次のように変更しました。
{
"hosts": []
}
その後、各マシンを再起動しました。テスト結果は同じで、まだ動作しません。
次に、コマンド docker swarm ca --rotate を実行し、テストを再実行しました。結果は同じです。
クラスターを削除して新しい構成で再初期化していません。(誰かがそれが役立つと思うならそうすることもできますが、そのプロセスで失われる docker シークレットと構成が多数あります。)
アップデート3
クラスターを完全に削除して再起動しましたが、これは機能しませんでした。
いくつかの情報源によると、次のコマンドを実行します。
sudo tcpdump -p esp
ノードで実行すると、トラフィックが表示されます。これをクラスター内のすべてのノードで実行し、すべてのテストを繰り返しましたが、どこにも出力がありません。
すべてのノードで ufw を非アクティブにします。
robert@metcaac6:/var/log$ sudo ufw status
[sudo] password for robert:
Status: inactive
しかし、iptables -LI を実行すると、すべてのノードで同じルールが取得されます。
robert@metcaac6:/var/log$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere policy match dir in pol ipsec udp dpt:7789 u32 "0x0>>0x16&0x3c@0xc&0xffffff00=0x100300"
DROP udp -- anywhere anywhere udp dpt:7789 u32 "0x0>>0x16&0x3c@0xc&0xffffff00=0x100300"
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-INGRESS all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (2 references)
target prot opt source destination
Chain DOCKER-INGRESS (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED tcp spt:https
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED tcp spt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:30001
ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED tcp spt:30001
ACCEPT tcp -- anywhere anywhere tcp dpt:30000
ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED tcp spt:30000
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target prot opt source destination
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
問題の可能性を探して dmesg と /var/log/syslog を調べましたが、何も見つかりません。
問題をどこで探せばいいのかまだわかりません。