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 ingee
TAG docker

댓글을 달아 주세요

Docker Storage 이해

Dev & Ops 2016.12.16 10:25

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으로 설정/운영해야 함.

- 도커 스토리지가 충분한 공간 위에서 안정적으로 운영되지 못하면,

  사용하는 컨테이너 이미지의 종류가 다양해질수록

  또 실행중인 컨테이너의 수가 많아질수록 시스템이 정상동작하지 못할 가능성이 높아짐.



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 ingee
TAG docker

댓글을 달아 주세요

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 ingee

댓글을 달아 주세요

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 ingee

댓글을 달아 주세요

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 ingee

댓글을 달아 주세요

  1. 2016.11.10 21:27  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • ingee 2016.11.13 11:54 신고  댓글주소  수정/삭제

      새로운 kind를 추가하는 것은 가능하겠지만, 제겐 방법을 말씀 드릴만큼의 지식이 없습니다. ^^;;

      "IaaS 레이어만 지원하고 있는 k8s..." 라는 표현과, "PaaS, SaaS 레이어를 지원할 수 있도록..." 이라는 표현은, 나중에 적절한 기회가 있다면, 서로의 정확한 이해를 위해 토론이 필요할 것 같습니다.

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 ingee
TAG docker, LXD

댓글을 달아 주세요

  1. nercy 2017.09.21 13:14 신고  댓글주소  수정/삭제  댓글쓰기

    와.. 혹시 자료를 좀 퍼가도 될까요?

    • ingee 2017.09.22 09:07 신고  댓글주소  수정/삭제

      CCL 라이선스에 의거, "출처를 밝히고, 상업적으로 사용하지 않고, 내용을 변조하지 않는 한도" 안에서 얼마든지 퍼가셔도 좋습니다.

Docker Swarm


+ 도커社가 직접 만든 클러스터링 솔루션
+ 여러대의 도커 호스트 머신들을 가상의/싱글 도커 호스트 머신처럼 만드는 솔루션
+ 기능
  . 서비스 디스커버리
  . 스케쥴링
  . Swarm API
+ 상용화 준비 완료 (Production Ready)
  . 1K 노드 & 50K 컨테이너 규모의 테스트/검증
    https://www.docker.com/products/docker-swarm#/demo
    (2분 남짓의 데모 동영상. 볼만함)
+ 아파치 라이선스
  . 2016년 03월, v1.2.0
  . 2015년 11월, v1.0.0 릴리즈
+ 제시된 로드맵 중 <Swarm API를 Docker API와 비슷하게 만들기>가 가장 기대됨
+ 작년까지 완성도에 대한 불만이 많았으나 많이 개선된 느낌. 확인이 필요함.




저작자 표시 비영리 변경 금지
신고
Posted by ingee
TAG docker, Swarm

댓글을 달아 주세요

도커 & 쿠버네티스의 네트워크 모델

 

도커의 네트워크 모델

도커 기초 개념

+ 호스트 머신

- 컨테이너를 실행/운영하는 머신

1개의 호스트 머신 위에서 여러 개의 컨테이너들이 실행됨

+ 컨테이너

- 리눅스의 cgroups, namespaces 기술을 기반으로 만들어진 CPU/ File System/ Network이 격리된 환경

- 독자적인 CPU/ File System/ Network 환경을 갖는다는 측면에서 VM과 유사, 하지만 본질은 그냥 평범한 리눅스 프로세스

- 하이퍼바이저 같은 중간 레이어 없이 호스트 머신의 커널 바로 위에서 실행되기 때문에 실행 성능 저하가 전혀 없음

- 하이퍼바이저 & VM 모델에 비해 리소스 오버헤드가 없음

 

도커가 해결해야 하는 네트워크 문제

1개의 호스트 머신 위에서 여러 개의 컨테이너들이 동작하는 상황에서, 도커는 네트워크 측면에서 다음 문제들을 해결해야 함

1.      호스트 머신 내부에 존재하는 컨테이너들 사이의 네트워크 연결을 보장해야 함

