[221] docker orchestration

Docker Orchestration

이종현 NAVER 서비스플랫폼 개발센터

1

Contents

1. Abstraction 2. Backgrounds 3. Docker Orchestration 4. Build Pool & Shipdock 5. Demo 동영상

2

1. Abstraction

3

4

이런 이야기를 해보려고 합니다…

git repo

naver developer

CLI/UI

build

docker registry

80

compose

cluster manage

docker cluster #1

docker cluster #2

push pull

push

pull

config load

base

store

containerize

5

이런 이야기는 하지 않습니다.

도커 각종 설정 방법 직접 만들지 않는 것들 …

2. Backgrounds

6

소개

저는 2007년부터 네이버에서 빌드/배포를 담당하고 있습니다.

7

many sources package repository many services

소스를 어떻게 효율적으로 서비스화 할지 고민 합니다.

3000+ modules 20000+ opr/mon

8

소스, 빌드/배포, 성공적…

네이버의 많은 개발자와 부서의 …

빌드 서비스를 정의하면…

네이버 개발자 들의 소스를 배포 가능하게 (package) 만드는 일

9

sources building package

빌드 서비스의 고민

10

Conflict

공유의 문제

효율성의 문제

네이버의 서비스마다 “서로 다른 빌드 환경” 을 원한다.

Customization

빌드 서비스의 효율성을 위해…

11

빌드를 위한 자원을 공유하면서 커스터마이징이 가능하도록.

SHARE !

배포 서비스를 정의하면…

빌드한 패키지를 서비스 할 수 있는 상태로 만드는 것

12

service deploying package

배포 서비스의 고민

네이버 서비스들의 “상태” 를 관리해주고 싶다.

13

rollback

deploy

이분, 저분, 마구 수정해도 항상 원하는 상태로 갈 수 있음!

1.0 1.1

1.2

1.2.1

2.1

2.0

3.0

서비스의 “상태” 를 이미지로 배포

14

deploy

rollback

1.0 2.0 3.0

1.2.1 2.1

“deploy == rollback”

Docker 를 주목한 이유

가상 머신보다 가벼운 컨테이너 효율적인 리스스 공유

이미지 빌드, 이미지 배포, 이미지 롤백 서비스의 상태를 관리

“Write Once, Run Anywhere” 빌드/배포를 단순하게

15

