Configuration management, Ansible 을 알아보자 part 1

안녕하세요. kin입니다.

오늘은 configuration management tool 가운데 다크호스로 이미 떠오른 ansible을 한 번 후려쳐 볼까 합니다.

이미 Chef, Puppet, Salt등 다양한 tool들이 많이 사용되어지고 있지만 Ansible 은 흠 일단 쉬워요. Chef, Puppet 은 Ruby 기반이지만 Ansible은 YML(야믈 이라고 발음) 기반이지요. 물론 YML이 static 하기 때문에 dynamic 적으로 사용하려면 JINJA2 (python 기반)을 같이 사용해야 하기 때문에 복잡(?)성이 증가 한다고 생각할 수 있지만 기본적으로 간단합니다.

그럼 Ansible 의 가장 기본적인 특징을 알아볼까요?

• Ansible 은 Agentless합니다. 
•  ansible은 기본적으로 SSH(또는 옵션에 따라 ZeroMQ) 기반입니다. 따라서 Puppet 사용시 PKI등의 잡스러운(?) 요소가 필요 없지요. 
• Ansible은 python 기반입니다.   python 2.4 이상의 버전이 필요합니다. 
• 풍부한 모듈 지원. 약 200개 이상의 모듈이 out of the box 로 지원됩니다. 
• Ansible galaxy에서 다양한 role들을 다운로드하여 사용하세요. (chef의 recipe라고 생각하시면 됩니다.) 

vagrant 기반 예제는 https://sorididim11@bitbucket.org/sorididim11/ansible_example.git  

Playbook

• playbook은 ansible의 환경 설정, 배포를 가능케 하는 언어.
• 각 playbook은 하나 또는 하나 이상의 ‘play’를 둔다. 즉 collection of plays
• play의 목적은 여러 호스트들에 잘 정의된 ‘role’과 ‘task’를 매핑하는 역할
• task는 ansible모듈의 호출을 의미.

• Playbook files

• Yml files

• 1 2 3 4 5 6 7 8 9 10 11 12 13 14

  - name: Install nodejs required for webservers   hosts: webservers   user: kin   sudo: yes   roles:     - nodejs - name: Install mongodb  required for dbservers   hosts: dbservers   user: kin   sudo: yes   roles:     - mongodb Colored by Color Scripter

  cs

