[도커]네트워킹

도커는 운영체제 수준 가상 소프트웨어를 활용하여 사용자가 모든 라이브러리 종속성이있는 도커 컨테이너에서 애플리케이션을 개발, 배포, 관리 및 실행할 수 있도록 지원하는 플랫폼이다. 도커 컨테이너는 애플리케이션을 실행하는 데 필요한 모든 종속성 (프레임 워크, 라이브러리 등)을 포함하는 독립 실행형 패키지다. 결국 프로세스를 분리해 독립적으로 실행될 수 있도록 하는 독립성이 도커의 본래 목적이다.

 

도커에서 네트워크는 도커 컨테이너에게 완전한 격리를 제공하기위해 사용된다. 도커 네트워킹의 장점은 아래와 같다.

1. They share a single operating system and maintain containers in an isolated environment.
- 단일 운영 체제를 공유하고 격리된 환경에서 컨테이너를 유지관리

2. It requires fewer OS instances to run the workload.
- 워크로드를 실행하는 데 필요한 OS 인스턴스가 적음

3. It helps in the fast delivery of software.
- 소프트웨어를 빠르게 전달할 수 있도록 도움

4. It helps in application portability.
- 애플리케이션 이식성에 도움됨

- Introduction To Docker Networking(참고4)

 

---

0. 네트워크 드라이버 종류

도커는 네트워크 드라이버를 통해 컨테이너에 대한 네트워킹을 지원한다. 제공되는 네트워크 드라이버의 종류는 Bridge, Host, None, Overlay, Macvlan의 5개다.

 

1) Bridge

- 기본(default) 네트워크 드라이버 → 드라이버를 지정하지 않으면 생성

- 일반적으로 통신이 필요한 독립 실행형 컨테이너에서 애플리케이션을 실행할 때 사용

 

→ 동일한 Docker 호스트에서 통신하기 위해 여러 컨테이너가 필요할 때 가장 적합함

 

2) Host

- 독립형 컨테이너의 경우 컨테이너와 Docker 호스트 간의 네트워크 격리를 제거하고 호스트의 네트워킹을 직접 사용(네트워크 정보를 공유)

- 컨테이너는 호스트의 입장에서 하나의 프로세스이기 때문에 네트워크 정보 공유 가능

- 컨테이너에서 사용하는 포트화 호스트에서 사용하는 포트는 서로 달라야 함

 

→ 네트워크 스택이 도커 호스트에서 격리되어서는 안되지만 컨테이너의 다른 측면을 격리하려는 경우에 가장 적합함

 

3) Overlay

- 서로 다른 도커 데몬을 함께 연결하고 swarm 서비스(클러스터 서비스)가 서로 통신 할 수 있도록 함 → 서로 다른 도커 호스트의 컨테이너가 통신할 수 있게 함

- 단일 호스트에는 사용하지 않음

- 컨테이너간에 OS 수준 라우팅을 수행 할 필요 없음

 

→ 통신을 위해 서로 다른 도커 호스트에서 실행되는 컨테이너가 필요하거나 여러 애플리케이션이 스웜 서비스를 사용하여 함께 작동 할 때 가장 적합함

 

4) Macvlan

- 컨테이너에 MAC 주소를 할당하여 네트워크에서 물리적 장치로 표시

- 도커 데몬은 MAC 주소를 기준으로 트래픽을 컨테이너로 라우팅

 

→ VM 설정에서 마이그레이션하거나 컨테이너가 각각 고유 한 MAC 주소를 가진 네트워크의 물리적 호스트처럼 보이도록해야 할 때 가장 적합함

 

5) None(Null)

- 모든 네트워킹을 비활성화

- 일반적으로 사용자 정의 네트워크 드라이버와 함께 사용

- 스웜(swarm) 서비스에는 사용할 수 없음

 

---

 

1. Bridge Network

 

브리지 네트워크는 동일한 도커 데몬 호스트에서 실행되는 컨테이너에 적용된다. 다른 도커 데몬 호스트에서 실행되는 컨테이너 간의 통신을 위해 운영체제 수준에서 라우팅을 관리하거나 오버레이 네트워크를 사용할 수 있다.

 

