콘텐츠로 이동

컨테이너 네트워킹

개요

컨테이너 하나가 돌아가는 것만으로는 서비스가 완성되지 않아요. 웹 서버 컨테이너로 요청이 들어와야 하고, 앱 컨테이너가 DB 컨테이너와 통신해야 하죠. 컨테이너끼리, 또 바깥과 어떤 규칙으로 연결할지를 정하는 게 네트워킹이에요. 처음엔 "컨테이너가 왜 서로 안 보이지?"라는 질문에서 시작하는 경우가 많아요.

상위 문서: Docker · 이미지와 도커파일 · 컨테이너

핵심 개념

기본 드라이버. Docker는 내장 네트워크 드라이버를 제공해요.

  • bridge (기본) — 한 호스트 안의 컨테이너들이 사설 네트워크를 만들어 서로 통신해요. 단, 기본 bridge에서는 컨테이너가 IP 주소로만 통신할 수 있어요.
  • host — 컨테이너가 호스트의 네트워크 스택을 그대로 공유해요. 포트 충돌이 쉽고 격리가 약해서 자주 쓰진 않아요.
  • none — 네트워크를 붙이지 않아요.

사용자 정의 네트워크와 DNS. docker network create로 만든 사용자 정의 bridge 네트워크가 실무 표준이에요. 이 안의 컨테이너는 자동으로 DNS 이름(컨테이너 이름)으로 서로를 찾아요. IP가 바뀌어도 이름은 고정이라, 연결 대상을 하드코딩하지 않아도 돼요.

$ docker network create app-net
$ docker run --network app-net --name api myapp:latest
$ docker run --network app-net --name db postgres:16

이제 api 컨테이너에서 db라는 호스트명으로 DB에 접근할 수 있어요.

포트 노출과 게시. 컨테이너 내부 포트는 기본적으로 바깥에서 보이지 않아요. -p 호스트포트:컨테이너포트로 게시(publish)해야 호스트 밖에서 접근할 수 있어요. 반대로 컨테이너에서 바깥으로 나가는 통신(인터넷)은 기본적으로 됩니다.

$ docker run -p 8080:80 nginx

네임스페이스 격리. 각 컨테이너는 자체 네트워크 네임스페이스를 가져서, 자체 IP와 라우팅 테이블을 가져요. 그래서 컨테이너끼리 격리되면서도 호스트 커널을 공유하는 거예요.

실제 적용(데이터스케쳐스)

우리 제품은 컨테이너 간 연결을 Docker가 아니라 Kubernetes의 네트워크 모델로 관리해요. 파드들이 같은 네임스페이스 안에서 서비스 이름으로 서로를 찾듯이요. 다만 로컬에서 여러 컨테이너를 묶어 개발 환경을 띄울 때(docker compose 등) 이 사용자 정의 네트워크와 DNS 개념이 그대로 적용되니, 이름 기반 연결에 익숙해 두면 운영 그림이 잘 맞아요.

더 알아보기