Docker

S6 Overlay


## Intro

여태까지 docker의 driver를 통한 networking 기술을 알아보았고, 이제 libnetwork로 1/3에서 제시했던 기본 routing과 같은 기능 외에 구현되어 있는 기능들에 대해서 알아봅니다.

- service discovery
- load balancing

## Service discovery

모든 container들과 swarm의 서비스들이 이름을 통해서 각 각을 찾을 수 있도록 하는 것이다. Docker는 자체적으로 내부의 DNS 서버를 이용하여 이를 수행한다. 과정을 요약하자면 다음과 같다.

1. container가 이름을 통해서 특정 container를 찾아야 함을 인식한다.
2. 먼저 Local 내부에서 이에 대한 정보를 갖고 있는지를 탐색한다. -> 있다면, 종료
3. Docker DNS server에 이를 요청하는 query를 전송한다.
4. Docker DNS server는 모든 container의 name과 network alias(별칭)를 알기 때문에 이를 찾을 수 있다.
5. 이때, DNS server는 먼저 동일한 network에 해당 container가 존재하는지를 확인한다. -> 없다면, 외부 DNS server로
6. 존재한다면, 이를 요청을 보낸 resolver에게 전달하고, 이게 다시 container로 전달된다.

## Load balancing

docker swarm은 기본적인 load balancer를 지원하여, 아래 그림과 같이 구현되어진다.

```bash
$ docker service create \
  --name my-web \
  --publish published=8080,target=80 \
  --replicas 2 \
  nginx
```

![docker-ingress-network](/images/docker-ingress-network.png)

즉, 어디로 요청을 보낸다고, 할지라도 load balancer는 어디에 해당 서비스가 존재하는지를 파악하고, 이를 전달하는 것이 가능해진다. 따라서, 어느 노드로 요청을 보내더라도 정상적으로 요청이 전달될 수 있는 것이다. 이를 Ingress load balancing이라고 부른다.

만약, 특정 node로 전달된 요청은 해당 node에 있는 container로 전달되기를 바란다면, host모드를 이용하여 진행할 수도 있다.

여기까지가 network에 대한 전반적이 내용입니다.

## Reference

