다음 설정을 디버깅하는 데 도움을 찾고 있습니다.
호스팅 회사의 VP Cloud 인스턴스가 3개 있습니다. (VPS가 VMWare라고 생각하지만 호스트 회사 사이트에서 문서를 찾을 수 없습니다.)
- 모두 Ubuntu 18.04를 실행하고 있습니다.
- 3개 모두에 도커를 설치했습니다.
모든 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 다음 init 명령을 실행했습니다.
docker swarm init --advertise-addr NODE_1_IP --data-path-port=7789
그리고 노드 2와 3에서 다음 조인 명령을 실행했습니다.
docker swarm join --token XXX -advertise-addr NODE_2/3_IP NODE_1_IP:2377
토큰은 노드 1이 나에게 준 값에서 가져옵니다. data-path-port를 지정하여 이전 문제를 해결했습니다. 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
이번에도 컬을 5번 실행합니다.
curl web
때로는 작동할 때도 있고 ctrl-c를 누를 때까지 그냥 거기 앉아서 멈추는 경우도 있습니다.
5배의 배수로 실행하면 작동 패턴과 깨진 패턴이 반복됩니다. 이는 일부 컨테이너가 NODE_1에서 실행 중이고 작동하지만 노드 2 및 3과의 통신이 작동하지 않기 때문이라고 생각합니다.
문제를 조사한 후 ESP ACCEPT 규칙이 클라우드 공급자 방화벽 규칙 세트에 추가되었습니다.
클러스터 재부팅을 시도했지만 운이 없었습니다.
이제 나는 막혔습니다. 디버깅을 진행하는 방법에 대한 권장 사항이 있습니까? 감사합니다 로버트
업데이트 1
디버깅하기 위해 웹 서비스가 NODE_3의 단일 인스턴스에서만 실행되도록 테스트를 변경했습니다. 그런 다음 노드 3에 대해 두 개의 콘솔을 로드하고 다음 명령을 실행했습니다.
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
한 콘솔에는 NODE_3으로 들어오는 트래픽과 NODE_3에서 나가는 다른 트래픽이 표시됩니다.
그런 다음 암호화되지 않은 테스트를 다시 실행했습니다. 들어오는 콘솔 모두에 약 7줄이 나타나고 나가는 콘솔에는 5줄이 나타납니다. 따라서 NODE_3으로 들어가는 트래픽과 NODE_3에서 나가는 트래픽이 있으며 테스트가 작동 중입니다.
그런 다음 암호화된 테스트를 실행했습니다. 이번에는 들어오는 콘솔에 한 줄이 나타나고 나가는 콘솔에는 아무것도 나타나지 않습니다. 따라서 단일 패킷이 NODE_3에 도달하고 있습니다. 암호가 해독되어 컨테이너로 다시 전송되는지 확실하지 않습니다.
업데이트 2
제가 언급하지 못한 구성 영역 중 하나는 다음과 같은 /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 클라이언트 인증서를 사용하여 원격으로 연결할 수 있도록 하기 위한 것입니다. 이 파일은 떼를 생성하기 전에 모든 노드에 설정되었습니다.
패킷의 암호 해독이 가능한 원인인 것처럼 보이므로 daemon.json을 다음과 같이 변경했습니다.
{
"hosts": []
}
그런 다음 각 컴퓨터를 재부팅했습니다. 테스트 결과는 동일합니다. 여전히 작동하지 않습니다.
그런 다음 docker swarm ca --rotate 명령을 실행하고 테스트를 다시 실행했습니다. 결과는 동일합니다.
새 구성으로 클러스터를 제거하고 다시 초기화하지 않았습니다. (누군가가 도움이 될 것이라고 생각하면 그렇게 할 수 있지만 그 과정에서 잃을 도커 비밀과 구성이 많이 있습니다.)
업데이트 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를 검사했지만 아무 것도 찾을 수 없습니다.
아직 문제를 어디에서 찾아야 할지 모르겠습니다.