• '야믈’이라 발음
• 사람이 쉽게 읽을 수 있는’ 데이터 직렬화(serialization) 양식.
• json은 간결함과 범용성에 초점을 둔다면, yaml은 json의 장점을 포함하고 임의의 고유 데이터 구조에 대한 직렬화 를 지원.
• yaml은 정적. ansible에서는 이를 동적으로 표현할 수 있는 무엇인가가 필요함.
• jinja2(http://jinja.pocoo.org/docs/)라는 python 라이브러리를 이용해서 yaml 문법의 단점 을 보완.
• Site.yml(플레이북 디폴트)
• block을 가지고 있음.
• block은 적용할 host와 role을 명시.

• Hosts file (inventory 파일이라고도 함)

• 1 2 3 4 5 6 7

  [webservers] web01 web02 192.168.100.1 set_hostname=web03  [dbservers] db1

  cs

• inventory파일은 리모트서버에 대한 meta데이터를 기술하는 파일
• 파일 포맷은 Standard INI-like 파일
• ansible에서는inventory파일에는 yml을 적용하지 않았음.
• 기본파일은 /etc/ansible/hosts을 읽게 하거나, 따로 inventory파일을 만들고 옵션을 주어 동작하게 할 수 있음.
• [, ]안이 그룹 이름이고, 호스트명(host)은 해당 그룹에 속함
• 한 줄에 하나의 호스트 선언(IP 또는 hostname)
• 호스트 선언 뒤에 Host variable을 선언할 수 있음. 
• 인벤토리 파일에서 호스트네임을 사용하면 /etc/hosts 파일에서 resolvable 하거나 dns lookup을 통해 찾을 수 있어야함.
• Group varible을 선언할 수 있음
• Role

• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  . ├── README.md ├── defaults │   └── main.yml ├── meta │   └── main.yml ├── tasks │   └── main.yml ├── templates │   └── nodesource.list.j2 └── test     └── integration         ├── default         │   ├── default.yml         │   └── serverspec         │       └── default_spec.rb         └── helpers             └── serverspec                 └── spec_helper.rb

  cs

• Role 들은 서로 dependency를 가질 수 있음. (meta에 정의)
• Files - 타겟으로 복사 되어져야 하는 파일들(설정 파일 들을 여기에 둔다)
• Handlers - YML file - notify에 triggered 되는 config의 부분이라고 할 수 있음
• Meta - YML file role dependencies
• Tasks - 스텝의 리스트로 구성되이 있는 YML 파일 즉 이 스텝들이 타겟 노드에서 명시된 순서대로 실행되어진다.
• Templates - jinja2 files(YML을 확장하는 동적 템플릿 파일)

• Task
• Name 아래 줄을 액션이라고 함. 이 액션이 ansible module을 사용하는 코드임 

• 1 2 3 4 5 6

  - name: Add the Redis PPA    apt_repository: repo='ppa:rwky/redis' update_cache=yes  - name: Install Redis from PPA    apt: pkg=redis-server state=installed  - name: Start Redis    service: name=redis state=started

  cs

주요 하이레벨 ochestration tool 장단점

안녕하세요.  Kin입니다.

오늘은 지인의 부탁으로 High-level orchestration tool 을 정리 하다가 정리한 글을 공유 할까 합니다.  훔 제가 관심있게 지켜보던 녀석들로 준비했고 너무 방대하여 다 정리하기는 좀 그렇겠죠?

 제가 가장 관심을 가지고 제멋대로 수정중인 DCOS부터 시작 해볼께요.

DCOS(DataCenter OS)

일단  mesosphere 에서 나온 PaaS를 지원할수 있는 DCOS. 

• Benefit
• 
  
• Messos 기반으로  Marathon이 default scheduler이고 chronous도 built-in입니다. 
• 기본적으로 multiple VM and docker 다 지원합니다. 
• 나름 이쁜 Dashboard, metric UI support
• 다양한 프레임워크과 통합 가능.  Marathon, Kubernetes, Docker Swarm, 하둡, 스톰, 스파크 등과 다 연동 가능합니다.(Docker Swarm은 아직 지원 하지 않아요. DCOS universe (앱 스토어와 비슷한 개념)을 확인해보세요.)
• 다양한 security 정책을 가지고 apps을 다양한 형태로 배포 할 수 있음
• DCOS universe나 command tool을 이용하면 한방에 다양한 services/frameworks 들을 설치 할 수 있음. 
• 메소스 기반이기 때문에 클러스터를 수만개의 노드로 확장할 수 있음(대형 레퍼런스가 많은 프로젝트죠)

• Drawback
• 제가 글을 쓰는 현재 엔터프라이즈 버젼만 multi-cloud 기능을 사용할 수 있어요. 
• 공짜 버전은 managed service가 아닙니다. ㅠ.ㅠ

Kubernetes 

• Benefit
• GCE(Google Container Engine)가 managed version의 큐버니티스를 지원합니다. 
• 클러스트 전체를 다운타임없이 update를 지원한다는데 어떠한 제약조건이 있는지 모르겠지만 설명대로 된다면 엄청난 기능이네요.  rolling update 형태의 클러스터 버전업! 
• POD이라는 서비스 개념으로 기본적으로 MSA(MicroService Architecture)를 지원합니다. 
• Drawback
• 현재 우버니티스를 통합하여 multi-datacenter를 지원한다고 하는데 아쉽게도 대형 레퍼런스는 아직 없는거 같습니다. 
• Rocket 과 docker 컨테이너 기술을 지원하지만 VM, standalone은 지원하지 않습니다. 
• 엄청 주관적인 관점이지만 UI가 좀 부족해 보입니다.
• 
  

Docker swarm

• Benefit
• Docker native API 기반. 직관적이죠. 
• Docker container 기반으로 시스템을 설계한다면 너무 사용하기 쉽고 편합니다. 제 지인들중에 팬이 많아요. 
• Drawback
• Docker 만 지원하죠. 
• Docker Swarm는 a managed service 가 아닙니다. 
• Rolling updates 도 쉽지 않다는 문제점이 있습니다. 디테일일 궁금하시다면 하하 질문해주세요. 

오버레이 네트워크? Docker networking?

Docker Networking

안녕하세요. kin입니다. 

오늘은 Docker가 쓸만해진(?)게 만들어준, 네트워크 feature에 대해 살짝 후려쳐 보죠.  자세한 사항은 Docker network doc 을 확인하세요. 

• 1.9 이전에는 오버레이 네트워크가 지원되지 않아 Proxy를 사용해야 했음
• Docker를 설치하면 자동으로 3개의 네트워크가 추가됨 (docker network ls command 로 화인)
• 컨테이너는 여러 개의 네트워크에 추가될수 있음
• 컨테이너는 같은 네트워크에 있어야 서로 통신할 수 있음
• Network type
• Bridge network
• --net=bridge
• 디폴트로 docker가 생성하는 브릿지 네트워크, docker0 라는 이름을 가짐
• Docker 엔진은 subnet 과 gateway를 이 네트워크에 생성한다.
• 옵션을 주지 않으면 docker 데몬이 컨네이터를 이 네트워크를 연결함
• private 범위에서 사용하지 않는 IP를 자동으로 선택해서 docker0 에 할당
• EXPOSE option
• Exposing port - EXPOSE 옵션은 컨네이너끼리 IP 기반으로 커뮤니케이션을 허락. (외부 통신 아님)
• LINK option
• --link option - 컨네이너안에 환경변수를 이용하여 서로를 이름으로만으로도 찾게 도와준다.
• External port option
•  -p 옵션을 통해 호스트(external network)와 이름 기반으로 커뮤니케이션 가능. 다커가 iptable을 생성해서 브릿지와 external 을 연결
• Overlay network  (multiple-host networking)



• built-in VXLAN 기반 네트워크 드라이버 사용.
• 오버레이 네트워크는 Key-value store가 요구 되어짐
• libkv가 kvstore 인터페이스 서포트- 구현체는 consul. Etcd, zookeeper
• 각각의 호스트에는 docker 엔진이 실행되어야 함
• Docker daemon에 옵션으로 서비스 디스커버리(Kvstore)의 주소를 설정해야함
• Host network
• --net=host
• 컨네이너가 호스트 머신과 네트워크 네임스페이스를 공유

CoreOS - Fleet, etcd and Systemd

안녕하세요. Kin입니다. 

저번에 PaaS, Deis를 소개드렸는데 Deis의 기반이 되는 coreos package를 후려쳐서 소개 할까 합니다. 

제가 저번의 Devops 핵심 Layers들을 소개 드렸죠? 기억이 안나신다면 Devops 핵심 요약 아키텍처 을 확인하세요. 

자 이제 주요 항목들을 하나씩 확인해 보시죠.

CoreOS

CoreOS는 일단 Container 전용 리눅스 배포판입니다. docker 뿐만아 아니라 자체적으로 light-weight rocket 이라는 container 기술을 가지고 있습니다. CoreOS 에는 built-in으로 다음과 같은 컴포넌트를 제공합니다.  

Main components of CoreOS

• Orchestration tool - fleet
• 분산 init system. systemd는 로컬 서비스 관리.
• fleet은 etcd, systemd를 이용해 원격에서 여러 서비스 관리
• docker container를 임의의 호스트로 배포.
• 부하 분산 
• 정해진 서비스 개수 유지. 즉 한 호스트가 정지하더라도 개수를 유지하기 위해 다름 호스트에 서비스를 실행시킴. 

• Service discovery - etcd
• distribured KV store 
• HTTP long polling support
• Raft consensus based master election.

• Executor- systemd
• 리눅스 서비스 매니저, SystemV, Linux init 대체제로 docker 컨네이너 실행
• init 보다 훨 빠름
• 서비스 의존성 설정 가능 및 실행 순서 제어
• 데몬은 journald를 사용하여 로그 기록 

클라우드 백본, Ochestration tool, Nomad 소개

안녕하세요 Kin입니다. 

오늘은 ochestration tool 중에 하나인 nomad 를 소개하고자 합니다.  예전에 ochestration tool 관련 발표 자료만들다가 정리한 문서인데 훔 나쁘지는 않아요.

일단 nomad는 vagrant와 consul로 유명한  hashicorp에서 나온 야심작(?)인데요.  

훔 다른 솔루션들에 비해 상당히 늦은 후발주자이기 때문에 기존 제품들의 비해 아키텍처 관점에서 

세련된 장점들을 가지고 있습니다. 

제가 글을 쓰는 현재 버전이 0.4 라서 mature와는 거리가 아주 먼 제품이라 말할 수 있지만 굉장히 큰 로드맵을 가진 오픈 소스입니다. 

아 참 nomad는 google borg and omega paper 기반 구현체입니다. 

이제 살살 살펴보시죠

Nomad

Nomad is orchestration tool that abstracts away machines and the location of applications,  and instead enables  users to declare what they want to run and Nomad handles where they should run and how to run them.

Backgroud Multi-Datacenter and Multi-Region Aware

Nomad models infrastructure by defining hierarchical structures as below :

• Datacenter
• Datacenter contains nodes that are all located on the same local area network
• ex) us-west, us-east
• Region
• Regions may contain multiple datacenter
• Scheduling operates at the region level
• Region is single consensus group which means work together and elect a single leader
• Regions are fully independent from each other( do not share jobs, clients, or state)
• Each region is expected to have either three or five servers.
• ex) us, korea
• Muti-regison
• One single cluster combining regions
• Scheduling does not operates at the muti-regison level
• Regions do not share jobs, clients, or state
• Request for query, submitting jobs can be forwarded among regions

