핵심 정리
docker network create appnet
docker run -d --name db --network appnet postgres:17
docker run -d --name api --network appnet my-api
# api 컨테이너 안에서 db라는 이름으로 postgres에 접근 가능구조 이해
어떤 네트워크와 서비스 발견 기준을 먼저 떠올리면 되나
| 상황 | 먼저 떠올릴 선택 |
|---|---|
| 컨테이너 이름으로 통신 | 사용자 정의 bridge 네트워크 |
| Compose 서비스 간 통신 | 서비스 이름을 호스트명으로 사용 |
| 외부 접근 없이 내부만 연결 | 별도 네트워크 + 포트 미공개 |
| 기본 bridge만 쓰고 있다 | 사용자 정의 네트워크로 분리 |
사용자 정의 네트워크는 이름 기반 서비스 발견을 쉽게 만든다
Docker는 사용자 정의 bridge 네트워크 안의 컨테이너에 내장 DNS를 제공한다. 같은 네트워크에 속한 컨테이너는 이름만으로 서로를 찾을 수 있다. 내장 DNS가 컨테이너 이름이나 alias를 현재 IP로 해석해 주기 때문에, 재시작이나 재생성으로 IP가 바뀌는 환경에서도 이름 기준 접근이 더 안정적이다.
# 같은 네트워크 안에서 이름으로 통신
docker network create appnet
docker run -d --name redis --network appnet redis:7
docker run -it --network appnet alpine sh
# 컨테이너 내부에서:
# ping redis → redis 컨테이너 IP로 해석됨
# wget redis:6379 → 연결 성공기본 bridge와 사용자 정의 bridge의 결정적 차이
Docker 기본 bridge 네트워크(docker0)는 사용자 정의 bridge처럼 이름 기반 발견을 기대하기 어렵다. 실무에서는 IP 주소에 기대기보다 사용자 정의 네트워크를 만들어 서비스 이름으로 통신하는 쪽이 훨씬 다루기 쉽다. --link는 이미 권장되지 않는 방식이므로, 새 구성을 만들 때는 사용자 정의 네트워크를 기본 선택으로 보는 편이 맞다.
# 기본 bridge: 이름으로 통신 불가
docker run -d --name svc-a alpine sleep 999
docker run -it alpine ping svc-a # 실패: Name or service not known
# 사용자 정의 bridge: 이름으로 통신 가능
docker network create mynet
docker run -d --name svc-a --network mynet alpine sleep 999
docker run -it --network mynet alpine ping svc-a # 성공컨테이너 이름으로 다른 컨테이너에 접근할 수 있는 이유
Docker 내장 DNS는 컨테이너가 네트워크에 조인할 때 등록된다. 컨테이너 이름, Compose 서비스 이름, 지정한 alias가 모두 DNS 엔트리로 등록된다. Compose를 사용하면 서비스 이름이 자동으로 DNS 이름이 되므로 db, redis, api처럼 설정 파일에 쓴 이름 그대로 내부 통신에 사용할 수 있다.
services:
api:
build: .
# api 컨테이너 안에서 "db"라는 호스트명으로 postgres에 접근
environment:
DATABASE_URL: postgres://user:pass@db:5432/mydb
db:
image: postgres:17
environment:
POSTGRES_PASSWORD: pass
# Compose가 자동으로 appnet 같은 네트워크를 만들고 두 서비스를 연결--network 플래그로 네트워크에 연결하는 방법
컨테이너는 여러 네트워크에 동시에 속할 수 있다. docker network connect로 실행 중인 컨테이너를 추가 네트워크에 연결할 수도 있다. 네트워크를 분리하면 통신 범위를 의도적으로 제한해 보안 경계를 만들 수 있다.
# 여러 네트워크에 동시 연결
docker network create frontend
docker network create backend
docker run -d --name api \
--network frontend \
my-api
# 실행 중에 추가 네트워크 연결
docker network connect backend api
# 이제 api는 frontend, backend 양쪽과 통신 가능
# db는 backend에만 연결해 frontend에서 직접 접근 불가
docker run -d --name db --network backend postgres:17기본 bridge와 사용자 정의 네트워크 차이는 "이름으로 찾을 수 있느냐"가 핵심이다
간단한 테스트에서는 기본 bridge도 동작하지만, 컨테이너 이름이나 서비스 이름으로 안정적으로 통신하려면 사용자 정의 네트워크가 맞습니다. 특히 Compose나 멀티서비스 환경에서는 이름 기반 DNS와 네트워크 단위 분리가 실전 기본값입니다.
체크포인트
| 상황 | 적합한 선택 |
|---|---|
| 컨테이너 이름으로 서비스를 찾고 싶을 때 | 사용자 정의 bridge 네트워크 |
| Compose에서 서비스 간 통신 | 서비스 이름을 호스트명으로 사용 |
| DB, 캐시를 외부에서 격리하고 싶을 때 | 별도 네트워크에 연결, 포트 미공개 |
| 기본 bridge 네트워크 사용 | 단순 테스트가 아니면 사용자 정의 네트워크 우선 검토 |
주의할 점
컨테이너 안에서 localhost는 컨테이너 자신을 가리킨다. 다른 컨테이너에 접근할 때 localhost를 사용하면 연결이 되지 않는다. 반드시 같은 네트워크 안의 컨테이너 이름 또는 Compose 서비스 이름을 호스트명으로 사용해야 한다.
services:
api:
environment:
DATABASE_URL: postgres://localhost:5432/app
# api 컨테이너 안에서 localhost는 api 자신이라 db로 연결되지 않음참고 링크
2 sources