Docker 는 기능 뿐 아니라 가이드 문서도 꾸준히 버전업 하고 있음.
년초를 맞아 Docker 가이드 문서를 다시 살펴볼 수 있는 기회가 있었음.
눈에 띈 내용을 요약함

 

Docker 어플리케이션 개발자를 위한 베스트 프랙틱스

출처: https://docs.docker.com/develop/dev-best-practices/

어플리케이션 데이터를 어디에 저장해야 하나

  • 어플리케이션 데이터를 Docker Storage (컨테이너에 할당된 디폴트 파일 시스템)에 저장하지 마라
  • 대신, 도커 Volumes 를 사용하라
  • 만약 상황이 적절하다면, 도커 Bind mount 도 괜찮다
  • Swarm Service 를 운영할 경우, 민감한 데이터는 Secrets 를 이용하라 (민감하지 않은 데이터는 Configs 를 이용하라)

 

개발환경과 운영환경의 차이

개발환경 운영환경
소스코드를 Bind mount 에 저장해서 이용하라 소스코드를 Volumes 에 저장해서 이용하라
호스트 사이의 시간 오차에 신경 쓸 필요 없다 모든 도커 호스트에 NTP 서버를 설정해서 시간을 맞춰 운영하라

 

도커 네트워크 드라이버 요약

출처: https://docs.docker.com/network/

도커 네트워크 드라이버 요약

Bridge network * 1개 호스트에서 여러개의 컨테이너들 사이의 통신이 필요할 때 적절한 선택
Host network

* 컨테이너 네트워크와 호스트 네트워크가 격리될 필요가 없을 때 적절한 선택

* 네트워크 성능 최적화가 필요할 때 적절한 선택

Overlay network

* 여러개 호스트들 사이에서 컨테이너들 사이의 통신이 필요할 때 적절한 선택

* 여러개의 컨테이너들을 Swarm Service 로 묶어서 운영할 때 적절한 선택

Macvlan network

* VM 방식에서 컨테이너 방식으로 이전할 때 고려할 수 있는 선택

* 컨테이너에 고유한 MAC 주소를 할당함

3rd party network plugins * 기타 다양한 네트워크 플러그인 사용 가능함

네트워크 성능 최적화가 필요한 Hyperledger Fabric 운영의 경우, Host network 모드 사용을 검토해볼만 함

 

어플리케이션 데이터 다루기

출처: https://docs.docker.com/storage/

  • Volumes : 어플리케이션 데이터를 도커가 관리하는 파일시스템 영역에 저장 (가장 권장하는 방식)
  • Bind mounts : 어플리케이션 데이터를 호스트 파일시스템에 저장 (조건만 맞는다면 괜찮은 방식)
  • tmpfs : 어플리케이션 데이터를 호스트 메모리에(만) 저장 (데이터를 호스트 파일시스템에 절대 저장하지 않으므로 기밀성이 좋다)

 

기타 팁

편리한 docker prune 명령 (컨테이너, 네트워크, 이미지, 캐시와 함께 Volume 까지 한꺼번에 정리)

$ docker system prune --volumes
WARNING! This will remove: 
        - all stopped containers 
        - all networks not used by at least one container 
        - all volumes not used by at least one container 
        - all dangling images 
        - all build cache 
Are you sure you want to continue? [y/N] y

 

(이상)

Posted by ingeeC
,

docker prune 명령 요약

  • docker system prune -f
    • 종료된(exit 상태의) docker container들을 모두 내리고, 쓸모 없는 image (dangling image)들을 제거

  • docker volume prune -f
    • 참조되지 않는 (현재 사용하지 않는) docker volume을 제거
    • volume의 life-cycle과 container의 life-cycle은 별개, 따라서 컨테이너가 종료되어도 컨테이너가 쓰던 볼륨은 스토리지에 남아 있게 된다.
    • 스토리지 공간이 모자라 골치 아픈 시스템 관리자에게 매우 유용한 명령

  • docker network prune -f
    • 현재 사용하지 않는 docker network 제거


마이크로 팁, 끝.


Posted by ingeeC
,

도커 운영 중, 호스트 머신의 스토리지가 가득찼을 때


현상

docker storage를 충분한 크기로 적절히 설정하고 운영함에도 host 머신의 스토리지가 full 되는 경우가 있다.