Gossip protocol( to manage membership. Serf base)

• LAN Gossip(Datacenter) - Refers to the LAN gossip pool which contains nodes that are all located on the same local area network or datacenter.
• WAN Gossip(Region, Multi-region) - Refers to the WAN gossip pool which contains only servers. These servers are primarily located in different datacenters and typically communicate over the internet or wide area network.

Subsystem 

• Nomad server
• Servers manage all jobs and clients
• Servers in a region participate in making scheduling decisions in parallel
• Run evaluations, and create task allocations for scheduling
• Replicate cluster states between each other
• Perform leader election
• Leader & follower
• Leader - The leader is responsible for processing all queries and transactions
• Follower - participate in making scheduling and forward query to leader
• Nomad client
• Register themselves with server
• Send heartbeats for liveness,
• Wait for new allocations,
• Update the status of allocations
• Provide server with the resources available, attributes, and installed drivers.

Job 

Each job file has only a single job a job may have multiple task groups

• Task
• A Task is the smallest unit of work in Nomad, Tasks are executed by drivers
• Task Group
•  A Task Group is a set of tasks that must be run togetherTask group on the same client node
• Drivers
• means of executing your Tasks (Docker, Qemu, Java, and static binaries.)
• Job type( = scheduler type)
• Service
• services that should never go down
• based on best fit scoring algorithm of google borg
• relatively long scheduling time
• batch
• short term performance and are short lived
• based on Berkeley's Sparrow scheduler
• system
• jobs that should be run on all clients that meet the job's constraints
• invoked when clients join the cluster or transition into the ready state
• jobs will be re-evaluated and their tasks will be placed on the newly available nodes if the constraints are met.
• Constraint
•  Constraints can be specified at the job, task group, or task level
• Constraint type
• hardware filter
• arch type
• Number of CPU cores
• AWS client id & instance type
• software filter
• kernal name & version
• installed driver
• name & id
• datacenter name
• noide id or name
• one of keys of metataday

