2019.04.15 - Docker에서 네트워크가 돌아가는 방식, 컨테이너와 네트워크를 붙여주고 inspect 하는 방법, Docker에서 IP에 의존하면 안 되는 이유

1. Docker에서 네트워크가 돌아가는 방식

$ docker container port NAME
$ docker container inspect --format '{{ .NetworkSettings.IPAddress }}' NAME

<도커의 네트워크 다이어그램>

실제 사용하는 네트워크 - HOST(도커를 실행하는 노드) - ETHERNET < FIREWALL > - NETWORK BRIGDE - CONTAINER(s) - application(image)

눈 여겨 봐야 할 것은 호스트와 컨테이너 사이에 네트워크 브릿지가 있어서 이 브릿지를 통해 호스트와 컨테이너가 통신할 수 있다는 것이다.

네트워크 브릿지는 사용자가 임의로 추가할 수 있다.

같은 네트워크 브릿지를 사용하는 컨테이너들은 서로간의 통신이 자유롭게 가능하다.
하지만 네트워크 브릿지가 다른 컨테이너가 있다면 걔네들은 호스트를 거쳐서 통신해야 한다. (컨테이너1 -> host -> 컨테이너2.. 이렇게)

아 그리고 --publish 8080:80 or -p 8080:80 옵션의 의미를 명확히 알겠다.
호스트의 8080포트로 들어오는 패킷을 컨테이너의 80으로 넘긴다는 것이다.
그럼 네트워크 브릿지를 통해 80번 포트로 리스닝 중인 컨테이너로 패킷이 넘어갈테고
그 패킷을 적절한 서비스가 처리하게 되는 것이다.


2. 컨테이너와 네트워크를 붙여주기, 새로운 네트워크 만들기, 네트워크 inspect 하기


$ docker network ls : 현재 도커에서 돌아가는 네트워크 목록들이 나타난다
-> bridge(or docker0) : 네트워크 브릿지
-> host : 호스트에 바로 붙어있는 네트워크. 이걸 사용하면 높은 네트워크 퍼포먼스를 기대할 수 있지만 보안 이슈도 잘 생각해야한다.
-> none : 커스텀 가능한 넽워크

$ docker network inspect NETWORK_NAME : 해당 네트워크의 옵션을 검사한다.

$ docker network create NAME : NAME의 새로운 네트워크를 만들어낸다.
별다른 옵션을 주지 않으면 브릿지(디폴트)로 만들어내며 172.17...(17이 존재하면 18, 18이 존재하면 19..)의 사설 IP를 만들어낸다.

$ docker container run -d --name new_nginx --network my_app_net nginx : 이전처럼 컨테이너를 run하는 것인데 네트워크 옵션을 선택해준 모습이다.

$ docker network connect/disconnect [NETWORK_ID] [IMAGE_NAME or IMAGE_ID from another network]
-> 선택한 네트워크로 컨테이너의 서비스를 이전시킨다.
-> 이렇게 한 뒤 docker network inspect [NETWORK_ID]를 하면 container에 이미지가 넘어온 걸 볼 수 있다.
-> 디스커넥트는 당연히 그 반대.


3. Docker를 사용할 때 컨테이너의 IP에 의존하면 안 되는 이유


여태까지는 IP 주소를 가지고 연결을 하니마니 했는데 사실 도커 내에서 IP 주소를 그대로 쓰는건 안티패턴이다.
좋은 방법이 아니므로 최대한 피하도록 노력해야한다.
왜냐면 IP주소는 쉽게 바뀔 수 있기 때문에 여기에만 relying하는 것은 위험하다.
(도커에서 컨테이너를 stop 시켰다가 다시 start하면 IP가 바뀌기도 한다.)
따라서 이름으로 컨테이너간 통신(동일 호스트 위에서 혹은 다른 호스트 위에서)
도커는 호스트명으로 컨테이너 이름을 사용한다.