docker 네트워크 설정 방법 요약

docker가 시작되면 숙주 호스트에 docker0이라는 가상 네트워크 인터페이스를 만듭니다. 기본값은 172.17.42.1/16입니다. 16개의 서브넷 마스크는 용기에 65534개의 IP 주소를 제공합니다.docker0은 이 위에 연결된 다른 네트워크 카드 사이에서 데이터 패키지를 자동으로 전송하는 가상 이더리움 브리지입니다. 용기와 호스트가 서로 통신하고 용기와 용기가 서로 통신할 수 있습니다.문제는 서로 다른 호스트에 있는 도커 용기가 통신할 수 있도록 하는 것이다.docker 네트워크를 어떻게 효과적으로 설정하는지는 현재로서는 비교적 복잡한 작업이기 때문에 flannel,Kubernetes,weave,pipework 등 많은 개원 프로젝트가 생겨났다.
 
1. flannel 
 
CoreOS팀은 etcd 기반 덮어쓰기 네트워크 (overlay network) 를 제작하여 호스트마다 독립된 서브넷 서비스를 제공합니다.Rudder는 집단에서 Docker 용기의 네트워크 설정을 간소화하고 여러 호스트에서 용기 서브넷 충돌 문제를 피하며 포트 매핑 방면의 작업을 대폭 줄일 수 있다.구체적인 코드는 https://github.com/coreos/flannel이고 그 작업 원리는 다음과 같다.
 
