docker - bridge 네트워크 모드에서 컨테이너 간 통신 시 --link 옵션 권장 이유
이상하군요, 예전에 container로 띄워 둔 PostgreSQL DB에 너무 연결이 많다고 합니다.
// 아래의 명령어로 띄워 두었던,
// docker run --name postgres1 -p 5432:5432 -v postgresql:/var/lib/postgresql/data --restart=always -e POSTGRES_PASSWORD=test_1234 -d postgres
OperationalError at /test/postgretest
connection to server at "192.168.100.50", port 5432 failed: FATAL: sorry, too many clients already
분명히 특정 앱에서 연결 누수가 있을 텐데요, 그래서 어떤 클라이언트인지 조사를 하기 시작했습니다.
현재 DB를 container로 띄운 상태였으므로, 그 컨테이너에 접속해 netstat로 확인을 했더니,
// PostgreSQL DB 컨테이너의 shell
// apt install net-tools
# netstat -ano | grep 5432
1 tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN off (0.00/0/0)
2 tcp 0 0 172.17.0.14:5432 172.17.0.1:48226 ESTABLISHED keepalive (640.20/0/0)
3 tcp 0 0 172.17.0.14:5432 172.17.0.1:38950 ESTABLISHED keepalive (2475.20/0/0)
4 tcp 0 0 172.17.0.14:5432 172.17.0.1:48380 ESTABLISHED keepalive (6538.43/0/0)
5 tcp 0 0 172.17.0.14:5432 172.17.0.1:40010 ESTABLISHED keepalive (1819.84/0/0)
...[생략]...
# ifconfig
eth0: flags=4163 mtu 1500
inet 172.17.0.14 netmask 255.255.0.0 broadcast 172.17.255.255
...[생략]...
보는 바와 같이 대상 IP가 172.17.0.1로 나옵니다. 이것은 도커 네트워크에서 기본 생성된 bridge로 묶인 호스트 측의 docker0 네트워크의 IP입니다.
// 호스트 측의 shell
$ ifconfig
...[생략]...
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
...[생략]...
그런데, 실제론 호스트 서버에서는 PostgreSQL DB를 접근하지 않고, 함께 호스팅되고 있는 다른 App 컨테이너에서 접속을 하고 있는 상태였습니다. 즉, 컨테이너 호스트 측의 docker0 네트워크에서 중계를 하는 것으로 인해 실질적인 대상이 되는 컨테이너의 IP가 숨겨져 문제의 추적이 되지 않는 것입니다.
이렇게 나온 원인은, PostgreSQL DB에 대한 클라이언트 측의 연결 문자열을 직접 호스트 측의 IP를 통해 접속했기 때문입니다.
// 파이썬의 경우
psycopg2.connect(host='192.168.100.50', dbname='...', user='...', password='...', port=5432)
즉, 이런 식으로 호스트 IP를 통해 접속하면, 호스트와 bridge 네트워크 간에 소프트웨어 적으로 연결이 발생합니다. 실제로 이런 상황을 호스트 측에서 netstat를 이용하면 확인할 수 있는데요,
// 호스트 측의 shell
$ netstat -ano | grep ":5432 "
tcp 0 0 172.17.0.1:52638 172.17.0.14:5432 ESTABLISHED off (0.00/0/0)
tcp 0 0 172.17.0.1:57348 172.17.0.14:5432 ESTABLISHED off (0.00/0/0)
tcp 0 0 172.17.0.1:41354 172.17.0.14:5432 ESTABLISHED off (0.00/0/0)
tcp 0 0 172.17.0.1:38850 172.17.0.14:5432 ESTABLISHED off (0.00/0/0)
tcp6 0 0 :::5432 :::* LISTEN off (0.00/0/0)
tcp6 0 0 192.168.100.50:5432 172.17.0.17:38822 ESTABLISHED off (0.00/0/0)
tcp6 0 0 192.168.100.50:5432 172.17.0.18:50978 ESTABLISHED off (0.00/0/0)
tcp6 0 0 192.168.100.50:5432 172.17.0.18:34984 ESTABLISHED off (0.00/0/0)
tcp6 0 0 192.168.100.50:5432 172.17.0.17:53266 ESTABLISHED off (0.00/0/0)
그러니까, PostgreSQL DB 컨테이너가 열고 있는 포트(-p 5432:5432/tcp)를 호스트 측에서도 동일하게 열어 LISTEN 상태로 대기하고 있다가, 외부 또는 같은 bridge에 속한 컨테이너에서 192.168.100.50:5432로 요청하는 연결이 있으면 수락한 다음, 그 연결과의 통신을 중계하기 위해 다시 docker0 네트워크를 통해 "172.17.0.1:52638 <--> 172.17.0.14:5432" 소켓 접속을 하는 것입니다.
딱 봐도 별로죠? ^^
이와 같은 중계 문제를 해결하려면, 컨테이너 간의 통신을 호스트 IP를 이용하지 않고 직접 통신을 하는 것입니다. 이를 위해 Bridge 네트워크 모드에서는 접속하려는 측의 컨테이너를 --link 옵션을 통해 알려주고 시작할 수 있습니다.
가령, 이번 글에서 예를 든 환경에서는 PostgreSQL DB 컨테이너를 접근하려는 측에 다음과 같이 옵션을 추가합니다.
// PostgreSQL DB가 동작 중인 컨테이너의 이름이 postgres1인 경우(docker run --name postgres1 ...),
// 그 컨테이너로 접속하는 측의 컨테이너 실행에 "--link" 옵션 사용
docker run ...[생략]... --link postgres1:postgre
그럼, 저렇게 실행하는 컨테이너에는 호스트 파일에 postgre 이름이 등록되고,
// 애플리케이션 측 컨테이너 환경
# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
...[생략]...
172.17.0.14 postgre 284ab17119dc PostgreSQLDB
따라서 소스 코드에서 저 이름을 사용해 접속할 수 있습니다.
// 컨테이너 환경에 postgre라는 이름의 DNS 항목이 추가되므로,
psycopg2.connect(host='postgre', dbname='...', user='...', password='...', port=5432)
이렇게 변경한 후 운영하면, 이후 PostgreSQL DB 컨테이너 측에서 해당 DB에 연결된 클라이언트의 연결을 곧바로 확인할 수 있습니다.
// PostgreSQL DB 컨테이너의 shell
// 접속하려는 측의 컨테이너 주소가 172.17.0.3이라고 가정
# netstat -ano | grep 5432
1 tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN off (0.00/0/0)
2 tcp 0 0 172.17.0.14:5432 172.17.0.3:48226 ESTABLISHED keepalive (640.20/0/0)
3 tcp 0 0 172.17.0.14:5432 172.17.0.3:38950 ESTABLISHED keepalive (2475.20/0/0)
4 tcp 0 0 172.17.0.14:5432 172.17.0.3:48380 ESTABLISHED keepalive (6538.43/0/0)
5 tcp 0 0 172.17.0.14:5432 172.17.0.3:40010 ESTABLISHED keepalive (1819.84/0/0)
...[생략]...
정리하자면, 물론 컨테이너 간 통신을 호스트 주소를 이용하는 것도 가능하겠지만, 1) 문제가 발생했을 때 원인 추적도 쉽고 2) 부가적인 TCP 소켓 연결도 하지 않는 "--link" 옵션 사용을 권장합니다.
참고로, 같은 bridge 네트워크 내에서의 컨테이너 간 통신이 --link로만 허용하도록 강제하고 싶다면 서버 역할의 컨테이너 실행 시 "-p" 옵션을 통한 포트 제공을 없애면 됩니다. 그런 경우 --link로는 잘 접속이 되지만 당연히 "호스트 주소+포트"로는 접속이 안 됩니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]