# df Filesystem Size Used Avail Use% Mounted on /dev/vda1 10G 3.9G 6.2G 39% / /dev/vdc1 10G 10G 0 100% /var /dev/vdd1 100G 7.5G 93G 8% /home ...


설명

  • /var/lib/docker/containers/ 디렉토리 아래, <container-id>/<container-id>-json.log 파일이 스토리지를 모두 차지했을 수 있다
  • 이 파일은 도커가 docker logs 명령 실행시 출력할 로그를 저장하는 파일이다 (docker storage에 저장되지 않고 host 머신의 파일 시스템을 소진한다)
  • 도커 실행시 max-size 옵션을 설정하면 로그 파일의 크기를 제한할 수 있다
  • 도커 실행시 max-file 옵션을 설정하면 로그 파일의 개수를 제한할 수 있다 (log rotate 효과)

해법

$ sudo vi /etc/docker/daemon.json
...다음 내용 추가...
{
  "log-driver": "json-file",
  "log-opts": {
    "mode": "non-blocking",
    "max-size": "4m",
    "max-file": "3"
  }
}

$ sudo systemctl restart docker

Ref


Posted by ingeeC
,

Docker Storage 이해

Ops 2018. 10. 15. 14:15

2018.10.15 덧붙임

컨테이너 안에서 파일을 저장하려면 data volume을 이용하는 것이 좋다 (강력히 권장. data volume 사용이 애매하면 mount volume도 권장).

  • 컨테이너 안에서의 파일 I/O는 storage driver에 의해 처리되며, 이는 일반 file I/O보다 큰 오버헤드를 감수해야 한다 (CoW 처리 때문)
  • 하지만, data volume 을 이용한 (컨테이너 안에서의) 파일 I/O는 storage driver를 우회하여 처리되며, host 머신의 file I/O와 동일한 속도로 처리된다
  • data volume (또는 mount volume)을 이용하려면 docker run 명령으로 컨테이너를 실행할 때, -v 옵션으로 볼륨을 지정하면 된다