Nomad cons/pros

• cons
• 멀티 데이터 센터 모델링 ( 여러개의 데이터 센터를 통합하여 관리하는 모델링 메카니즘 제공(현재 kubernetes가 ubernetes를 통합하여 지원) 
• container 기술뿐만아니라 standalone, 다양한 virtual machine 지원 
• props
• 버전 0.4(아직 갈 길이 멈) 
• compact하고 simple 하다고 자랑하지만 사실 기능이 없어 가벼운 것임(volume management 지원 예정)
• 무조건 docker host network 기반 (오버레이 네트워크? 사용 불가능)
• docker compose 나 kubernetes는 서비스 concept과 같은 logical group 개념 없음. (물어보면 다 지원 예정)
• docker 기능 사용 할 수 없음. 로드 맵이 너무 general해서 docker specific한 옵션들을 job file에 사용 할 수 없음. ex) docker의 로깅 기능 즉 logstash 같은 플러그인을 사용 못함.

Devops 핵심 요약! 클라우드의 서브시스템/컴포넌트 -

안녕하세요. Kin입니다. 

필드에 너무 많은 클라우드 기술들이 존재해서 뭘 써야하나 고민하셨죠. 오늘은 특정한 클라우드 솔루션을 소개하는것보다 모든 솔루션들의 기본이 되는 devops의 핵심 중에 핵심을 간단한 아키텍처 관점에서 살펴보도록 하겠습니다. 

