Docker Compose를 실행하면 컨테이너들은 자동으로 같은 네트워크 안에 묶인다. 이 덕분에 api 서비스가 db 서비스에 접근할 때 IP 주소 대신 서비스 이름을 그대로 호스트명으로 쓸 수 있다. 네트워크 설정을 제대로 이해하면 서비스 간 격리와 연결을 정밀하게 제어할 수 있다.
docker compose up을 실행하면 Compose는 프로젝트 이름을 prefix로 붙인 default network를 자동으로 만든다. 별도 설정 없이도 같은 compose.yaml 안의 모든 서비스가 이 네트워크에 연결된다.
[프로젝트명_default 네트워크]
┌─────────┐ ┌─────────┐ ┌─────────┐
│ api │────▶│ db │ │ cache │
└─────────┘ └─────────┘ └─────────┘
└─────────────────────────────────┘
모두 같은 네트워크
default network: Compose가 자동 생성하는 bridge 타입 가상 네트워크. 컨테이너마다 내부 IP가 할당된다.
같은 네트워크 안에 있으면 Docker의 내장 DNS가 서비스 이름을 해당 컨테이너의 IP로 자동 해석한다. 별도의 IP 하드코딩 없이 서비스 이름만으로 연결할 수 있다.
services:
api:
image: myapp:latest
environment:
DB_HOST: db # 서비스 이름을 호스트명으로 사용
CACHE_HOST: cache
db:
image: postgres:16
cache:
image: redis:7
api 컨테이너 내부에서 ping db를 실행하면 db 컨테이너의 IP로 응답이 온다.
서비스 수가 늘어나면 모든 컨테이너를 하나의 네트워크에 두는 것이 보안상 불리하다. custom network를 정의해 접근 범위를 명시적으로 제한할 수 있다.
services:
api:
image: myapp:latest
networks:
- frontend
- backend
db:
image: postgres:16
networks:
- backend # api만 접근 가능, web은 접근 불가
web:
image: nginx:latest
networks:
- frontend # api와만 통신, db에는 접근 불가
networks:
frontend:
driver: bridge
backend:
driver: bridge
[frontend 네트워크] [backend 네트워크]
┌─────┐ ┌─────┐ ┌─────┐ ┌────┐
│ web │──▶│ api │ │ api │──▶│ db │
└─────┘ └─────┘ └─────┘ └────┘
web은 db와 다른 네트워크에 있으므로 직접 통신이 차단된다. api는 두 네트워크 모두 참여해 중간 계층 역할을 한다.
여러 Compose 프로젝트가 동일한 네트워크를 공유해야 할 때 external network를 사용한다. 네트워크를 Compose 밖에서 미리 만들어두고 external: true로 참조한다.
docker network create shared-net
services:
api:
image: myapp:latest
networks:
- shared-net
networks:
shared-net:
external: true # Compose가 직접 생성하지 않고 기존 네트워크를 참조
external network: docker network create로 미리 생성된 네트워크. Compose가 down을 실행해도 삭제되지 않는다.
| 방식 | 설정 | 격리 수준 | 주 용도 |
|---|---|---|---|
| default network | 없음 (자동) | 낮음 | 빠른 개발 환경 |
| custom network | networks: 블록 | 높음 | 서비스 간 접근 제어 |
| external network | external: true | 프로젝트 간 공유 | 멀티 Compose 연동 |
서비스가 3개 이상이거나 DB에 대한 접근을 제한해야 한다면 custom network로 명시적으로 분리하는 것이 기본 원칙이다.