1) User-defined bridges vs default bridge

 

(1) User-defined bridges provide automatic DNS resolution between containers.

• 레거시로 간주되는 --link 옵션을 사용하지 않는 한 기본 브리지 네트워크의 컨테이너는 IP 주소로만 서로 액세스 할 수 있다.
• 사용자 정의 브리지 네트워크에서 컨테이너는 이름 또는 별칭으로 서로를 확인할 수 있다. 웹 프론트엔드와 백엔드가 존재하는 애플리케이션이 있다고 할 때, web 컨테이너와 db 컨테이너를 호출했을 때, web 컨테이너는 별다른 동작 없이 db 컨테이너에 있는 데이터베이스에 접근할 수 있다.
• 기본 브리지 네트워크에서 동일한 애플리케이션 스택을 실행하는 경우 컨테이너간에 링크를 수동으로 만들어야한다 (레거시 --link 플래그 사용). 이러한 링크는 양방향으로 생성되어야하므로 통신해야하는 컨테이너가 2개 이상이면 너무 복잡해질 수 있다. 또는 컨테이너 내에서 /etc/hosts 파일을 조작 할 수도 있지만 이로 인해 디버그가 어려워질 수 있다.

 

(2) User-defined bridges provide better isolation.

• --network가 지정되지 않은 모든 컨테이너는 기본 브리지 네트워크에 연결된다.
• 서로 관련없는 스택 / 서비스 / 컨테이너가 통신 할 수 있으므로 위험 할 수 있다.

 

(3) Containers can be attached and detached from user-defined networks on the fly.

• 컨테이너의 수명 주기 동안 사용자 정의 네트워크는 즉시 연결하거나 연결을 끊을 수 있다.
• 기본 브리지 네트워크에서 컨테이너를 제거하려면 컨테이너를 중지하고 다른 네트워크 옵션으로 다시 만들어야 한다.

 

(4) Each user-defined network creates a configurable bridge.

• 컨테이너가 기본 브리지 네트워크를 사용한다면, 네트워크 구성을 변경할 수는 있지만 모든 컨테이너들이 해당 설정(MTU, iptables 규칙 등)을 공유하게 된다. 게다가 기본 브리지 네트워크 구성을 변경하면 이는 도커 외부에서 발생하게 되므로 도커를 재시작을 요구한다.
• 사용자 정의 네트워크는 'docker network create'명령어를 사용해서 생성되고 구성된다. 따라서 각 컨테이너의 네트워크 구성을 별도로 설정할 수 있다.

 

(5) Linked containers on the default bridge network share environment variables.

• 원래 두 컨테이너간에 환경 변수를 공유하는 유일한 방법은 --link 플래그를 사용하여 연결하는 것이다. 이러한 유형의 변수 공유는 사용자 정의 네트워크에서는 불가능하다. 그러나 환경 변수를 공유하는 더 좋은 방법이 있다.
  • 여러 컨테이너가 도커 볼륨을 사용하여 공유 정보가 포함 된 파일 또는 디렉토리를 마운트 할 수 있다.
  • docker-compose를 사용하여 여러 컨테이너를 함께 시작할 수 있으며 compose 파일은 공유 변수를 정의 할 수 있다.
  • 독립형 컨테이너 대신 swarm 서비스를 사용하고 shared secret 및 config을 활용할 수 있다.
• 같은 사용자 정의 브리지 네트워크에 연결된 컨테이너들은 모든 포트를 서로에게 공개한다. 다른 네트워크에 연결된 타 컨테이너 또는 비 도커 호스트에서 해당 포트에 접근하려면, 포트는 -p 또는 --publish 플래그를 사용해야 한다.

 

2) Examples

# 사용자 정의 브리지 네트워크 생성 
$ docker network create my-net

# 사용자 정의 브리지 네트워크 삭제
$ docker network rm my-net

# 컨테이너에 사용자 정의 네트워크 연결 
$ docker create --name my-nginx \
  --network my-net \
  --publish 8080:80 \
  nginx:latest
  
# 현재 실행 중인 컨테이너에 사용자 정의 네트워크 연결 

$ docker network connect my-net my-nginx

