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)
13287정성태3/16/20232995Windows: 229. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 윈도우를 직접 띄우는 방법파일 다운로드1
13286정성태3/15/20233470Windows: 228. Win32 - 리소스에 포함된 대화창 Template의 2진 코드 해석 방법
13285정성태3/14/20233044Windows: 227. Win32 C/C++ - Dialog Procedure를 재정의하는 방법파일 다운로드1
13284정성태3/13/20233196Windows: 226. Win32 C/C++ - Dialog에서 값을 반환하는 방법파일 다운로드1
13283정성태3/12/20232796오류 유형: 852. 파이썬 - TypeError: coercing to Unicode: need string or buffer, NoneType found
13282정성태3/12/20233132Linux: 58. WSL - nohup 옵션이 필요한 경우
13281정성태3/12/20233058Windows: 225. 윈도우 바탕화면의 아이콘들이 넓게 퍼지는 경우 [2]
13280정성태3/9/20233688개발 환경 구성: 670. WSL 2에서 호스팅 중인 TCP 서버를 외부에서 접근하는 방법
13279정성태3/9/20233365오류 유형: 851. 파이썬 ModuleNotFoundError: No module named '_cffi_backend'
13278정성태3/8/20233201개발 환경 구성: 669. WSL 2의 (init이 아닌) systemd 지원
13277정성태3/6/20233615개발 환경 구성: 668. 코드 사인용 인증서 신청 및 적용 방법(예: Digicert)
13276정성태3/5/20233607.NET Framework: 2102. C# 11 - ref struct/ref field를 위해 새롭게 도입된 scoped 예약어
13275정성태3/3/20233951.NET Framework: 2101. C# 11의 ref 필드 설명
13274정성태3/2/20233569.NET Framework: 2100. C# - ref 필드로 ref struct 타입을 허용하지 않는 이유
13273정성태2/28/20233258.NET Framework: 2099. C# - 관리 포인터로서의 ref 예약어 의미
13272정성태2/27/20233428오류 유형: 850. SSMS - mdf 파일을 Attach 시킬 때 Operating system error 5: "5(Access is denied.)" 에러
13271정성태2/25/20233476오류 유형: 849. Sql Server Configuration Manager가 시작 메뉴에 없는 경우
13270정성태2/24/20233057.NET Framework: 2098. dotnet build에 /p 옵션을 적용 시 유의점
13269정성태2/23/20233571스크립트: 46. 파이썬 - uvicorn의 콘솔 출력을 UDP로 전송
13268정성태2/22/20234062개발 환경 구성: 667. WSL 2 내부에서 열고 있는 UDP 서버를 호스트 측에서 접속하는 방법
13267정성태2/21/20234040.NET Framework: 2097. C# - 비동기 소켓 사용 시 메모리 해제가 finalizer 단계에서 발생하는 사례파일 다운로드1
13266정성태2/20/20233616오류 유형: 848. .NET Core/5+ - Process terminated. Couldn't find a valid ICU package installed on the system
13265정성태2/18/20233614.NET Framework: 2096. .NET Core/5+ - PublishSingleFile 유형에 대한 runtimeconfig.json 설정
13264정성태2/17/20234884스크립트: 45. 파이썬 - uvicorn 사용자 정의 Logger 작성
13263정성태2/16/20233210개발 환경 구성: 666. 최신 버전의 ilasm.exe/ildasm.exe 사용하는 방법
13262정성태2/15/20234297디버깅 기술: 191. dnSpy를 이용한 (소스 코드가 없는) 닷넷 응용 프로그램 디버깅 방법 [1]
1  2  3  4  5  6  7  8  9  10  11  [12]  13  14  15  ...