제가 생각하는 클라우드에는 백본(backbone)이 되는 가장 중요한 기술이 3개입니다. 

• Ochestration tool  
•  후려쳐서 말하자면 machine들을 클러스터로 묶고 각 machine의 리소스를 관리하며 이 리소스를 기반으로 스케줄링하여 어플리케이션을 필요한 위치에 런치하고 관리하는 tool이라고 생각하시면 됩니다. 대표적인 솔루션으로는 Mesos/marathon, Kubernetes, nomad, diego 등이있습니다.

• Cluster management -  클라우드를 구성하는 노드(node. 그냥 서버 한대라고 생각하시죠.) 들의 묶음을 만들고 관리하는 역할입니다. 즉 후려처서 멤버쉽을 관리하는 놈이라고 생각하면됩니다. 
• Resource management - 관리하는 노드들의 리소스를 관리하는 역할입니다.
• Scheduling - 자 이제 마지막으로 노드들의 집합에서 리소스를 기반으로 스케줄링하여 릴리즈 할 어플리케이션이 어느 노드에 배포되어야 하지는 결정하는 역할입니다. 
• Executer 또는 Driver - 각 노드에 설치되서 스케줄러가 할당한 Job을 실행하는 역할입니다. 
• Service discovery 

• Service discovery 말은 복잡해 보이지만 실은 무지 간단합니다. 일단 왜 필요 하냐면요. 간단히 말하자면 사용자가 많아지면 인스터스를 scale out하고 사용자가 적이지면 scale in을 해야겠죠. 즉 인스턴스가 상황에 따라 노드들을 왔다갔다 하면 죽었다 살았다를 반복하지요. 그럼 문제. 자 살아있는 인스턴스 어디에 있는지 어떻게 확인하죠? 이런 문제를 해결하는 메커니즘이 서비스 디스커버리 입니다.  자 그럼 구성요소를 살펴 보겠습니다.
• Service registry - 후려쳐서 Key-value store 라고 생각하시면 됩니다.  즉 여기에 어디에 어떤 인스턴스가 살아있다라고 쓰고 읽고 하는 장소라고 생각하시면 됩니다. 
• Server registrar - 서비스 레지스트리에 서비스 인스턴스를 등록하는 주체입니다. 보통 ochestration tool과 연동하면 자동적으로 서비스 레지스트리에 등록합니다. 
• 보통 오케스트레이션 툴과 서비스 디스커버리는 한 세트입니다. 예를 들면 Kuberneters라는 툴은 etcd라는 서비스 디스커버리 구현체를 내장하고 있지요. 물론 다른 구현체로 교체도 가능합니다. 
• 대표적인 구현 솔루션은 consul , etcd, zookeeper 등입니다. 나중에 하나씩 자세히 뜯어 먹어 볼께요. 나중에!

• Configuration management

1. 뭐 다들 아시겠지만 후려친 개념부터 말씀들리면 서버 또는 가상서버에 소프트웨어를 설치하거나 설정을 자동화 할 수 있게 하는 스크립트라고 생각 하시면 됩니다. 
1. 필요한 소프트웨어, 라이브러리, 설정 파일을 한 번에 여러 노드에 배포 하실때 자동화하는 메커니즘입니다. 
2. 구현 솔루션으로 Chef, Puppet, Ansible 등이 있습니다. 

자 이제 위의 세가지 솔루션으로 무얼 할 수 있을까요? 

한 번 가정해보죠. 사용자가 폭주하여 서비스 인스턴스를 늘려야 한다고 가정해보죠. 

그럼 새로운 서버 또는 가상 서버가 필요하겠네요. 자 그럼 뚝하고 가상서버나 서버가 생성됐다고 생각해보시죠. 자 그다음은 이 서버들에 필요한 서버들에 소프트웨어를 설치하고 설정해야겠네요. 이때 필요한게 configuration management tool입니다. 

그 후에는 어떨까요. 새롭게 셋업된 이 친구를 우리 그룹(클러스터) 에 추가해야겠죠.  사실 configuratno managment 과정중에 제가 필요한 소프트웨어를 설치한다고 말씀드렵는데 이때 cluster 의 slave 클라이언트가 보통 설치 됩니다. 즉 셋업되면서 설정에 따라 클러스터에 멤버가 되는거지요.  서비스 디스커리리 클라이언트도 똑같은 방법으로 설치되고요. 