# 사용자 정의 브리지 네트워크 연결 해제

$ docker network disconnect my-net my-nginx

# 외부로 포워딩 허용

$ sysctl net.ipv4.conf.all.forwarding=1
$ sudo iptables -P FORWARD ACCEPT

---

2. Host Network

 

• 컨테이너에 호스트 네트워크 모드를 사용하는 경우 해당 컨테이너의 네트워크 스택은 Docker 호스트에서 격리되지 않으며 (컨테이너는 호스트의 네트워킹 네임 스페이스를 공유 함) 컨테이너에 자체 IP 주소가 할당되지 않는다.  
  • 예를 들어 포트 80에 바인딩되는 컨테이너를 실행하고 호스트 네트워킹을 사용하는 경우 컨테이너의 애플리케이션은 호스트 IP 주소의 포트 80에서 사용할 수 있다.
• 호스트 모드 네트워킹은 성능을 최적화하는 데 유용 할 수 있으며, NAT (네트워크 주소 변환)가 필요하지 않고 각 포트에 대해 "userland-proxy"가 생성되지 않기 때문에 컨테이너가 광범위한 포트를 처리해야하는 상황에서 유용 할 수 있다.

 

---

3. Overlay Network

 

• 오버레이 네트워크 드라이버는 여러 Docker 데몬 호스트간에 분산 네트워크를 만든다. 이 네트워크는 호스트 별 네트워크의 상단(top, overlay)에 있으며, 암호화가 활성화되면 연결된 컨테이너 (스웜 서비스 컨테이너 포함)가 안전하게 통신 할 수 있다.
• 사용자 정의 브리지 네트워크를 생성하는 것과 동일한 방식으로 'docker network create'를 사용하여 사용자 정의 오버레이 네트워크를 생성 할 수 있다. 서비스 또는 컨테이너는 한 번에 둘 이상의 네트워크에 연결할 수 있고, 각각 연결된 네트워크를 통해서만 통신 할 수 있다.

 

---

4. Macvlan Network

 

일부 애플리케이션, 특히 네트워크 트래픽을 모니터링하는 레거시 애플리케이션 또는 애플리케이션은 물리적 네트워크에 직접 연결될 것으로 예상된다. 이러한 상황에서는 macvlan 네트워크 드라이버를 사용하여 각 컨테이너의 가상 네트워크 인터페이스에 MAC 주소를 할당하여 물리적 네트워크에 직접 연결된 물리적 네트워크 인터페이스처럼 보이게 할 수 있다. 이 경우 macvlan은 물론 macvlan의 서브넷 및 게이트웨이에 사용할 Docker 호스트의 물리적 인터페이스를 지정해야한니다. 다른 물리적 네트워크 인터페이스를 사용하여 macvlan 네트워크를 격리 할 수도 있다.

 

macvlan 네트워크를 사용할 때 주의할 점은 아래와 같다.

• 애플리케이션이 브리지 (단일 Docker 호스트에서) 또는 오버레이 (여러 Docker 호스트에서 통신)를 사용하여 작동 할 수 있다면 장기적으로 이러한 솔루션이 더 나을 수 있다.
• 네트워킹 장비는 하나의 물리적 인터페이스에 여러 MAC 주소를 할당하는 "무차별 모드(promiscuous mode)"를 처리 할 수 ​​있어야한다.
• IP 주소 고갈 또는 네트워크에 고유 MAC 주소가 부적절하게 많은 수의 상황인 'VLAN spread' 현상으로 인해 네트워크가 손상되기 매우 쉽다.

 

 

---

[참고]

1. "Networking overview", Docker Docs, https://docs.docker.com/network/
2. "docker network", Docker Docs, https://docs.docker.com/engine/reference/commandline/network/
3. "Introduction To Docker Networking", simplilearn, https://www.simplilearn.com/tutorials/docker-tutorial/docker-networking
4. "Use bridge networks", Docker Docs, https://docs.docker.com/network/bridge/
5. "Use overlay networks", Docker Docs, https://docs.docker.com/network/overlay/
6. "Use macvlan networks", Docker Docs, https://docs.docker.com/network/macvlan/