2.      호스트 머신 외부와 컨테이너 사이의 네트워크 연결을 보장해야 함

 

도커는 네트워크 문제 해결을 위해 veth (Virtual ETHernet) 기술을 이용

+ veth는 서로 연결된 2개의 가상 네트워크 디바이스 (http://lwn.net/Articles/232688/ 참조)

+ 반드시 2개가 동시에 생성됨 (created in pairs)

- veth 생성 명령: $ ip link add veth0 type veth peer name veth1

- 어느 한쪽 디바이스에 패킷을 보내면, 다른쪽 디바이스로 패킷이 전달됨 (반대 방향도 마찬가지)

+ 네트워크 Namespace 장벽 사이의 통신을 위해 사용 (http://www.opencloudblog.com/?p=66 참조)

 

도커 네트워크 환경의 구성 과정

도커 데몬이 실행되면 호스트 머신에 docker0 (가상 네트워크 브릿지)가 생성됨

도커 컨테이너를 실행하면 해당 컨테이너를 위한 veth (가상 네트워크 장치) pair 가 생성됨

생성된 veth pair의 한쪽 끝은 컨테이너 안으로 격리되어 eth0로 이름이 바뀜 (컨테이너 안에서만 보여짐)

다른쪽 끝은 호스트 머신에 vethXXXX 이름으로 존재하며 docker0 브릿지에 연결됨

같은 호스트 머신에서 실행되는 컨테이너들은 docker0 브릿지를 매개로 서로 연결 가능



도커 네트워크 모델

 

+  호스트 머신 밖으로 서비스를 제공해야 하는 컨테이너는 호스트 머신의 네트워크 포트를 점유할 수 있음 (도커 run -p 옵션)

+ 호스트 머신의 네트워크 포트를 맵핑하는 컨테이너가 여러 개일 경우, 어플리케이션별 네트워크 포트 관리 필요 --> 개인 개발이 아닌 팀 단위 개발에서는 실질적으로 불가능 --> 쿠버네티스가 우아하게 해결!


컨테이너와 호스트 머신 사이의 포트 맵핑

 

쿠버네티스(이후 k8s)의 네트워크 모델

k8s 기초 개념

+ Master

- k8s 클러스터를 관리하는 머신

+ Node

- k8s 클러스터를 구성하는 머신

- 도커 컨테이너 실행을 담당

- 얼마 전까지 'Minion'이라고 불렸음

+ Pod

- 서로 관련된 컨테이너들을 묶어 놓은 집합

- k8s의 배포/운영/관리의 단위

+ Service

- 같은 일을 하는 Pod 들의 집합

- k8s 클러스터 내에서 고유한/고정된 IP 주소 부여

- Service에 소속된 멤버 pod들에 대해 로드밸런싱 기능 수행

 

k8s가 해결해야 하는 네트워크 문제

여러 노드로 구성된 클러스터를 운영하는 k8s는 네트워크 측면에서 다음 문제들을 해결해야 함

1.      긴밀한 관계가 있는 컨테이너와 컨테이너 사이의 네트워크 연결을 보장해야 함 (Pod 네트워크 모델)

2.      Pod Pod 사이의 네트워크 연결을 보장해야 함 (Pod 네트워크 모델)

3.      서버 역할을 수행하는 Pod가 크래쉬로 인해 다시 시작되더라도 클라이언트는 네트워크 설정 변경 없이 원래 서버에 접근할 수 있어야 함 (Service 네트워크 모델)

 

Pod 네트워크 모델

+ Pod k8s 운영/관리의 기본 단위

+ k8s 클러스터 안에서 실행되는 모든 컨테이너들은 Pod 단위로 관리됨

- 1개의 Pod에 여러 개의 컨테이너가 존재할 수 있음

- k8sPod마다 고유한 IP주소를 부여


k8s 클러스터의 Pod 네트워크 모델

 

+ Pod를 실행하면 Pod 안에 ‘pause’라는 이름의 컨테이너가 생성/실행됨

+ pause 컨테이너는 Pod의 네트워크 환경 (IP주소, 라우팅 테이블, …)을 만드는 역할만 수행함 (다른 일은 전혀 하지 않음)

+ Pod 안의 다른 컨테이너들은 pause 컨테이너가 만든 네트워크 환경을 공유


Pod 네트워크 상세 (with pause 컨테이너)

 

Service 네트워크 모델

+ Pod는 크래쉬될 수 있음

+ Pod가 크래쉬되면 k8sPod를 다시 살림 (k8s Replication Controller의 역할), 하지만 이 과정에서 IP 주소가 새로 할당 됨

+ 클라이언트 측의 네트워크 설정을 변경하지 않고 Pod가 제공하는 서비스에 안정적으로 접근할 수 있는 방법이 필요 ==> Service!

+ Service는 다수의 멤버 end-point들로 구성

Service는 멤버 end-point들에 대한 로드밸런싱 기능을 수행


k8s Service의 네트워크 모델

 

(이상)

저작자 표시 비영리 변경 금지
신고
Posted by ingee

댓글을 달아 주세요

  1. 2015.11.23 15:49  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

Mesos & CoreOS & 기타등등 요약
도커 클러스터 운영을 위한 솔루션


Mesos
+ Mesos는 Mesohpere(회사)가 만든 Data Center OS

+ 현재 아파치 재단에 의해 오픈소스 프로젝트로 운영
+ 데이터센터 내의 자원을 공유/격리/관리하는 솔루션
+ Twitter, Facebook, eBay, Riot Games(LOL 개발사)에서 이용


ZK: ZooKeeper

<<이미지 출처: https://www.digitalocean.com/community/tutorials/an-introduction-to-mesosphere>>



Mesos Marathon
+ Mesosphere가 만든 Mesos용 Framework (Mesos의 작업 관리자)
  - Framework는 Mesos 구성요소 중 하나
  - Mesos가 데이터센터의 커널이라면, Marathon은 init나 upstart 데몬에 해당
+ Mesos 위에 (도커) 컨테이너를 deploy하고 manage
  - 도커 컨테이너를 deploy, run, scale 하려면 Marathon 0.7.0+ 와 Mesos 0.20.2+ 필요
+ 어플리케이션의 starting, stopping, scaling 을 위한 REST API 제공



CoreOS
+ CoreOS?
  - Docker 구동에 최적화된 가볍고 최소화된 OS
  - 컨테이너 클러스터 운영을 위한 OS
+ CoreOS의 특징
  - 미니멀 OS
  - 도커 컨테이너 지원
  - 처음부터 클러스터를 고려 (Clustered By Default)
+ CoreOS는 거의 모든 플랫폼에서 실행 가능
  - Vagrant, Amazon EC2, VMWare, OpenStack 기반 VM 및 커스텀 HW에서 실행 가능


<<처: https://www.airpair.com/coreos/posts/coreos-with-docker>>


  + CoreOS : 미니멀 리눅스 OS
  + rkt 또는 docker : 컨테이너 런타임
  + etcd : HA를 보장하는 key-value 저장소
    - 모든 호스트는 etcd에 접근하기 위한 로컬 endpoint를 제공

    - 모든 어플리케이션은 항상 127.0.0.1:4001 에서 etcd 에 접근 가능
    - etcd는 replicated 되어 관리되며, 모든 정보를 클러스터 전체가 공유함
  + systemd : 머신 단위 시스템 구동 도구
  + fleet : 클러스터 단위 시스템 구동 도구
    - CoreOS 위에서 도커 컨테이너를 실행시킬 때 fleet와 함께 실행시키는 것을 권장
    - fleet는 HA 보장; 서비스 컨테이너가 같은 머신/zone/region에 배치되지 않도록 관리
    - fleet는 속성에 따른 배치(collocation with the same properties) 보장

    - 속성값을 조정하여 서비스 아키텍처를 관리



Boot2Docker
+ Windows와 Mac OS에서 도커를 실행시킬 수 있는 도구
  - 도커는 리눅스에서만 실행됨
  - boot2docker는 내부적으로 VirtualBox를 이용
+ 도커 구동을 위해 만든 경량 리눅스 배포판을 이용
  - 작은 크기(~24MB), 빠른 부팅(~5s)


ref
---
http://www.albireo.net/threads/45289/
http://mimul.com/pebble/default/2013/10/27/1382885361083.html
http://www.yongbok.net/blog/apache-mesos-cluster-resource-management/
https://github.com/mesosphere/marathon
https://coreos.com/
https://coreos.com/using-coreos/
http://www.slideshare.net/subicura/coreos-38279596
http://www.moreagile.net/2014/07/docker-coreos.html
http://majesty76.tistory.com/43
http://lunatine.net/about-systemd/
https://github.com/coreos/fleet
https://github.com/boot2docker/boot2docker
http://www.slideshare.net/pyrasis/learning-dockerandboot2docker

저작자 표시 비영리 변경 금지
신고
Posted by ingee
TAG docker

댓글을 달아 주세요

컨테이너 오케스트레이션 시스템, "쿠버네티스(Kubernetes)"

 

Kubernetes?

- 상용 레벨 적용이 가능한 오픈소스 컨테이너 오케스트레이션 시스템

- 빠른 Dev와 간단한 Ops를 지향하는 "리눅스 컨테이너 클러스터" 관리 도구

  : Manage a cluster of Linux containers as a single system to accelerate Dev and simplify Ops

 

Kubernetes 관련 동향

- 구글, Kubernetes 프로덕션 레디 버전 출시 (@OSCON 컨퍼런스, 7.21)

- 리눅스 재단, CNCF( Cloud Native Computing Foundation ) 설립 공표

  . 클라우드 & 컨테이너 친화적 어플리케이션을 위한 기술 개발이 목표

  . 구글, CNCF를 통해 Kubernetes를 발전시킬 계획임을 발표 (Kubernetes CNCF에 기증)

  . AT&T, Box, Cisco, Cloud Foundry, CoreOS, Docker, eBay, Google, Huawei, IBM, Intel,

Joyent, Mesosphere, Red Hat, Twitter, VMware 등 참여

  . 회원사(founding member) 모집중!

- 구글, "컨테이너 엔진" 사업 시작

  . https://cloud.google.com/container-engine/

  . Kubernetes를 호스팅하여 제공하는 managed 서비스

  . 베타 서비스 (몇 주 전까지만 해도 알파 서비스였음)

  . 특징

    - 도커 컨테이너 포맷 지원

    - 선언에 의한 관리(Declarative Management)

      : 컨테이너의 운영 요구조건(CPU/MEM, 리플리카 갯수, KeepAlive 정책)

JSON 파일에 선언하면, 컨테이너 엔진(Kubernetes)이 운영을 보장

  . 가격

    - "컨테이너 엔진"은 구글 "컴퓨트 엔진"이 제공하는 VM 위에서 동작

    - 베타 기간 동안 "컨테이너 엔진"에 대한 과금은 없으며, "컴퓨트 엔진" 사용량만 과금

 

Kubernetes 주요 개념/구성요소

- 클러스터(cluster)

  . 어플리케이션 컨테이너들이 배치되고 실행되는 컴퓨팅 자원

- 파드(pod)

  . 어플리케이션 실행에 필요한 도커 컨테이너들의 집합

  . 생명주기를 같이 하는 컨테이너들의 그룹

  . Kubernetes를 통한 배포(deploy) 및 실행의 최소 단위

- 리플리케이션(replication) 컨트롤러

  . pod들의 라이프사이클 관리자

  . 사용자의 선언(JSON 파일)에 따라 Pod 숫자(replica 숫자)를 관리

  . Pod들의 health status를 체크

- 서비스(service)

  . 관련 pod 집합을 대표하는 단일한/안정적인 이름 (IP Addr, ...)

  . 로드밸런서

- 레이블(label)

  . pod들의 그룹핑/조직화를 위해 관리하는 key-value pair/메타데이터

 

(이상)

저작자 표시 비영리 변경 금지
신고
Posted by ingee

댓글을 달아 주세요