즉 configuratno management시에 필요한 클러스터링 툴, 서비스 디스커버리 툴이 설치되고 우리가 작성한 설정에 따라 자동으로 멤버쉽이 형성되면서 이제 클러스트에 하나의 노드가 되지요. 따라서 스케줄러가 이넘이 놀고 있으니 JOB을 할당 하여 분산을 실행할꺼고 분산 중에 어플리케이션이 재배치 되는 과정중에 서비스 레지스트리가 업데이트 되면서 지속적으로 위치를 파악할 수 있게 됩니다. 

그림은 업데이트 할께요. 

미니 헤로쿠, PaaS Deis 심플 아키텍처 이야기

안녕하세요. Kin 입니다. 

오늘은 블로깅을 오픈한 기념으로 미니 히로쿠(Heroku)라고 불리는 Deis( Day-iss, 다이쓰 라고 발음) 라고 불리는 PaaS 플랫폼을 소개할까 합니다. 

자! 우선 많은 분들이 AWS기반 헤로쿠를 사용해보신 분도 많겠지만(?)
아직 신세계를 발견 못하시는 분들

또는  

헤로쿠가 많이 비싸서 사용 못하시는 분들은 일단 미니 헤로쿠, 다이쓰를 한번 써보시는 것도 좋은 듯합니다. 

만병 통치약은 아니지만( 플랫폼 적인 제한이 있습니다.)
개념을 이해하시면 다른 PaaS(나중에 리스트 함 뽑아보겠습니다)으로
전환도 그리 어렵지 않게 하실 수 있을듯 합니다. 

Deis 는 오픈 소스 PaaS 플랫폼입니다. 헤로쿠의 영감을 얻은 비슷한 workflow를 구현한 구현체 기본적으로 

CoreOS + Fleet(오케스트레이션 툴) + Systemd + etcd(서비스 디스커버리) 조합을 베이스로 구현되었으며 세계적으로 가장 hot한 docker 컨테이너 기술을 기반을 지원하는 PaaS입니다. 

클라우드 기본개념이 필요하시다면 Devops 핵심 요약! 클라우드의 서브시스템/컴포넌트 글을 참조하세요.

deis 기본 라이프싸이클

1. 사용자가  deis에 내장되어있는 git server에 푸쉬.
2. Deis 자동적으로 빌드, 테스트 , 패키징등의 빌드 파이프라인을 가동시켜 docker image를 생성 
3. 생성된 image를 docker registery에 저장
4. Scheduler는 docker registry를 감지하고 이 이미지를 스케줄링 설정에 따라 다양한 클라우드 플랫폼 프로바이더(AWS, GCE, Ausure 등) 에 launch.

Deis subysystem

기본적으로 DCOS , Kubernete, Mantle 등의 클라우드 하이레벨 오케스트레이션 솔루션들은 각 노드들의 역할(보통 마스터/슬레이브) 구조 역할을 정의하고 비슷한 역할을 합니다. 즉 하나를 제대로 이해하시면 나머지도 쉽게 이해 하실 수 있으니 찬찬히 살펴보세요. 

@ Control Plane subsystem

  The Control Plane dispatches work to the Data Plane via a scheduler performs management functions for the platform (in blue) are all implemented as Docker containers.

•    Control pane Components
•  Controller - end uesr interface which expose HTTP API.  the controller contains the scheduler, which decides where to run app containers. ( 필터와 같이 제약 조건을 통해 배치 노드를 지정 할 수 있다라는 의미)
• Builder - GIT build server
• Git server 사용
• Build docker file
• Docker registry 에 image 등록
• Release 관리 - 서로 연결된 컨네이너를 정보를 가지고 한 컨네이너가 버전업이 되면 디펜던시를 가진 다른 컨테이너도 redploy
• Store - blob storage that stores statuful control plane's components
• Registry - docker registry to store docker image
• Database - postgresql to store state of platform  (백업 정보 저장)
• Logger - syslog server to aggregate logs from data plane Can be queryed by controller

@ Data plane subsystem

  Schedule containers !

•   Data plane Components
• Publisher - publish containers to router (퍼블릭하게 만듬 etcd를 통해)
• Logspout - feed log to control plane logger

@ Router Mesh

  used to route traffic to both the Control Plane and Data Plane.   Publish application to consumers, Exposes containers in data plane.  Use service discovery, etcd

  흥미가 생깃 deis doc 문서를 참조하세요.