Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

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로는 잘 접속이 되지만 당연히 "호스트 주소+포트"로는 접속이 안 됩니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 12/15/2022]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13312정성태4/8/20233150Windows: 244. Win32 - 시간 만료를 갖는 MessageBox 대화창 구현 (개선된 버전)파일 다운로드1
13311정성태4/7/20233562C/C++: 163. Visual Studio 2022 - DirectShow 예제 컴파일(WAV Dest)
13310정성태4/6/20233158C/C++: 162. Visual Studio - /NODEFAULTLIB 옵션 설정 후 수동으로 추가해야 할 library
13309정성태4/5/20233367.NET Framework: 2107. .NET 6+ FileStream의 구조 변화
13308정성태4/4/20233207스크립트: 47. 파이썬의 time.time() 실숫값을 GoLang / C#에서 사용하는 방법
13307정성태4/4/20233015.NET Framework: 2106. C# - .NET Core/5+ 환경의 Windows Forms 응용 프로그램에서 HINSTANCE 구하는 방법
13306정성태4/3/20232922Windows: 243. Win32 - 윈도우(cbWndExtra) 및 윈도우 클래스(cbClsExtra) 저장소 사용 방법
13305정성태4/1/20233171Windows: 242. Win32 - 시간 만료를 갖는 MessageBox 대화창 구현 (쉬운 버전)파일 다운로드1
13304정성태3/31/20233478VS.NET IDE: 181. Visual Studio - C/C++ 프로젝트에 application manifest 적용하는 방법
13303정성태3/30/20232807Windows: 241. 환경 변수 %PATH%에 DLL을 찾는 규칙
13302정성태3/30/20233412Windows: 240. RDP 환경에서 바뀌는 %TEMP% 디렉터리 경로
13301정성태3/29/20233525Windows: 239. C/C++ - Windows 10 Version 1607부터 지원하는 /DEPENDENTLOADFLAG 옵션파일 다운로드1
13300정성태3/28/20233229Windows: 238. Win32 - Modal UI 창에 올바른 Owner(HWND)를 설정해야 하는 이유
13299정성태3/27/20233018Windows: 237. Win32 - 모든 메시지 루프를 탈출하는 WM_QUIT 메시지
13298정성태3/27/20232930Windows: 236. Win32 - MessageBeep 소리가 안 들린다면?
13297정성태3/26/20233537Windows: 235. Win32 - Code Modal과 UI Modal
13296정성태3/25/20232942Windows: 234. IsDialogMessage와 협업하는 WM_GETDLGCODE Win32 메시지 [1]파일 다운로드1
13295정성태3/24/20233158Windows: 233. Win32 - modeless 대화창을 modal처럼 동작하게 만드는 방법파일 다운로드1
13294정성태3/22/20233373.NET Framework: 2105. LargeAddressAware 옵션이 적용된 닷넷 32비트 프로세스의 가용 메모리 - 두 번째
13293정성태3/22/20233499오류 유형: 853. dumpbin - warning LNK4048: Invalid format file; ignored
13292정성태3/21/20233435Windows: 232. C/C++ - 일반 창에도 사용 가능한 IsDialogMessage파일 다운로드1
13291정성태3/20/20233923.NET Framework: 2104. C# Windows Forms - WndProc 재정의와 IMessageFilter 사용 시의 차이점
13290정성태3/19/20233457.NET Framework: 2103. C# - 윈도우에서 기본 제공하는 FindText 대화창 사용법파일 다운로드1
13289정성태3/18/20232746Windows: 231. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 자식 윈도우를 생성하는 방법파일 다운로드1
13288정성태3/17/20232830Windows: 230. Win32 - 대화창의 DLU 단위를 pixel로 변경하는 방법파일 다운로드1
13287정성태3/16/20232995Windows: 229. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 윈도우를 직접 띄우는 방법파일 다운로드1
1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...