An overlay network is first configured with an IP range and the size of the subnet for each host. For example, one could configure the overlay to use 10.100.0.0/16 and each host to receive a/24 subnet. Host A could then receive 10.100.5.0/24 and host B could get 10.100.18.0/24. flannel uses etcd to maintain a mapping between allocated subnets and real host IP addresses. For the data path, flannel uses UDP to encapsulate IP datagrams to transmit them to the remote host. We chose UDP as the transport protocol for its ease of passing through firewalls. For example, AWS Classic cannot be configured to pass IPoIP or GRE traffic as its security groups only support TCP/UDP/ICMP.(https://coreos.com/blog/introducing-rudder/)
 
2. Kubernetes
 
Kubernetes는 Google이 내놓은 용기 관리 및 편성을 위한 소스 오픈 프로젝트로 용기 호스트 클러스터 내에서 용기화 응용 프로그램의 배치를 쉽게 관리, 모니터링, 제어할 수 있습니다.Kubernete는 SDN과 매우 비슷한 특수한 네트워크화 개념을 가지고 있다. 하나의 서비스 에이전트를 통해 임의의 용기에 분배할 수 있는 IP 주소를 만들고, 전방의 응용 프로그램이나 이 서비스를 사용하는 사용자는 이 IP 주소를 통해서만 서비스를 호출할 수 있으며, 그의 세부 사항에 신경 쓸 필요가 없다.이런 에이전트 방안은 약간 SDN의 맛이 있지만 전형적인 SDN의 2-3층 메커니즘 위에 세워진 것은 아니다.
 
Kubernetes uses a proxying method, whereby a particular service — defined as a query across containers — gets its own IP address. Behind that address could be hordes of containers that all provide the same service — but on the front end, the application or user tapping that service just uses the one IP address.
This means the number of containers running a service can grow or shrink as necessary, and no customer or application tapping the service has to care. Imagine if that service were a mobile network back-end process, for instance; during traffic surges, more containers running the process could be added, and they could be deleted once traffic returned to normal. Discovery of the specific containers running the service is handled in the background, as is the load balancing among those containers. Without the proxying, you could add more containers, but you’d have to tell users and applications about it; Google’s method eliminates that need for configuration. ( https://www.sdncentral.com/news/docker-kubernetes-containers-open-sdn-possibilities/2014/07/ )
 
3. 서로 다른 숙박 호스트의 모든 용기에 같은 네트워크 구간의 IP 주소를 설정하기 위해 설정하는 방법은 http://www.cnblogs.com/feisky/p/4063162.html이다. 이 글은 Linuxbridge를 바탕으로 한 것이다. 물론 OpenvSwitch+GRE로 숙박 호스트 간의 연결을 구축할 수도 있다.
 
# From http://goldmann.pl/blog/2014/01/21/connecting-docker-containers-on-multiple-hosts/ 
# Edit this variable: the 'other' host.
REMOTE_IP=188.226.138.185
 
# Edit this variable: the bridge address on 'this' host.
BRIDGE_ADDRESS=172.16.42.1/24
 
# Name of the bridge (should match/etc/default/docker).
BRIDGE_NAME=docker0
 
# bridges
 
# Deactivate the docker0 bridge
ip link set $BRIDGE_NAME down
# Remove the docker0 bridge
brctl delbr $BRIDGE_NAME
# Delete the Open vSwitch bridge
ovs-vsctl del-br br0
# Add the docker0 bridge
brctl addbr $BRIDGE_NAME
# Set up the IP for the docker0 bridge
ip a add $BRIDGE_ADDRESS dev $BRIDGE_NAME
# Activate the bridge
ip link set $BRIDGE_NAME up
# Add the br0 Open vSwitch bridge
ovs-vsctl add-br br0
# Create the tunnel to the other host and attach it to the
# br0 bridge
ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre options:remote_ip=$REMOTE_IP
# Add the br0 bridge to docker0 bridge
brctl addif $BRIDGE_NAME br0
 
# iptables rules
 
# Enable NAT
iptables -t nat -A POSTROUTING -s 172.16.42.0/24 ! -d 172.16.42.0/24 -j MASQUERADE
# Accept incoming packets for existing connections
iptables -A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# Accept all non-intercontainer outgoing packets
iptables -A FORWARD -i docker0 ! -o docker0 -j ACCEPT
# By default allow all outgoing traffic
iptables -A FORWARD -i docker0 -o docker0 -j ACCEPT
 
# Restart Docker daemon to use the new BRIDGE_NAME
service docker restart
 
4.weave를 사용하여 용기에 IP 설정 (사용방법은 http://www.cnblogs.com/feisky/p/4093717.html 참조),weave의 특성은

응용 격리: 서로 다른 서브넷 용기 간에 기본적으로 격리되어 같은 물리적 기기에 있어도 서로 통하지 않는다.서로 다른 물리적 기기 사이의 용기도 기본적으로 격리된

물리적 시스템 간 컨테이너 호환: weave connect $OTHERHOST

동적 네트워크 추가: weave를 통해 시작하지 않은 용기에 대해 weave attach 10.0.1.1/24$id를 통해 네트워크 추가(detach 네트워크 삭제)

보안: weave launch -password wEaVe를 통해 weave peers 간 암호화 통신에 사용할 비밀번호를 설정할 수 있습니다

과 숙박 호스트 네트워크 통신: weave expose 10.0.1.102/24, 이 IP는 weave 브리지에

weave 라우팅 상태 보기: weave ps

NAT를 통한 외부 네트워크 액세스 docker 컨테이너

 
5. 호스트 docker의 기본 가상 구역을 수정한 다음에 각 호스트에 각각 상대방의 docker 구역을 루트 테이블에 추가하고 IPtables에 맞추면 docker 용기 과장 호스트 통신을 실현할 수 있다.구성 방법은 다음과 같습니다.
 
가상 머신 2대 설치

v1: 192.168.124.51

v2: 192.168.124.52

VM docker0 세그먼트 변경, v1 172.17.1.1/24, v2 172.17.2.1/24
＃v1

sudo ifconfig docker0 172.17.1.1 netmask 255.255.255.0
sudo bash -c 'echo DOCKER_OPTS="-B=docker0" >> /etc/default/docker'
sudo service docker restart

# v2
sudo ifconfig docker0 172.17.2.1 netmask 255.255.255.0
sudo bash -c 'echo DOCKER_OPTS="-B=docker0" >> /etc/default/docker'
sudo service docker restart

 
그리고 v1에서 v2의 docker 가상 구역을 루트 테이블에 추가하고 v2에서 v1의 docker 가상 구역을 자신의 루트 테이블에 추가합니다

# v1 192.168.124.51
sudo route add -net 172.17.2.0 netmask 255.255.255.0 gw 192.168.124.52
sudo iptables -t nat -F POSTROUTING
sudo iptables -t nat -A POSTROUTING -s 172.17.1.0/24 ! -d 172.17.0.0/16 -j MASQUERADE

# v2 192.168.124.52
sudo route add -net 172.17.1.0  netmask 255.255.255.0  gw 192.168.124.51
sudo iptables -t nat -F POSTROUTING
sudo iptables -t nat -A POSTROUTING -s 172.17.2.0/24 ! -d 172.17.0.0/16 -j MASQUERADE

이로써 두 가상 기기의 docker 용기가 서로 접근할 수 있게 되었다.