Deview 2014 의 도커 발표자료를 참고하세요 ^^ (http://deview.kr/2014/session?seq=20 )

16

Docker 에 대한 설명은 다루지 않습니다.

3. Docker Orchestration

17

Docker Orchestration 이란 …

여러 개의 컨테이너로 하나의 서비스를 구성하는 것

18

http://svc.io:80

tcp:6380 tcp:3306

http://svc.io:80

Orchestration 이 필요한 이유

19

Composition 여러 종류의 컨테이너로 구성된 서비스의 설정 및 연동

Replication Scalability, Fault Tolerance, High Availability

“Write Once Run Anywhere” 같은 이미지가 Local/Cluster 에서 모두 동작할 수 있도록

Orchestration 의 요소 (4가지 정도만 …)

20

1. Scheduling 클러스터의 적절한 노드에 컨테이너를 실행 (# of)

(CPU, MEM, Storage, Context, …)

2. Networking 컨테이너 사이/외부와의 네트워킹

(L2 Overlay, L4 Load Balancing, HTTP Proxy, …)

21

3. Discovery 컨테이너/그룹을 찾아내는 방법

(Membership, KV Store, DNS, …)

4. Logging / Monitoring / Alerting 로그를 보고, 상태를 확인하고 이상을 감지

…

Orchestration 의 요소 (4가지 정도만 …)

어떤 것을 선택/조합할 것인가 ?

22

Docker Ecosystem

Orchestration 검토의 시작

23

“Native Clustering for Docker” “Standard Docker API”

24

Docker Swarm

https://blog.docker.com/2014/12/docker-announces-orchestration-for-multi-container-distributed-apps/

Native Cluster, Docker API 는 매력적인 Feature 만족스럽지 않음…

Docker Orchestration API

Replication 상태 관리

Heavy Development (0.4.0 에서 많이 개선) 언젠가는 다시 검토 (하지만 지금은 아니라고 판단.)

25

Docker Swarm 일단 포기

“Google Style” 클라우드 서비스 관리 서비스에 적합한 Docker 클러스터를 가장 빠르게 구축

Pods, Replication Controllers, Labels, Services, …

안정성 (Ver 1.0, Google Cloud Engine)

http://stackoverflow.com/questions/26705201/whats-the-difference-between-apaches-mesos-and-googles-kubernetes 26

Kubernetes

비교적 원하는 기능이 “예상대로” 동작했고, 현 시점에서 가장 앞선 구현체 중 하나로 판단. 더 필요한 것들.

Docker API, Orchestration API

External Traffic (Discovery, Forwarding)

Multi-Cluster 관리

…

27

Kubernetes 선택

28

이제 Orchestration 이 정해졌으니 …

UI

build

docker registry

80

compose

cluster orchestration

cluster #1

cluster #2

naver developer

OCUS F

4. Build Pool & ShipDock

29

ShipDock

Milestone

30

Build Pool

Service Cluster

Jenkins Dockerize

Containerized Service Test

Service Containerize

ShipDock

Build Pool

31

Build Pool

Service Cluster

Build Pool

Jenkins 를 Docker 컨테이너로 제공

Fast Pre-built 서버 제공

Jenkins 관리 효율화 (생성, 백업, 이중화, …)

Kubernetes 에 대한 개발/운영 경험

32

Build Pool Design

33

CoreOS

Flannel

ETCD

Kubernetes

SkyDNS

Docker Registry (1.0)

docker registry (1.0)

kubernetes

kube-api

naver developer

request

image

pull/push image

create

current build/deploy system

Build Pool 의 효과

Fast Build 빌드 자원의 공유로 고성능 빌드 가능

Pre-Built C/C++, Java, Android, node.js, …

No management

34

평균 빌드 시간 비교

VM 1core (38 sec)

VM 2core (23 sec)

BP (13 sec) 2배

3배

+ Docker Orchestration 구축 경험

Lesson Learned

Stateless Container Data Multi-Cluster

35

컨테이너는 Stateless 해야 한다.

Jenkins 의 누적 데이터를 Container 에 저장 주기적인 이미지 백업 (일 단위) 문제점:

백업이 제대로 되고 있는지 확인하기 어려움

State 변경하기 어려움 (ex. Environment Variable)

36

컨테이너 데이터의 저장 방법이 필요하다.

37

컨테이너 종료 시 삭제 Instant, No backup

컨테이너 종료 후에도 보관 여러 컨테이너 사이에 공유 (중복 데이터)

Label 등으로 특정 컨테이너에 바인딩

Multi-Cluster 관리가 필요하다.

38

비교적 이른 시점부터 Multi-Cluster 를 고려 해야…

컨테이너가 Cluster 별 설정이 필요한 경우가 생김. Ex) Multi-IDC, Network ACL, …

ShipDock

ShipDock

39

Build Pool

Service Cluster

ShipDock : “Shipping Docker”

Docker Test Pool - 기반 기술과 “돌아가는 버전” 확보

Continuous Deployment

- 소스 푸쉬를 서비스에 반영

Platform As A Service 준비 - “Write Once, Run Anywhere”

40

Shipdock 구조

41

dogsight (UI/CLI)

dorothy (builder)

docker registry

doh (manage)

kubernetes

kube-api

consul HTTP Proxy

In-bound traffic

docker-api+

naver developer

Our Implementations

DOH : “Docker’s Orchestration Headquarter”

Multi-Cluster 여러 Docker 클러스터 관리 (+ Scheduling) Transparency

kubernetes, swarm

Customized API Orchestration API

42

Dorothy

“Docker Based Builder” like 인스턴트하게 Docker 컨테이너를 생성하여 이미지 빌드/푸쉬 Jenkins 보다 가볍고 Stateless 한 빌드를 구성하기 위해

43

Docksight

Shipdock 의 Dash Board / Control UI GUI 와 CLI 를 지원 여러 클러스터를 지원하는 적절한 UI/CLI 를 찾지 못했음.

44

Docker Registry

V2.x 로 오면서 많은 부분 개선 Pull Performance Webhook, …

일부 보완 필요

이미지 Search (Elastic Search) Trusted Image Registry Proxy / Mirroring, Webhook, …

45

Consul

ETCD 외에 다른 Service Discovery 검토 목적 목적이 명확한 점이 매력

Membership, Consensus Cluster KV Store DNS for Container/Group

46

Internal Kubernetes

External HTTP Proxy (nginx)

Kube-proxy 에 대한 1 Hop 을 줄이기 위해

47

Networking

kubernetes

consul

HTTP Proxy

In-bound traffic

5. Demo 동영상

48

49

Dorothy

1) Source Push 2) Source Build 3) Image Upload

50

Containerize

1) Create Compose Info 2) Start Service 3) Scale-Out Service

51

Blue-Green Deploy

1) Current Status 2) Deploy (new version) 3) Updated Status 4) Done (or Back)

Q&A

52