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 ingeeC
,

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

 

도커의 네트워크 모델

도커 기초 개념

+ 호스트 머신

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

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 ingeeC
,

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 ingeeC
,

컨테이너 오케스트레이션 시스템, "쿠버네티스(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 ingeeC
,

도커(Docker) 커맨드 요약

출처: The Docker Book (지은이:제임스 턴불, 옮긴이:장독대, 출판사:루비페이퍼)


도커 관련 개념
+ 도커 이미지
  - 컨테이너 실행을 위해 필요한 프로그램/라이브러리/소스파일 등의 묶음
  - docker build 명령으로 이미지 생성
  - 이미지는 레지스트리에 존재
  - 디폴트 레지스트리는 Docker Inc가 관리하는 퍼블릭 레지스트리인 도커 허브(Docker Hub)
+ Dockerfile
  - 도커 이미지 생성을 위해 작성하는 파일
  - C/C++ 빌드시 사용하는 Makefile에 해당
+ 도커 컨테이너
  - 도커 이미지를 실행한 상태
  - 하나의 이미지로 여러개의 컨테이너를 만들 수 있음
  - docker run 커맨드로 컨테이너 실행
+ union mount
  - 한번에 여러 파일 시스템 layer를 마운트 하지만 마치 하나의 파일 시스템처럼 보이도록 마운트
  - 도커의 파일 시스템은 bootfs부터 layer 형태로 쌓인다
+ 복사후 쓰기 (Copy On Write)
  - 파일을 변경하려면 그 파일은 아래에 존재하는 읽기-전용 레이어로부터 읽기-쓰기 레이어로 복사된다
  - 파일의 읽기-전용 버전은 사라지는 것이 아니라 계속 존재

도커 관련 서비스
+ Quay
  - 퍼블릭 & 프라이빗 레지스트리 서비스 제공
  - 도커 허브의 대안
+ Orchard
  - https://www.orchardup.com/
  - Get Docker host in the cloud, instantly
  - 프라이빗 레지스트리 서비스 제공
  - 도커 컨테이너의 클라우드 호스팅 서비스 제공
  - 유료 서비스
  - Simple PaaS?

Docker 커맨드
+ docker attach 커맨드: 컨테이너에 재접속
+ docker build 커맨드: 도커 이미지 빌드
  > -t 옵션: 레포지터리 이름을 지정
+ docker images 커맨드: 도커 이미지 리스트 확인
+ docker info 커맨드: 도커가 정상 동작하는지 확인
+ docker inspect 커맨드: 컨테이너 상세 정보 확인
+ docker logs 커맨드: 컨테이너의 로그를 가지고 온다
  > -f 옵션: 로그 tailing
  > -f --lines 옵션
  > -t 옵션: 로그를 타임스탬프와 함께 출력
+ docker ps 커맨드: 실행중인 컨테이너 목록 확인
  > -a 옵션: 중지된 컨테이너 포함, 모든 컨테이너 목록 표시
  > -l 옵션: 포트 맵핑 확인
+ docker pull 커맨드: 도커 레지스트리에서 도커 이미지 가져오기
  > 디폴트 레지스트리는 Docker Inc가 관리하는 퍼블릭 레지스트리인 도커 허브(Docker Hub)
+ docker push 커맨드: 이미지를 도커 허브에 넣는다
+ docker rm 커맨드: 컨테이너 제거
+ docker run 커맨드: 도커 컨테이너 실행
  > -i 옵션: 컨테이너가 STDIN을 오픈해서 유지하도록 지정
  > -t 옵션: 컨테이너에 pesudo-tty(터미널)를 할당
  > 실행중인 컨테이너 내부에서
  >     ps 명령으로 컨테이너 프로세스 체크 가능
  >     apt-get 명령으로 SW 패키지 설치 가능
  > --name 옵션: 컨테이너 이름을 지정
  >    옵션을 사용하지 않으면 임의의 이름을 자동 할당
  > -d 옵션: 컨테이너를 데몬 형태로 실행
  > 포트 오픈 옵션
  > -p 옵션: 컨테이너의 어떤 네트워크 포트를 오픈할지 지정
  >     Dockerfile의 EXPOSE 명령으로 지정한 포트의 오픈 여부가 실행단계에서 결정된다
  > -P 옵션: Dockerfile에서 EXPOSE된 모든 포트를 오픈
  > -v 옵션: 호스트에 있는 디렉터리를 컨테이너 안의 볼륨(디렉토리)으로 맵핑
  >     어플리케이션이나 코드가 아직 완성되지 않아서 이미지에 포함하고 싶지 않은 경우 유용
  >     목적지에 rw나 ro 옵션을 추가하여 목적지의 읽기/쓰기 상태 설정 가능
  > --link 옵션: 컨테이너와 컨테이너의 네트워크를 연결
  >     두개의 인자를 요구
  >     하나는 링크할 컨테이너의 이름
  >     다른 하나는 링크를 위한 alias
+ docker start 커맨드: 중지된 컨테이너 시작
+ docker stop 커맨드: 데몬 컨테이너를 중지
+ docker top 커맨드: 실행 중인 프로세스를 조사

Dockerfile 명령어
+ EXPOSE 명령: 컨테이너에 있는 어플리케이션이 컨테이너에 있는 특정 포트를 사용하도록 지정
  > docker run 커맨드로 컨테이너를 실행할 때 포트를 오픈할 수 있도록 대기
+ ENV 명령: 이미지에 환경 변수 설정
  > docker run 실행시 -e 옵션으로도 전달 가능
+ CMD 명령: docker run 커맨드로 컨테이너를 생성할 때 실행할 명령을 설정
+ ENTRYPOINT 명령: CMD와 유사, 쉽게 오버라이되지 않는 실행 명령을 설정
+ WORKDIR 명령: 컨테이너를 위한 작업 디렉터리 설정
  > docker run 실행시 -w 옵션으로 오버라이딩 가능
+ VOLUME 명령: 컨테이너에 볼륨(디렉토리)을 추가
  > 볼륨은 컨테이너 사이에서 공유되고 재사용된다
  > 컨테이너는 볼륨을 공유하기 위해 실행될 필요 없다
  > 볼륨에 대한 변경은 바로 적용된다
  > 볼륨 변경은 이미지 업데이트시 포함되지 않는다
  > 볼륨은 컨테이너가 사용하지 않을 때까지 유지된다
+ ADD 명령: 이미지에 파일과 디렉토리를 추가
+ COPY 명령: ADD 명령과 유사, 파일 복사에 집중, 자동 압축 해제 같은 기능 없음


(이상)


Posted by ingeeC
,