docker inspect를 치면 컨테이너 IP가 172.17.0.2라고 분명히 나온다. 그런데 Mac 터미널에서 그 주소로 접속하면 아무 응답이 없다. IP는 있는데 길이 없는 셈이다.

결론부터 말하면 Mac에서 보이는 컨테이너 IP는 정보일 뿐, 접속할 수 있는 주소가 아니다. 이 글에서는 Docker Desktop(Mac)의 네트워크가 어떻게 생겼길래 이런 일이 생기는지, Linux와 무엇이 다른지 정리한다.

컨테이너 IP는 VM 안에서만 유효하다

Docker 컨테이너는 Linux 커널 기능(namespace, cgroup) 위에서 돈다. macOS 커널에는 그 기능이 없어서, Docker Desktop은 Mac 위에 가벼운 Linux VM을 하나 띄우고 Docker Engine과 컨테이너를 전부 그 안에서 실행한다.

컨테이너가 받는 172.17.x.x 주소는 이 VM 안의 docker0 브릿지 네트워크에서 나온다. 기본 bridge 네트워크의 대역이 172.17.0.0/16이고, 게이트웨이 172.17.0.1이 VM 안의 docker0이다. 사용자 정의 네트워크를 만들면 172.18.x.x처럼 다른 대역을 받는다.

graph LR
  subgraph Mac["macOS 호스트"]
    T["터미널: curl 172.17.0.2 (경로 없음)"]
  end
  subgraph VM["Docker Desktop Linux VM"]
    B["docker0 브릿지 172.17.0.1"]
    C["컨테이너 172.17.0.2"]
    B --- C
  end
  T -. "라우팅 없음" .-> B

Mac의 라우팅 테이블에는 172.17.0.0/16으로 가는 경로가 없다. 브릿지는 VM 안에만 있고 Mac 쪽 네트워크 인터페이스와 연결돼 있지 않다. 그래서 **Mac에서 **172.17.x.x로 보낸 패킷은 갈 곳이 없다. docker inspect가 IP를 보여주는 건 VM 안에서 Docker Engine이 알려준 값을 그대로 옮긴 것일 뿐이다.

Linux에서는 같은 명령이 된다

Linux에서는 Docker Engine이 호스트 커널에서 직접 돈다. docker0 브릿지가 호스트의 네트워크 인터페이스로 생기고, 호스트 라우팅 테이블에 172.17.0.0/16 경로가 붙는다. 덕분에 호스트에서도 컨테이너 IP로 바로 접속할 수 있다.

구분LinuxMac (Docker Desktop)
Docker Engine 위치호스트 커널Linux VM 안
docker0 브릿지호스트에 존재VM 안에만 존재
호스트에서 컨테이너 IP 접속가능불가능

Mac에서 컨테이너에 닿으려면 IP 대신 포트를 게시해야 한다. docker run -p 8080:80 ...처럼 포트를 열면 Docker Desktop이 Mac의 localhost:8080으로 들어온 요청을 VM 안 컨테이너로 넘겨준다. 공식 문서도 Mac에서는 컨테이너로 직접 트래픽을 라우팅할 수 없으니 포트 게시를 쓰라고 안내한다.

컨테이너 IP를 확인하는 두 가지 방법

접속은 못 해도 IP를 확인할 일은 있다. 컨테이너끼리 통신을 디버깅할 때가 그렇다.

호스트에서는 docker inspect로 본다.

docker inspect {Container ID}

출력이 길어서 IP만 필요하면 포맷을 지정하는 편이 낫다.

# 연결된 모든 네트워크의 IP만 출력
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' {Container ID}

컨테이너 안에서는 아래 명령으로 본다.

ip addr  # 또는
hostname -I

두 결과가 같은 172.17.0.2를 가리킨다. 다만 slim·alpine 계열 이미지에는 ip 명령이 없거나 hostname -I 옵션을 지원하지 않을 수 있다.

정리

Mac에서 컨테이너 IP로 접속이 안 되는 건 설정 실수가 아니라 구조 때문이다. 컨테이너 네트워크는 Docker Desktop의 Linux VM 안에만 있고, Mac은 그 안으로 가는 길을 모른다. Mac에서는 IP 대신 포트 게시를 쓰면 된다.

참고자료