2016.12.16 덧붙임

  • 도커는 원래 Ubuntu에서 개발, Ubuntu의 파일 스토리지 시스템은 AUFS
  • Red Hat 계열 배포판 (RHEL, CentOS, ...)에는 AUFS가 존재하지 않음
  • Red Hat 계열 리눅스를 위해, 도커는 Device Mapper를 2번째 Storage Backend로 수용함
  • Red Hat 계열 리눅스에 도커를 설치하면, Device Mapper가 도커의 Storage Backend로 동작 (loop-lvm)
  • 만약, 도커를 상용 수준으로 운영하려면, Device Mapper를 loop-lvm(디폴트)가 아닌 direct-lvm으로 설정/운영해야 함
  • loopback device (loop-lvm)는 상용 서비스를 처리하기엔 성능이 너무 안 좋음 (https://forums.docker.com/t/loopback-storage-devices/22007/2)



2016.01.29 원글

Q: 도커를 쓸 때 궁금했다
- 도커허브에서 가져온 도커 이미지는 어디에 저장되는 걸까?
- 도커 컨테이너 안에 write 하는 데이터는 어디에 저장되는 걸까?

A: 알고보니, <도커 스토리지>에 저장됐다
- <도커 이미지>는 layer 구조를 갖는다
- <도커 컨테이너>의 데이터는 CoW (Copy On Write) 정책에 따라 저장된다
+ RHEL/ CentOS/ Fedora 에서는 <도커 스토리지> 설정 작업이 필요하다 (Device Mappr)
  - 디폴트 스토리지는 loopback 장치
  - 안정적이지 않음
- Ubuntu는 도커 패키지 설치후 도커 스토리지 설정 없이 그냥 써도 좋다 (AUFS)

도커 스토리지 설정 스크립트 (@RHEL/ CentOS/ Fedora)
0. su
  $ su
1. volume이 정상적으로 준비되어 있는지 확인
  # fdisk -l
  - 사용하지 않는 /dev/vdc 장치 존재 확인
2. docker-storage-setup 설정 파일 수정
  # cat <<EOF > /etc/sysconfig/docker-storage-setup DEVS=/dev/vdc VG=docker-vg EOF
3. docker-storage-setup 명령 실행
  # docker-storage-setup
  ...
  Physical volume "/dev/vdc1" successfully created
  Volume group "docker-vg" successfully created
  Rounding up size to full physical extent 16.00 MiB
  Logical volume "docker-poolmeta" created.
  Logical volume "docker-pool" created.
  ...

Ref
- (추천!) Understand images, containers, and storage drivers
  https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
- Docker and the Device Mapper storage driver
  https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/
- Comprehensive Overview of Storage Scalability in Docker
  http://developerblog.redhat.com/2014/09/30/overview-storage-scalability-docker/

(이상)

Posted by ingeeC
,

도커 "WARNING: bridge-nf-call-iptables is disabled" 워닝 없애기


현상

docker info 명령을 실행했을 때 "bridge-nf-call-iptables is disabled" 워닝이 뜨는 경우가 있다.
$ docker info
...
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

의미

  • CentOS 같은 리눅스 배포판은 net.bridge.bridge-no-call-iptables 값이 디폴트 0 (zero)다
  • 이는 bridge 네트워크를 통해 송수신되는 패킷이 iptables 설정을 우회한다는 의미다
  • 컨테이너의 네트워크 패킷이 호스트머신의 iptables 설정에 따라 제어되도록 하는 것이 바람직하며 이를 위해서는 이 값을 1로 설정해야 한다

해법

$ sudo vi /etc/sysctl.conf ...다음 내용 추가... net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1

$ sudo sysctl -p


Ref


Posted by ingeeC
,

Dockerfile 베스트 프랙티스

https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices


* 컨테이너는 쉽게 죽고 살 수 있어야 한다 (Containers should be ephemeral )
  수시로 파괴되고 생성되어도 정상 동작해야 한다


* .dockerignore 파일을 활용하라 (Use a .dockerignore file)
  - docker build 디렉토리에 파일이 많아지면 안좋다
    . build 된 이미지가 커진다
    . biuld 작업이 느려진다
  - .dockerignore 파일로 관련 없는 파일들을 무시하게 하라


* 컨테이너의 목적을 (하나만) 분명히 하라 (Each container should have only one concern)
  - 하나의 어플리케이션을 여러개의 컨테이너로 나누는 편이
    <horizontal-scaling>과 <컨테이너-이미지 재활용> 측면에서 좋다


* layer 수를 줄여라 (Minimize the number of layers)
  - 이미지의 레이어 수를 줄이는 것이 좋다
  - RUN, COPY, ADD 명령이 레이어를 만든다


* Dockerfile 명령어 관련 조언
  - FROM
    . 항상 공식 이미지를 base 이미지로 사용하라


  - RUN
    . apt-get update와 apt-get install은 항상 한줄로 묶어 사용하라
    . apt-get install 시 패키지의 버전을 명시하면 잠재적인 오류를 줄일 수 있다
    . RUN 명령 모범 사례
      RUN apt-get update && apt-get install -y \
        aufs-tools \
        automake \
        build-essential \
        curl \
        dpkg-sig \
        libcap-dev \
        libsqlite3-dev \
        mercurial \
        reprepro \
        ruby1.9.1 \
        ruby1.9.1-dev \
        s3cmd=1.1.* \
        && rm -rf /var/lib/apt/lists/*


  - EXPOSE
    . 전통적인 포트 사용을 권한다
      예를 들어, 아파치 웹서버는 EXPOSE 80,
      MongoDB는 EXPOSE 27017


  - ADD or COPY
    . ADD 보다 COPY 를 권한다 (더 단순하다/직관적이다)
    . 여러 파일들을 한꺼번에 COPY 하는 것보다 파일별로 COPY 하는 것을 권한다
      그러면, 어떤 파일이 바뀌었을 때 캐시-이미지를 활용할 가능성이 커진다


(이상)

Posted by ingeeC
,

k8s vs swarm 비교 요약

비교항목 Kubernetes
Swarm
설치
△ (열위)
Docker 설치 후,
k8s 추가 설치 필요
O (우위)
Docker만 설치하면 끝

미세 조정
(fine control)
O (우위)
클러스터 미세 조정 가능
(pod, replica-set,
deployment, service 등
세밀하게 구분된 객체 제공)
△ (열위)
미세 조정 미흡
(service 객체만 제공)


성능
container
life-cycle 관리
O (동등)
deploy, scale, update
O (동등)
deploy, scale, update
container
rolling-update
O (우위)
7초
△ (열위)
117초
node fail 복구
△ (열위)
304초
O (우위)
21초
사용 소감
* Flexible
* 신뢰성이 높고 유연함
* 현시점에서 가장 적합한 선택
* Simple
* 리소스 사용량이 작고 빠름
* 특수 상황에 적합한 선택


솔루션 특징 요약
k8s
  * 주요 resource
    - pod 객체
      . 컨테이너 집합
      . k8s의 실행 단위 (스케줄링 단위)
    - deployment 객체
      . pod 배포를 담당하는 자원
      . pod 인스턴스 수를 관리하는 replica-set 자동 생성
      . pod 인스턴스에 대한 rolling-update 관리
    - service 객체
      . pod 집합을 고정된 end-point로 관리
  * declarative configuration
    - desired-state를 선언(declare)하면 k8s가 클러스터의 current-state를 desired-state로 맞추기 시작
    - kubectl edit 명령이 유용


swarm
  * 주요 resource
    - docker engine swarm mode에는 pod, replica-set 등의 객체가 없고, service 객체만 존재
    - service
      . service는 1개 이상의 container로 구성되며,
        service 생성시 옵션 파라미터를 사용하여 replica 갯수를 지정
  * imperative configuration
    - 클러스터 상태 변경 명령을 내리면 즉시 반응 (장점 아님)

공통점 & 차이점
  . k8s와 swarm 모두 master가 죽어도 pod/service/overlay-network의 동작/연결은 유지됨
  . k8s는 delarative configuration, swarm은 imperative configuration
    즉, admin이 컨테이너 인스턴스를 100개 -> 10개로 지정하는 명령을 내렸을 경우
    - k8s는 중간 상태인 100개를 건너뛰고 최종 상태인 10개에 도달하는 방식
    - swarm은 100개 상태를 거쳐 10개 상태에 도달하는 방식

성능 테스트 결과

테스트 종류 Kubernetes Swarm
Container
Life-cycle
Mgmt.
컨테이너 생성
- 컨테이너 생성 시간 측정
- master x1, node x3
10개 생성
2.3초
3:4:3
7.0초
4:3:3
50개 생성
11.6초
17:17:16
14.3초
17:16:17
100개 생성
27.8초
34:33:33
22.2초
33:33:34
200개 생성
83.2초
66:67:67
63.2초
66:67:66 (?)
200개 with 4 node
59.1초
50:50:50:50
41초
50:50:50:50
300개 with 4 node
실패
(자원 부족)
70초
75:75:75:75
Scaling:
- 1개 컨테이너를 100개로 scaling
- master x1, node x4
25.3초
25:25:25:25
26.4초
25:25:25:25
Rolling Update:
- 어플리케이션 중단 없이 컨테이너 이미지 교체
- 컨테이너 인스턴스 10개가 동작하는 상황
- master x1, node x4
7.1초
3:2:2:3
117초
Cluster
Mgmt.
node fail 대처:
- 4개 node가 동작중인 상황에서
- 1개 node를 power-off,
- 제거된 node에서 실행되던 컨테이너가
다른 node로 이동/복구되는 시간을 측정
304.8초
33:33:34
21초


k8s vs swarm 테스트 스크립트 비교

테스트 종류
Kubernetes 명령 스크립트
Swarm 명령 스크립트
컨테이너 생성
$ kubectl create -f deploy.yaml
$ docker service create
--name hello-nodejs
ingee/hello-nodejs:0.2
Scaling
$ kubectl scale
--replicas=10
deploy hello-nodejs
$ docker service update
--replicas 10
hello-nodejs
Rolling Update
$ kubectl set image
deploy hello-nodejs
hello-nodejs=ingee/hello-nodejs:0.2
$ docker service update
--images ingee/hello-nodejs:0.2
hello-nodejs


(이상)

Posted by ingeeC
,

Docker networking and service discovery 요약
  * <https://www.oreilly.com/learning/docker-networking-service-discovery>
  * 2016-04-11
  * 저자는 Mesosphere 엔지니어, 편향된 의견이 있을 수 있음

개요
  * 도커 네트워킹과 서비스 디스커버리는 신규 영역이라 Best Practice 가 적다
  * 도커 네트워킹과 서비스 디스커버리 표준이 정립되려면 몇년 더 있어야할 것 같다

도커 네트워킹
  * 도커 네트워킹은 컨테이너를 위한 SDN 솔루션
  * 도커 네트워킹이 해결해야 하는 문제
    - 서로 다른 host에서 실행되는 컨테이너들끼리 어떻게 연결/통신하게 하나?
    - 컨테이너와 외부세계(인터넷)가 어떻게 연결/통신하게 하나?
    - 클러스터 내부의 상태 (IP 할당 등)를 어떻게 유지하나?
    - 기존 네트워크 인프라에 어떻게 통합하나?
    - 보안정책을 어떻게 적용하나?
  * 도커 네트워킹 솔루션
    - Overlay
      . 도커사는 2015년 3월 SDN 스타트업 SocketPlane을 인수
      . SocketPlane의 솔루션을 Docker Overlay Driver라고 명명
      . 도커 bridge mode 네트워크를 클러스터 레벨로 확장
      . Docker Swarm에 적용 (도커 버전 1.9+)
    - Flannel
      . 모든 컨테이너(pod)는 고유한 IP 주소로 통신 가능
      . k8s에 적용
    - 그밖에 Weave, Project Calico, Open vSwitch, Pipework, OpenVPN 등 존재

서비스 디스커버리 & 로드 밸런싱
  * 서비스 디스커버리
    - 컨테이너 스케줄링과 서비스 디스커버리는 동전의 양면
      . 두 기능은 반드시 동행하며,
      . 서로가 서로를 필요로 함
    - 서비스 디스커버리란?
      . 특정 컨테이너가 어느 host에서 실행되는지 알아내는 솔루션
      . register 기능과 lookup 기능으로 구성
    - 서비스 디스커버리는 로드 밸런싱과 밀접한 관계가 있다
    - 100~1000+ node 규모의 클러스터라면 서비스 디스커버리 부하 테스트 필요
    - 서비스 디스커버리 솔루션
      . Zookeeper : 검증된 솔루션, 설치가 어렵다는 평
      . etcd : 경량 솔루션
      . Consul
      . 기타 Mesos-DNS, SkyDNS, WeaveDNS 등
  * 로드 밸런싱
    - 로드 밸런싱으로 달성할 수 있는 것
      . throughput 최대화, response time 최소화
      . 특정 컨테이너에만 부하가 집중되는 것(hotspotting)을 방지
    - 도커 로드 밸런싱 솔루션
      . NGINX : 서비스 디스커버리 솔루션과 정합성 좋음
      . HAProxy : 도커사가 솔루션을 인수, 향후 도커의 네이티브 솔루션이 될 전망
      . Bamboo
      . Kube-Proxy : k8s에 적용

컨테이너 오케스트레이션
  * 스케줄링은 중요, 하지만 오케스트레이션의 일부일 뿐
  * 스케줄러는 컨테이너를 클러스터 위에서 배포/실행(deploy)하는 역할
  * 스케줄러가 deploy target node를 선택하는 기준
    - 머신의 사용 현황
    - app 실행에 필요한 자원 요구사항
    - app 실행 조건(constraint)
      . ex) SSD 가 설치된 머신에서 실행
  * 오케스트레이션 솔루션별 스케줄러 특성
    - Docker Swarm
      . Swarm의 스케줄러는 pluggable (다른 스케줄러로 교체 가능)
      . HA 기능 제공 (아직은 불완전하다는 평, 개발중)
    - Kubernetes
      . 구글의 10년 노하우를 결집
      . 모든 컴포넌트가 교체 가능


  * 오케스트레이션 솔루션 비교
    - 노드 규모에 따른 적합도

  Tool       | ~10 nodes | 10~100 nodes | ~1,000 nodes | 1,000+ nodes
-------------+-----------+--------------+--------------+--------------
Docker Swarm |    ++     |    +         |    ?         |    ?
-------------+-----------+--------------+--------------+--------------
Kubernetes   |    ++     |    ++        |    +         |    ?
-------------+-----------+--------------+--------------+--------------
Apache Mesos |    +      |    ++        |    ++        |    ++

    - 워크로드 종류에 따른 적합도

             | non-      |           |       | Long-   |           |

  Tool       | Container | Container | Batch | running | Stateless | Stateful
-------------+-----------+-----------+-------+---------+-----------+---------
Docker Swarm |  -        |  ++       |  +    |  ++     |  ++       |  +
-------------+-----------+-----------+-------+---------+-----------+---------
Kubernetes   |  -        |  ++       |  +    |  ++     |  ++       |  +
-------------+-----------+-----------+-------+---------+-----------+---------
Apache Mesos |  ++       |  ++       |  ++   |  ++     |  ++       |  +


(이상)

Posted by ingeeC
,

Kubernetes, Mesos DC/OS, Docker(Swarm) 비교

 

Kubernetes

Mesos DC/OS

Docker Swarm

특징

가장 안정적인 솔루션
.
다양한 테스트 시도를 모두 만족시킴

가장 화려한 솔루션
. UI
수준이 높고 기능이 풍부함

가장 쉬운 솔루션
.
새로 배울 개념과 도구가 거의 없음

운영 가능한 host 머신 수

1,000 node

10,000 node

1,000 node

라이선스 모델

아파치

아파치

아파치

버전 히스토리

v1.3.6 (latest, 2016-08-27)
v1.0 (2015-06-18)
v0.2 (2014-09-09)

v1.8 (latest, 2016-08-04)
2016.4
월 오픈소스화

v1.2.5 (latest, 2016-08-18)
v1.0 (2015-11-03)
v0.1 (2015-02-26)

Managed Service

Google Container Engine (구글)

Azure Container Service (MS)

Docker Cloud (도커)

비고

. 기술자료 풍부
. CNCF
와 긴밀히 협조

* CNCF: Cloud Native Computing Foundation

. 기술자료 부족
. MS
Mesosphere가 적극 드라이브

. 기술자료 풍부
.
개념/기능의 간결함이 인상적

 

 

Mesos DC/OS 상세 자료

·         트위터, AirBnB 에서 사용

·         MS Azure 에서 Managed 서비스 제공 ==> Azure Container Service

·         DC/OS ?

o   랩탑 컴퓨터를 쓰면서 어떤 어플리케이션이 어떤 코어에서 실행될지 관리한 적이 있는가?

§  어플리케이션이 실행될 코어를 스케줄링하는 것은 커널이 일이다

§  마찬가지로, 컨테이너가 실행될 host 머신을 선택하는 것은 오케스트레이터(DC/OS) 일이다

o   DC/OS 싱글 컴퓨터 OS 그런 것처럼 다양한 문제를 해결하기위한 다양한 도구를 포함한다,

o   GUI CLI 제공되지 않는 랩탑을 써본적이 있는가?

§  수백대의 host 머신을 ssh 접속으로 관리하는 것은 불편하다

§  DC 전체를 조감/관리할 있는 UI 필요하다

§  어떤 어플리케이션이 어느 host 에서 실행되는지 한눈에 있는 UI 필요하다

o   Service Discovery 위한 DNS 필요하다

o   모든 서비스들을 하나로 번들링한 패키지가 필요하다 ==> DC/OS!

·         DC/OS = Mesos + Marathon + Chronos

o   Mesos 데이터센터를 위한 분산 시스템 커널

o   Marathon 작업(컨테이너) 관리용 스케줄러 (Kubernetes 컨테이너 관리용 스케줄러로 사용 가능)

o   Chronos 배치작업용 스케줄러

o   1개의 DC/OS 클러스터에서 다수의 스케줄러 동시 이용 가능

·         DC/OS 구성 요소 process 실행 시퀀스

o   구성 요소 & 관계


 

o   process 실행 시퀀스


·         주요 기능

o   Stateful Storage Support

§  external persistent volume 지원

·         app 입장에서 사용 편리, 전통적인 disk 동일

·         elasticity replication 대가로 speed 희생 (느림)

§  distributed file system 지원

·         app 입장에서 storage 사용법이 생소

·         네트워크 기반으로 동작하기 때문에 느림

§  local ephemeral storage 지원

·         stateless, semi-stateless 12-factor, cloud native app 적합

·         stateful service에는 부적합

§  local persistent volume 지원

·         fast and persistent storage 제공

·         data replication, RAID drive & backup 프로세스 등을 함께 사용한다면 speed 저하 없이 강인한(fault tolerant) storage 사용 가능

o   Elastic Scalability

§  horizontal scaling 지원

·         Marathon 이용, service instance 숫자를 언제든지 쉽게 조정

·         Marathon Load BAlancer 이용, autoscaling 가능

§  vertical scaling 지원

·         Marathon 이용, 서비스 다운타임 없이 instance 용량 업데이트 가능

o   Zero Downtime Upgrade

§  다운타임 없이 서비스 자동 업데이트 가능

§  DC/OS 위에서 실행되는 서비스는

·         rolling, blue-green, canary deploy pattern 사용 가능

·         deploy 실패시 이전 시점으로 one-click 복구 가능

o   Service Discovery and Distributed Load Balancing

§  자동 DNS endpoint 생성 기능 제공

§  서비스 lookup API 제공

§  내부 통신 고속화를 위한 L4 virtual IP proxing 기능 제공

§  외부향 서비스를 위한 L7 load balancing 기능 제공



Docker (Swarm) 상세 자료

·         2016 7 Docker 1.12 릴리즈됨

·         소감:

o   k8s처럼 pod(관련 컨테이너들의 집합)라는 낯선 개념을 도입하지 않고도, 도커에 내장된 Swarm 통해

§  overlay-network,

§  replica 관리 (실행되는 컨테이너 수를 사용자 지정값과 같도록 관리),

§  scaling 처리,

§  service discovery,

§  load balancing 처리 기능을 k8s 동등하게 지원하는 것이 인상적 ==> 새로 배울 개념이 적다 !

o   docker 데몬/클라이언트에 내장된 명령으로 Swarm 클러스터를 관리 ==> 새로 배울 도구가 적다 !

·         Docker 1.12 특징

o   Swarm 명령이 native 지원됨 ==> The Best way to orchestrate Docker is Docker !

§  docker swarm 명령들이 추가됨

o   Service 모니터링

§  docker service 커맨드로 service desired state 지정/관리

§  health check

§  replica 관리 (실행되는 컨테이너 수가 설정된 값과 같도록 관리)

§  scaling 관리

o   Self Healing

§  service 죽으면 도커 엔진이 다시 스케줄링함

§  k8s 같은 별도의 오케스트레이션 도구 필요 없음

§  Swarm 클러스터 위에서 실행되는 컨테이너에 대해 지속 실행과 스케일링을 지원함

§  데모 동영상 ~ https://www.youtube.com/watch?v=F7hoq0KwHD4&t=8m13s

o   Security

§  도커에 인증서를 관리하는 CA 서버가 통합됨

§  추가 설정 없이 host 머신들 사이의 모든 통신을 암호화 처리함 (디폴트)

o   Load Balancing

§  클러스터 위에 service publish 하면 클러스터에 속한 모든 host 머신의 해당 port 접근 가능

§  도커가 모든 host 머신의 해당 port 들어오는 service request 적절한 컨테이너로 re-라우팅 & 로드밸런싱

o   Rolling Deploys

§  replica 실행 중에 컨테이너를 한개씩 또는 두개씩(개수 설정 가능) 업데이트

§  새로 추가된 명령어 한방으로 처리

§  데모 동영상 ~ https://www.youtube.com/watch?v=F7hoq0KwHD4&t=6m38s

o   도커 1.11 대비 1.12 개선점 요약

 

·         Docker 1.12 Networking Model

o   모든 컨테이너는 3 종류의 오버레이 네트워크에 연결됨

§  ingress

·         도커가 정의하는 오버레이 네트워크

·         port publish (-p 옵션) service ingress 네트워크에 붙음 (port publish 하지 않은 컨테이너는 ingress 네트워크에 붙지 않음)

§  docker_gwbridge

·         도커가 정의하는 오버레이 네트워크

·         클러스터 외부와 연결하기 위한 네트워크

§  user-defined overlay

·         사용자가 정의하는 오버레이 네트워크

·         사용자는 다수의 오버레이네트워크를 정의할 있음

·         $ sudo docker network create -d overlay mynet

§  오버레이네트워크는 host 머신에 처음 컨테이너가 할당되어 실행될 생성됨

o   Routing Mesh

§  도커는 내장된 Routing Mesh 도움으로 클러스터 안의 모든 host 머신으로 유입되는 요청이 컨테이너가 실행되는 적절한 host 머신으로 re-라우팅되도록 보장함

§  클러스터 외부의 로드밸런서는 도커 클러스터 내부의 컨테이너 실행 상황(어떤 컨테이너가 어떤 host 머신에서 실행되는지) 몰라도



Ref

·         Apache Mesos 소개

o   ~ http://www.mimul.com/pebble/default/2013/10/27/1382885361083.html

·         "Nexus: A Common Substrate for Cluster Computing"

o   ~ https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-158.pdf

·         "Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center"

o   ~ https://amplab.cs.berkeley.edu/wp-content/uploads/2011/06/Mesos-A-Platform-for-Fine-Grained-Resource-Sharing-in-the-Data-Center.pdf

·         범용 PaaS 플랫폼 mesos(mesosphere)

o   ~ http://www.slideshare.net/songaal/paa-s-mesosmesosphere

·         Mesosphere 튜토리얼

o   ~ http://docs.mesosphere.com/intro-course

·         Mesosphere DC/OS on Google Cloud Platform

o   ~ https://mesosphere.com/google/

·         Docker Swarm

o   ~ https://docs.docker.com/swarm/

·         Docker Swarm vs. Kubernetes

o   ~ https://outofbedlam.github.io/docker/2016/03/12/DockerSwarm-vs-Kubernetes/

·         What's New In Docker 1.12

o   ~ http://blog.nimbleci.com/2016/08/03/whats-new-in-docker-1.12/

·         Docker Engine 1.12 comes with built-in Distribution & Orchestration System

o   ~ http://collabnix.com/archives/1317

·         Docker 1.12 Networking Model Overview

o   ~ http://collabnix.com/archives/1391

Posted by ingeeC
,

LXC & LXD



LXC(Linux Container, 렉스-씨)
- 리눅스 커널의 cgroups와 namespaces를 이용 컨테이너를 관리하는 모듈

    (container driver)
- Docker 초기 버전도 LXC를 container driver로 사용함
- Docker 0.9 버전부터 자체 개발한 container driver (libContainer)를 사용하기 시작
  . LXC와 Docker가 별개의 패키지로 배포되기 때문에 발생할 수 있는 버전 오류 제거,

    안정성 향상
  . Docker가 LXC를 거치지 않고 커널의 container API를 직접 호출, 효율성 향상

  . 하지만 굳이 원한다면 설정을 통해 libContainer 대신 LXC를 쓸 수도 있음


<Container Driver>



LXD(Linux Container Daemon, 렉스-디)
- 캐노니컬(Canonical)이 만든 컨테이너 솔루션 (LXC를 구성요소로 포함)
- Container의 Security를 강조
  . "Secure by default (옵션 설정 없이 디폴트 상태가 Secure한 상태)"를 표방
  . Unprivileged Container 지원

    (root가 아니어도 컨테이너를 띄울 수 있음,

    별거 아닌 것 같아도 보안 측면에서 꽤 중요한 기능)
- Docker는 Application Container, LXD는 Machine Container
  . 어플리케이션을 컨테이너로 패키징하는 것이 아니라 완전한 리눅스 실행환경을 컨테이너로 패키징
  . 본질적인 비교라기보다는 LXD 포지셔닝을 위한 일종의 마케팅 구호

    (개념적인 차이만 있을 뿐, 본질적/성능적/기술적 차이는 없음)
  . LXD의 목표는 VM 대체가 목적 (OpenStack과 통합,

    LXD의 경쟁상대는 Docker가 아니라 KVM)
- 심지어 LXD 컨테이너 안에 Docker 컨테이너를 띄우는 것을 권장!
  . LXD로 Security를 보완할 수 있음
  . VM에 Applicaiton을 배포하는 현재의 작업 프로세스/메카니즘을 유지할 수 있음
- VM은 익숙하지만 Container는 낯설어 불편한 사람들에게는 LXD가 현실적인 대안이 될 듯함


<VM vs. LXD vs. Docker 개념 비교>


(이상)

Posted by ingeeC
,