DEVIEW2015 DAY2. docker orchestration

1. Docker
Orchestration
이종현
NAVER 서비스플랫폼 개발센터
1

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

3. 1.
Abstraction
3

4. 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. 5
이런 이야기는 하지 않습니다.
도커
각종 설정 방법
직접 만들지 않는 것들
…

6. 2.
Backgrounds
6

7. 소개
저는 2007년부터 네이버에서 빌드/배포를 담당하고 있습니다.
7
many sources package repository many services

8. 소스를 어떻게 효율적으로 서비스화 할지 고민 합니다.
3000+ modules
20000+ opr/mon
8
소스, 빌드/배포, 성공적…
네이버의 많은 개발자와 부서의 …

9. 빌드 서비스를 정의하면…
네이버 개발자 들의 소스를 배포 가능하게 (package) 만드는 일
9
sources building package

10. 빌드 서비스의 고민
10
Conflict
공유의 문제
효율성의 문제
네이버의 서비스마다 “서로 다른 빌드 환경” 을 원한다.
Customization

11. 빌드 서비스의 효율성을 위해…
11
빌드를 위한 자원을 공유하면서 커스터마이징이 가능하도록.
SHARE !

12. 배포 서비스를 정의하면…
빌드한 패키지를 서비스 할 수 있는 상태로 만드는 것
12
servicedeployingpackage

13. 배포 서비스의 고민
네이버 서비스들의 “상태” 를 관리해주고 싶다.
13
rollback
deploy
이분, 저분, 마구 수정해도 항상 원하는 상태로 갈 수 있음!
1.0 1.1
1.2
1.2.1
2.1
2.0
3.0

14. 서비스의 “상태” 를 이미지로 배포
14
deploy
rollback
1.0 2.0 3.0
1.2.1 2.1
“deploy == rollback”

15. Docker 를 주목한 이유
가상 머신보다 가벼운 컨테이너
 효율적인 리스스 공유
이미지 빌드, 이미지 배포, 이미지 롤백
 서비스의 상태를 관리
“Write Once, Run Anywhere”
 빌드/배포를 단순하게
15

16. Deview 2014 의 도커 발표자료를 참고하세요 ^^
(http://deview.kr/2014/session?seq=20 )
16
Docker 에 대한 설명은 다루지 않습니다.

17. 3.
Docker
Orchestration
17

18. Docker Orchestration 이란 …
여러 개의 컨테이너로 하나의 서비스를 구성하는 것
18
http://svc.io:80
tcp:6380tcp:3306
http://svc.io:80

19. Orchestration 이 필요한 이유
19
Composition
 여러 종류의 컨테이너로 구성된 서비스의 설정 및 연동
Replication
 Scalability, Fault Tolerance, High Availability
“Write Once Run Anywhere”
 같은 이미지가 Local/Cluster 에서 모두 동작할 수 있도록

20. Orchestration 의 요소 (4가지 정도만 …)
20
1. Scheduling
 클러스터의 적절한 노드에 컨테이너를 실행 (# of)
(CPU, MEM, Storage, Context, …)
2. Networking
 컨테이너 사이/외부와의 네트워킹
(L2 Overlay, L4 Load Balancing, HTTP Proxy, …)

21. 21
3. Discovery
 컨테이너/그룹을 찾아내는 방법
(Membership, KV Store, DNS, …)
4. Logging / Monitoring / Alerting
 로그를 보고, 상태를 확인하고 이상을 감지
…
Orchestration 의 요소 (4가지 정도만 …)

22. 어떤 것을 선택/조합할 것인가 ?
22
Docker Ecosystem

23. Orchestration 검토의 시작
23

24. “Native Clustering for Docker”
“Standard Docker API”
24
Docker Swarm
https://blog.docker.com/2014/12/docker-announces-orchestration-for-multi-container-distributed-apps/

25. Native Cluster, Docker API 는 매력적인 Feature
만족스럽지 않음…
 Docker Orchestration API
 Replication 상태 관리
Heavy Development (0.4.0 에서 많이 개선)
 언젠가는 다시 검토 (하지만 지금은 아니라고 판단.)
25
Docker Swarm 일단 포기

26. “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

27. 비교적 원하는 기능이 “예상대로” 동작했고,
현 시점에서 가장 앞선 구현체 중 하나로 판단.
더 필요한 것들.
 Docker API, Orchestration API
 External Traffic (Discovery, Forwarding)
 Multi-Cluster 관리
 …
27
Kubernetes 선택

28. 28
이제 Orchestration 이 정해졌으니 …
UI
build
docker registry
80
compose
cluster
orchestration
cluster #1
cluster #2
naver
developer
OCUSF

29. 4.
Build Pool &
ShipDock
29

30. ShipDock
Milestone
30
Build
Pool
Service
Cluster
Jenkins Dockerize
Containerized Service Test
Service Containerize

31. ShipDock
Build Pool
31
Build
Pool
Service
Cluster

32. Build Pool
Jenkins 를 Docker 컨테이너로 제공
 Fast Pre-built 서버 제공
 Jenkins 관리 효율화 (생성, 백업, 이중화, …)
 Kubernetes 에 대한 개발/운영 경험
32

33. 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

34. 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 구축 경험

35. Lesson Learned
Stateless
Container Data
Multi-Cluster
35

36. 컨테이너는 Stateless 해야 한다.
Jenkins 의 누적 데이터를 Container 에 저장
주기적인 이미지 백업 (일 단위)
문제점:
 백업이 제대로 되고 있는지 확인하기 어려움
 State 변경하기 어려움 (ex. Environment Variable)
36

37. 컨테이너 데이터의 저장 방법이 필요하다.
37
컨테이너 종료 시 삭제
 Instant, No backup
컨테이너 종료 후에도 보관
 여러 컨테이너 사이에 공유 (중복 데이터)
 Label 등으로 특정 컨테이너에 바인딩

38. Multi-Cluster 관리가 필요하다.
38
비교적 이른 시점부터 Multi-Cluster 를 고려 해야…
컨테이너가 Cluster 별 설정이 필요한 경우가 생김.
Ex) Multi-IDC, Network ACL, …

39. ShipDock
ShipDock
39
Build
Pool
Service
Cluster

40. ShipDock : “Shipping Docker”
Docker Test Pool
- 기반 기술과 “돌아가는 버전” 확보
Continuous Deployment
- 소스 푸쉬를 서비스에 반영
Platform As A Service 준비
- “Write Once, Run Anywhere”
40

41. 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

42. DOH : “Docker’s Orchestration Headquarter”
Multi-Cluster
 여러 Docker 클러스터 관리 (+ Scheduling)
Transparency
 kubernetes, swarm
Customized API
 Orchestration API
42

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

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

45. Docker Registry
V2.x 로 오면서 많은 부분 개선
 Pull Performance
 Webhook, …
일부 보완 필요
 이미지 Search (Elastic Search)
 Trusted Image Registry
 Proxy / Mirroring, Webhook, …
45

46. Consul
ETCD 외에 다른 Service Discovery 검토 목적
목적이 명확한 점이 매력
Membership, Consensus
Cluster KV Store
DNS for Container/Group
46

47. Internal
 Kubernetes
External
 HTTP Proxy (nginx)
 Kube-proxy 에 대한 1 Hop 을 줄이기 위해
47
Networking
kubernetes
consul
HTTP Proxy
In-bound traffic

48. 5.
Demo 동영상
48

49. 49
Dorothy
1) Source Push
2) Source Build
3) Image Upload

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

51. 51
Blue-Green Deploy
1) Current Status
2) Deploy (new version)
3) Updated Status
4) Done (or Back)

52. Q&A
52