- [🔗 Docker Deep Dive](https://www.oreilly.com/library/view/docker-deep-dive/9781800565135/), Nigel Poulton


[Docker] Network(3)


## Intro

저번 글에 이어서 이번에는 docker network의 driver들에 대한 자세한 내용을 다루겠다.

- bridge networks
- overlay networks
- host networking
- IPVlan networks
- MacVlan networks

## Bridge Network

container간의 통신을 위해서 필요한 것이 bridge 네트워크이다. 하지만, 여기서 주의해야할 것은 오직, single host에서만 동작한다는 점이다. 즉, 다른 docker host에 존재하는 container와는 연결이 불가능하다.

그렇다면, bridge가 무엇인가? 이는 두 개의 network 장치를 연결하는 L2 switch를 말한다. 즉, container를 연결하는 도구라고 보면 되겠다. 이를 통해서 연결된 container는 해당 container의 모든 port에 접근이 가능해진다.

![docker-bridge-network](/images/docker-bridge-network.png)

위는 `$ docker network ls`를 입력하면 기본적으로 볼 수 있는 내용이다. 위에 세개는 처음부터 끝까지 docker에 존재하는 default network입니다. host는 직접적으로 host에 연결하는 경우의 network이고,(후에 설명합니다.) none은 아무 네트워크에도 연결되지 않아 외부로 어떤 traffic도 보내지 않을 container들이 속하게 된다. 여기서 bridge는 default bridge라고 불리며, network를 설정하지 않고, container를 생성하게 되면 기본적으로 해당 bridge로 연결되게 된다. 이를 통해서 container 간의 연결도 구현하는 것이 가능하다.

하지만, 일반적으로 단일 기기에서 container 간의 연결을 수행할 때에는 bridge를 직접 생성하여 연결하는 것이 일반적이다. (그 이유는 도메인 네임 설정을 자동으로 해준다는 점에서 이점이 있기 때문 -> [🔗 참고](https://docs.docker.com/network/bridge/#differences-between-user-defined-bridges-and-the-default-bridge))

아래는 이를 이용한 간단한 예시이다.

```bash
# bridge 생성
$ docker network create -d bridge eui_bridge

# container 생성
$ docker container run -d --name c1 \
  -network eui_bridge \
  alpine sleep 1d
  
# container2 생성
$ docker container run -it --name c2 \
  -network eui_bridge \
  alpine sh
   
# ping을 통해 c1과 연결 여부 확인
$ ping c1
```

위의 과정을 처음부터 설명하자면,

1. eui\_bridge라는 network를 bridge로 생성한다.
2. container에 eui\_bridge를 연결하고, alpine 이미지를 기반으로 생성한다. 이때 시작 시에 sleep을 하루 동안 시행한다.(sleep 하는 이유는 꺼지지 않게 하기 위함)
3. 마찬가지로 eui\_bridge에 연결하고, alpine 이미지로 container를 생성한 후에 shell을 실행시킨다.
4. c2에서 실행된 shell에서 c1으로 ping을 전송한다. (이때 같은 network bridge끼리는 container name으로 domain이 생성된다.)

참고로 여기서 기억해야할 것이 있다면, bridge는 container간의 연결을 위한 것이고, container의 특정 port를 host와 mapping하고자 할 때에는 `--publish` 를 활용해야 한다.

```bash
$ docker run -p 5000:80 nginx
```

이를 통해서 host의 5000번과 container의 80번 port를 연결할 수 있다.

## Overlay Network

위에서 설명한 것이 단일 호스트 내부에서 container 간의 연결이었다면, 여러 host가 존재하는 cluster 환경에서 docker의 container간 통신을 위한 driver가 overlay이다. 현재에는 docker swarm을 통해서 application을 여러 host에서 제공하는 경우에 사용하게 된다.

먼저 원리를 알아보자면, VXLAN을 활용한다는 것이다. 이는 L3 network 상위에서 다른 두 기기 간에 L2 통신을 지원하는 것인데, 이를 통해서 우리는 다른 node간에 존재하는 container 끼리도 통신할 수 있도록 할 수 있다. docker swarm에 의해서 관리되어 L3로 연결된 두 node의 위에서는 VXLAN Tunnel EndPoint(VTEP)이 각 각 존재한다. 이들을 통해서, tunnel이 형성되고 통신이 가능해지는데, 기존에 container에 존재하고 있던 CNM에서 정의한 Sandbox 속에 virtual switch가 생성되고 이와 VTEP이 연결되어 다른 기기에 있는 container간에도 통신이 가능해지는 것이다.

예시를 든다면, docker stack을 통해서 시스템을 구성해본 적이 있다면, container를 생성하는 과정에서 network가 먼저 생성되는 것을 확인할 수 있을 것이다. 이때 생성되는 것이 overlay 네트워크로 이를 통해서 여러 container가 replica가 어느 node에 생길지 확정할 수 없음에도 통신을 자유롭게 하는 것을 볼 수 있다.

## Host Networking

해당 방식은 docker를 한 번이라도 써본 사람이라면 다음 명령어는 익숙할 것이다.

```bash
$ docker run -p 80:80 nginx
```

nginx image를 기반으로 container를 실행시키고, container 내부의 80번과 host의 80번 port를 mapping하겠다는 것이다. 이를 통해서 container는 host의 network에 관여하는 것이 가능하다.

하지만, host networking을 이용하게 되면 container 내부에 network stack이 생성되지 않고, 해당 container의 모든 network 설정이 해당 host의 설정에 그대로 mapping되는 것이다. 이를 이용하면 성능상의 이점은 있겠지만, 상당히 설정이 난잡해질 수 있다.

## IPVlan Network

MAC address와 IP adress를 부여하여, 실제 네트워크에 container를 직접 연결하는 방식이다.

장점은 별도의 port forwarding이나 bridge를 사용하지 않으므로 당연히 빠르지만, NIC를 이용하기에 promiscuous mode를 open해야 한다는 단점이 있다. 이는 switch가 데이터를 전송할 대상을 찾지 않고, 연결된 모든 대상에게 보내는 모드로, sniffing에 취약하고 이 때문에 public cloud system에서는 이를 막아 놓기에 사용할 수 없다.

![docker-ip-vlan](/images/docker-ip-vlan.png)
여기까지 말했을 때, 이해했다면, 이미 설정하는 것을 알아보러 떠나면 될 것이고, 이해하지 못했다면, 아마 쓸 일이 없을 것이니 넘어가시면 될 것이다.

자세한 사항은 공식 페이지를 참고하자.

[🔗 IPvlan networks](https://docs.docker.com/network/ipvlan/)

## MacVlan Network

ipvlan과 동일하지만 차이점은 MAC 주소를 할당한다는 점이다. 그 외에는 다를 것이 없다.

[🔗 macvlan networks](https://docs.docker.com/network/macvlan/)

## Reference

- [🔗 Docker Deep Dive](https://www.oreilly.com/library/view/docker-deep-dive/9781800565135/), Nigel Poulton


[Docker] Network(2)


## Intro

Docker Swarm을 docker stack을 이용하여 실행시키게 된다면, 무엇이 생성되는가? 우리는 서비스가 생성되기도 전에 network가 생성되는 것을 볼 수가 있다. container와 container간 그리고, host를 통해 외부 internet환경에 container를 연결 시키는 모든 과정을 알아보자.

Docker를 사용하다보면, host와 통신을 위해 외부로 port를 열어주는 것과 container 간의 통신을 헷갈려 하는 사람들이 생각보다 많은 것 같다. 심지어는 container간 통신을 위해서 localhost로 정보를 주고받을려고 하는 몹쓸 시도를 하는 관경도 몇몇 봐왔다.

따라서, 우리는 한 번 Docker의 network에 대해서 한 번 공부해보는 것이 좋을 것이다.

해당 차시에서는 우선 전체적인 docker network를 설명하는 기본적인 키워드를 알아볼 것이고,

2 차시에서는 주로 사용되는 docker network driver를 알아볼 것이고,

3 차시에서는 libnetwork의 핵심 기능 중 service discovery, load balancing에 대해서 알아보겠다.

## Docker Networking Base

우리가 기억해야 할 것은 CNM, libnetwork, Driver 이렇게 3가지다. 각 각이 무엇인지는 차례차례 알아보자.

### Container Network Model (CNM)

container간의 network를 구현하기 위한 design을 제시한 내용입니다. 따라서, idea일 뿐입니다. 자세한 내용은 하위 링크를 통해서 확인 가능합니다.

[🔗 Github - moby/libnetwork](https://github.com/moby/libnetwork/blob/master/docs/design.md)

하지만, 이를 좀 더 요약해봅시다. 일단 핵심 요소 3가지를 먼저 이해해봅시다.

- **Sandbox** : 고립된 하나의 Network 공간을 의미합니다. 해당 공간에는 ehternet interface나 port 그리고 routing table같은 구현이 포함됩니다.
- **Endpoints** : Virtual Network를 서로 연결하는 interface의 역할입니다. (veth라고도 불립니다.) CNM에서는 Sandbox 내부에서 이와 Network를 연결하는 역할을 합니다.
- **Networks** : Virtual Switch로 여기면 됩니다. 이를 통해서 여러 개의 endpoints를 연결할 수 있습니다.

자 이제 이렇게 3개의 네트워크를 정리하면, 이제 Container 내부에 Sandbox가 존재하고, 그 Sandbox 내부의 endpoints를 연결하는 Network를 통해서 결론적으로 Container 간의 연결을 수행하게 됩니다.

![cnm](/images/cnm.jpeg)

### libnetwork

위에서 이야기한 것처럼 CNM은 단순히 idea일 뿐입니다. 이를 구현허여 표준화된 것이 바로 libnetwork라고 생각하면 됩니다. 이는 Go를 이용하여 작성된 open source로 위에서 제시한 링크를 통해서 해당 open source에 접근할 수 있습니다. 위에서 언급한 CNM을 구현하였고, 추가적으로 service discovery, ingress-based container load balancing, network control plane 및 management plane 기능을 구현하였다. 현재에는 docker에서 network 구현에 사용된다.

\* control & management plane : 직접적으로 network의 흐름을 제어하는 단계로, routing과 같은 제어를 수행한다.

### Drivers

즉, libnetwork가 전체적인 network의 control plane과 management plane 기능을 구현하였다면, driver는 data plane을 구현한다. 즉, 직접적으로 데이터를 전달하는 역할을 수행한다. 이러한 기능들은 docker에서 여러 개의 driver라는 submodule을 통해서 구현하였다. docker pub를 통해서 default보다 나아간 driver 역시 설치가 가능하다. 하지만 기본적으로, host, bridge, overlay, ipvlan, macvlan 등을 포함하고 있다.

여기까지가 docker network에 대한 overview이다. 다음 차시에 계속...

## Reference

- [🔗 Docker Deep Dive](https://www.oreilly.com/library/view/docker-deep-dive/9781800565135/), Nigel Poulton
- Tumbnail : Photo by [Michael](https://unsplash.com/@michael75?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/cargo-ships?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)


[Docker] Network(1)


## Intro

해당 글은 Linux에서 docker를 동작시킨다는 가정하에 작성하였다. (Window도 대부분 동일하다고 한다.)

docker는 여러 개의 보안 정책을 포함한다.

이를 크게 누가 관리하느냐에 따라서 두 개의 부류로 나눌 수 있다.

1. OS system (Linux)
2. Docker

이전 가상화와 반가상화를 비교한 글에서 보았듯이 Container 기술을 결과적으로 반가상화에 해당하며, 이를 위해서 OS의 지원이 필요하다. 따라서, 이를 Linux 자체에서 구현해주는 것이 존재하고, Docker에서 Application 단에서 구현한 부분으로 나뉘어지는 것이다.

먼저, Linux에서 지원하는 각종 security에 대해서 알아봅시다.

## Linux's Security for Docker

전체적인 디테일 사항은 정리하지 않는다. 해당 내용은 간단히 살펴보는 정도이다.

### Namespaces

namespace는 container 기술에서 매우 핵심적인 위치에 존재한다고 할 수 있다. 이를 통해서, OS를 여러 개로 나누고, 마치 완전히 고립된 형태의 OS처럼 느끼도록 만든다. (키워드는 isolation) 그렇다면 하나의 host 내에서 어떻게 여러 개의 container가 완벽하게 독립되어 있다고 느낄 수 있게 할 수 있을까? 이는 다음과 같은 종류의 namespace를 분리함으로서 가능하다.

- **process ID (pid)** : process는 tree 형태로 이루어지게 된다. 따라서, 하나의 process (즉, PID 1)에 의해서 여러 개의 process가 동작을 시작하는 것이다. 그런데, namespace를 통해서 우리는 여러 개의 완벽하게 독립적인 process tree를 구축하게 된다.
- **Network (net)** : 각 각의 container마다 network stack을 구현한다. 즉, network interface 부터 시작해서, IP Address, port, routing table 등을 구축하게 되는 것이다.
- **Filesystem / mount (mnt)** :모든 container가 각자의 root filesystem을 가지고, 다른 모든 container들은 이것에 접근할 수 없다.
- **Inter process Communication(ipc)** : process간의 통신을 위해서 우리는 shared memory를 사용하게 되는데 이 또한 고립적으로 구현되도록 한다.
- **User** : 각 container마다 다른 user group을 구축하고 사용할 수 있도록 한다.
- **Unix Time sharing (uts)** : hostname을 container마다 제공하는 것으로, 이를 통해서 network 상에서 ip가 아닌 hostname으로 접근하는 것이 가능해진다.

즉, 해당 절에서는 이 한 마디를 기억하면 편해집니다. "하나의 Docker의 container는 namespace들의 집합으로 이루어져있다."

### Control Groups(C group)

namespace가 각 container간의 isolation을 보장한다면, cgroup은 한계를 설정하는 것이 역할이다. container들이 하나의 machine에서 동작한다면 어쩔 수 없이 그들이 사용할 수 있는 총 자원의 양은 한정될 수 밖에 없다. 그리고, 자칫 잘못하면 하나의 container가 너무 많은 자원(CPU, Memory, Storage, ...)을 소모하여 다른 container의 동작을 방해할 수 있다. 이를 막기 위한 것이 바로 cgroup이다. 이를 통해서 우리는 각 container에게 자원을 나누어 할당하는 것이 가능하다.

### Capabilities

어떤 작업을 하더라도, Machine을 root 권한으로 작업을 하는 것은 굉장히 위험하다. 따라서, container에서 application을 동작시키기 위한 최소한의 권한만을 부여하여 사용하는 것이 올바르다. 이를 수행할 수 있도록, 권한을 지정하는 것이 가능하다.

### Mandatory Access Control(MAC) system

MAC은 파일이나 특정 데이터에 대한 접근 제어를 수행하는 것을 의미한데, 이는 AppArmor나 SELinux 등에 의해서 구현되어지는데, 기본적으로 Docker는 container에 AppArmor를 각 container에 적용하여 이를 구현한다. customizing이 가능하지만, 이에 대한 이해를 충분히 하기를 권한다.

### seccomp

seccomp의 filter mode를 활용하면, container에서 발생하는 syscall을 제한하는 것이 가능하다. 이는 MAC 처럼 직접 customizing도 가능하지만 이에 대한 깊은 이해가 뒷받침되어야 한다.

## Docker Engine's Security for Docker

### Secure Swarm Mode

기본적으로 Docker Swarm은 manager와 worker로 구분되어 동작한다. manager는 기본적으로 control plane을 제어하고, 전체 적인 cluster 환경을 구성하며, 작업을 적절하게 전달한다. 그리고, 전체적인 application code를 동작시키는 것이 worker들이 수행하는 역할이다. 기본적으로 manager와 worker들은 모두 다른 Node이다. 따라서, 이들간의 통신을 수행할 때에 인증과 같은 작업을 필수적이다. 따라서, Docker Swarm에서는 이를 지원하기 위해서 manager로 임명된 node를 CA로 하여 TLS 인증을 수행한다. 이를 통해서, 서로를 인증하고, 전송 데이터 암호화를 수행한다.  
  
\* control plane vs data plane : 통신을 일상에서의 교통흐름이라고 본다면, control plane은 신호등과 같은 규칙을 의미하고, data plane은 실제로 이동하는 차량들로 비유할 수 있다. 즉, control plane은 cluster 환경에서의 제어를 위한 데이터이고, data plane은 실제로 주고 받는 데이터라고 볼 수 있다.

### Image Scanning

Docker는 이미지에서 보안상의 취약점 여부를 scan하는 기능을 기본적으로 탑재하고 있다. 이를 통해서, 이미지가 가진 취약점 등을 파악하는 것이 가능하다.

### Docker Content Trust

Docker는 download 또는 실행할 이미지의 제공자를 식별하고 무결성을 쉽게 체크할 수 있도록 하기 위해서 Docker Content Trust를 제공한다. registry에 이미지를 업로드할 때, 직접 서명이 가능하고, 이를 통해서 특정 사용자에 의해서 생성되었음을 확정할 수 있다. 이렇게 서명이 존재해야만 pull이 가능하도록 설정하는 것 역시 가능하다.

### Docker Secrets

Docker에서 보안 정보를 안전하게 보관하기 위해서 고안된 것으로, 특정 타겟에서 안전하게 SSH key와 같은 정보를 안전하게 전달하는 것 이 가능합니다.

## Reference

- [🔗 Docker Deep Dive](https://www.oreilly.com/library/view/docker-deep-dive/9781800565135/), Nigel Poulton
