도커 사용자 정의 네트워크 구성

1. 사용자 정의 네트워크 구성

자동으로 생성된 브릿지 docker0은 기본 기능이다보니 빠진 기능이 많고, 보통 사용자가 정의한 네트워크를 구성하여 사용한다.

먼저, 위 명령을 이용하여 사용자 정의 bridge network 생성이 가능하다.

도커는 기본적으로 HostOS와 bridge 간 연결을 하는데 이는 --net 옵션으로 네트워크 설정을 할 수 있다.

※ --net 옵션에 줄 수 있는 효과

bridge	브릿지 접속을 하도록 설정
none	네트워크 외부 노출을 하지 않음
container:컨테이너명 container:컨테이너ID	다른 컨테이너의 네트워크 활용 (다른 컨테이너의 대역을 빌림)
host	컨테이너가 host os의 네트워크를 함께 쓰도록 설정
macvlan	물리 네트워크에 컨테이너 MAC 주소를 통한 직접 연결 사용
NETWORK	기타 사용자 정의 네트워크 활용

 

위와 같이 포트포워딩 정보 없이 컨테이너를 띄웠는데도 불구하고 연 적도 없는 80번 포트가 열리는 것을 확인할 수 있다.

위와 같이 nginx가 그냥 호스트 주소로도 잘 돌아가는 것을 확인할 수 있다.

nginx의 80번 포트에 대한 PID를 조회해보면 host 내부 프로세스처럼 잡히는 것을 볼 수 있다.

해당 컨테이너는 자체적인 IP 주소를 갖지 않는 것을 볼 수 있다.

호스트의 IP를 쓰기 때문에 따로 배정받을 필요가 없는 것이고, 이는 docker0을 쓰지 않는다는 의미이다.

 

1) 사용자 정의 네트워크 생성

먼저, network create 명령어로 생성 후 확인해보면 아무 옵션도 주지 않은 경우 기본 bridge로 만들어지는 것을 볼 수 있다.

route를 이용하여 현재 ip routing table을 조회해보면 위와 같이 인터페이스명이 br로 시작하는 브릿지가 생성된 것을 확인할 수 있다.

172.18 대역으로 브릿지가 생성되었다.

ifconfig로 조회해보면 가장 상단에 해당 인터페이스를 볼 수 있다.

현재까지의 네트워크 구성은 위 그림과 같다.

또한, inspect 명령어를 통해 자세한 네트워크 상황을 조회해볼 수 있다. 

마찬가지로 아무 설정하지 않았을 경우 기본값은 브릿지로 생성되는 것을 확인할 수 있다.

위와 같이 터미널을 각각 띄워 해당 네트워크 브릿지에 2개의 컨테이너를 연결한다.

ifconfig 명령어로 각각 배정받은 ip 주소를 확인할 수 있다.

route 명령어를 통해 연결되어 있는 대역을 확인할 수 있고, 위쪽에서 새로 생성했던 172.18 대역에 연결된 것을 알 수 있다.

현재까지의 네트워크 구성은 위 그림과 같다.

inspect로 조회해보면 브릿지 입장에서도 확인할 수 있고, 연결된 컨테이너들도 볼 수 있다.

brctl show를 수행해보면 위와 같이 2개의 브릿지를 확인할 수 있고, 생성한 브릿지가 2개의 인터페이스를 가지는 것을 볼 수 있다.

컨테이너는 무조건 하나 당 하나 이상의 가상이더넷을 가지므로 컨테이너 두 개가 띄워진 현재는 위와 같이 설정된다.

network1의 bash 창에서 ping을 해보면 위와 같이 컨테이너 이름만 가지고도 잘 수행되고, network2의 IP 주소도 확인할 수 있다.

사용자 정의 네트워크는 자체적으로 DNS를 구성해주고, 그곳에 알아서 도메인까지 구성된다.

원래 컨테이너 이름만 가지고는 당연히 IP 주소를 조회할 수 없지만, 같은 커스텀 네트워크 내부에서는 예외적으로 docker DNS가 구축되기 때문에 컨테이너 이름만으로도 조회가 가능하다.

위와 같이 아무런 옵션 없이 newnode를 만들어주면 기본브릿지(192.17 대역)로 연결된다.

현재까지의 네트워크 구성은 위 그림과 같다.

따라서 network1 컨테이너에서는 newnode 컨테이너에 ping을 보낼 수 없는 것을 학인할 수 있다.

 

2) 좀 더 상세한 네트워크 만들어보기

위와 같이 좀 더 상세한 옵션들을 지정해준 후 네트워크를 생성하고 조회해보면 목록에 잘 생성된 것을 확인할 수 있다.

라우트 목록을 조회해보면 위에서 설정한 대역으로 브릿지가 생성된 것을 확인할 수 있다.

여기서 다음 컨테이너를 띄우면 IP는 172.33.1 대역으로 가져가게 될 것이다.

컨테이너를 띄운 후 ip를 조회해보면 역시 172.33.1.0 대역으로 진행되고, 처음 만든 컨테이너라 2번으로 배정된다.

자동 순서대로 배정하고 싶지 않으면 위와 같이 --ip 옵션으로 내부 IP를 지정할 수도 있다.

위와 같이 네트워크 자체를 조회해봐도 위와 동일한 정보들을 확인할 수 있다.

brctl로 확인해보면 위와 같이 생성한 브릿지 목록을 확인할 수 있다.

또한, ip addr 명령어로 해당 브릿지들을 확인할 수 있다.

ip route로도 역시 확인 가능하다.

exec를 이용해 net1에 ip addr 명령을 전달하여 조회해봐도 위와 같이 연결 현황을 확인할 수 있다.

최종 네트워크 구성은 위 그림과 같다.

 

3) 브릿지가 다른 경우의 구성

먼저, vswitch에 연결한 net1의 경우 172.33 대역을 사용하고 있다.

반면, mynetwork에 연결한 network1이나 network2는 172.18 대역을 사용하고 있다.

network1에서 net1으로 ping을 보내면 위와 같이 연결이 안되는 것을 확인할 수 있다.

즉, 같은 내부망이어도 현재 구성만으로는 브릿지 간 통신이 불가능하다는 것을 알 수 있다.

 

4) 네트워크 연결

먼저, con-net2라는 새로운 네트워크를 생성해주었고, 위 명령어를 통해 172.19 대역을 사용하고 있는 것을 확인할 수 있다.

위와 같이 connect 명령어를 사용하여 network2 컨테이너를 con-net2에 연결해주었다.

network2의 bash 창에서 확인해보면 위와 같이 eth1에 con-net2의 대역이 추가되어 있는 것을 확인할 수 있다.

이렇게 되면 양쪽 네트워크 모두에 연결된 형태가 되기 때문에 자연스럽게 양쪽 망과 통신이 가능해지게 된다.

con-net2 대역을 사용하는 connet라는 컨테이너를 만들어준 후 network2의 bash창에서 ping을 날려보면 위와 같이 잘 통신되는 것을 확인할 수 있다.

또한, con-net2를 inspect해보면 컨테이너 목록에서 위와 같이 network2를 인지하고 있는 것을 확인할 수 있다.

rm을 이용하여 con-net2 브릿지를 삭제해보면 위와 같이 연결된 컨테이너 엔드포인트가 존재하여 불가능하다는 오류가 발생한다.

컨테이너와 브릿지의 연결은 disconnect 명령어로 진행할 수 있다.

con-net2에 연결되어 있던 conneet 컨테이너를 삭제해주면 con-net2 네트워크도 정상적으로 삭제가 진행되는 것을 볼 수 있다.