시작하며

터미널 작업자에게 TMUX는 축복 같은 도구다. TMUX를 쓰면 터미널 작업의 효율성이 극적으로 높아진다.

1. 우선 어떤 작업이 오래 걸릴 경우 그 작업이 끝날 때까지 멍하니 기다릴 필요가 없다. 즉시 다른 Window나 Pane을 열고 다른 작업을 시작할 수 있다.
2. 또 어떤 작업을 하다 사정이 생겨 터미널 접속을 끊어야 할 경우 기존 작업이 중단되는 것을 걱정하지 않아도 된다. 터미널을 끊어도 하던 작업이 중단되지 않는다 (다시 말해 Session이 유지된다). 다음에 다시 접속해서 하던 작업을 이어 할 수 있다.

설치방법

설치 방법도 쉽다. 리눅스 사용자라면 표준 패키지 매니저를 이용해서 설치하면 된다.

• (우분투라면) sudo apt-get install tmux
• (CentOS라면) sudo yum install tmux

사용방법

CTRL-b 키가 TMUX의 기능을 부르는 핵심 키다.

0. TMUX 실행

$ tmux

1. Window 만들기, 이동하기

• window 만들기 (create window) : CTRL-b, c
• window 이동하기 (next window) : CTRL-b, n

2. Pane 나누기, 이동하기

• 가로 pane 나누기: CTRL-b, "
• 세로 pane 나누기: CTRL-b, %
• pane 이동하기: CTRL-b, 화살표

3. 세션 끊기, 이어하기

• 세션 끊기 (detach) : CTRL-b, d
• 세션 이어하기 (attach) : tmux a

터미널 접속만 가능한 소박한 환경에서도 TMUX와 VIM만 있으면 충분히 많은 일을 할 수 있다.

터미널 만세!

Docker 는 기능 뿐 아니라 가이드 문서도 꾸준히 버전업 하고 있음.
년초를 맞아 Docker 가이드 문서를 다시 살펴볼 수 있는 기회가 있었음.
눈에 띈 내용을 요약함

Docker 어플리케이션 개발자를 위한 베스트 프랙틱스

출처: https://docs.docker.com/develop/dev-best-practices/

어플리케이션 데이터를 어디에 저장해야 하나

• 어플리케이션 데이터를 Docker Storage (컨테이너에 할당된 디폴트 파일 시스템)에 저장하지 마라
• 대신, 도커 Volumes 를 사용하라
• 만약 상황이 적절하다면, 도커 Bind mount 도 괜찮다
• Swarm Service 를 운영할 경우, 민감한 데이터는 Secrets 를 이용하라 (민감하지 않은 데이터는 Configs 를 이용하라)

개발환경과 운영환경의 차이

도커 네트워크 드라이버 요약

출처: https://docs.docker.com/network/

도커 네트워크 드라이버 요약

네트워크 성능 최적화가 필요한 Hyperledger Fabric 운영의 경우, Host network 모드 사용을 검토해볼만 함

어플리케이션 데이터 다루기

출처: https://docs.docker.com/storage/

• Volumes : 어플리케이션 데이터를 도커가 관리하는 파일시스템 영역에 저장 (가장 권장하는 방식)
• Bind mounts : 어플리케이션 데이터를 호스트 파일시스템에 저장 (조건만 맞는다면 괜찮은 방식)
• tmpfs : 어플리케이션 데이터를 호스트 메모리에(만) 저장 (데이터를 호스트 파일시스템에 절대 저장하지 않으므로 기밀성이 좋다)

기타 팁

편리한 docker prune 명령 (컨테이너, 네트워크, 이미지, 캐시와 함께 Volume 까지 한꺼번에 정리)

$ docker system prune --volumes
WARNING! This will remove: 
        - all stopped containers 
        - all networks not used by at least one container 
        - all volumes not used by at least one container 
        - all dangling images 
        - all build cache 
Are you sure you want to continue? [y/N] y

(이상)

docker prune 명령 요약

• docker system prune -f
  • 종료된(exit 상태의) docker container들을 모두 내리고, 쓸모 없는 image (dangling image)들을 제거
  
  
• docker volume prune -f
  • 참조되지 않는 (현재 사용하지 않는) docker volume을 제거
  • volume의 life-cycle과 container의 life-cycle은 별개, 따라서 컨테이너가 종료되어도 컨테이너가 쓰던 볼륨은 스토리지에 남아 있게 된다.
  • 스토리지 공간이 모자라 골치 아픈 시스템 관리자에게 매우 유용한 명령
  
  
• docker network prune -f
  • 현재 사용하지 않는 docker network 제거
  
  

도커 운영 중, 호스트 머신의 스토리지가 가득찼을 때

현상

docker storage를 충분한 크기로 적절히 설정하고 운영함에도 host 머신의 스토리지가 full 되는 경우가 있다.

# df
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        10G  3.9G  6.2G  39% /
/dev/vdc1        10G  10G     0   100% /var
/dev/vdd1       100G  7.5G   93G   8% /home
...

설명

• /var/lib/docker/containers/ 디렉토리 아래, <container-id>/<container-id>-json.log 파일이 스토리지를 모두 차지했을 수 있다
• 이 파일은 도커가 docker logs 명령 실행시 출력할 로그를 저장하는 파일이다 (docker storage에 저장되지 않고 host 머신의 파일 시스템을 소진한다)
• 도커 실행시 max-size 옵션을 설정하면 로그 파일의 크기를 제한할 수 있다
• 도커 실행시 max-file 옵션을 설정하면 로그 파일의 개수를 제한할 수 있다 (log rotate 효과)

해법

$ sudo vi /etc/docker/daemon.json
...다음 내용 추가...
{
  "log-driver": "json-file",
  "log-opts": {
    "mode": "non-blocking",
    "max-size": "4m",
    "max-file": "3"
  }
}

$ sudo systemctl restart docker

Ref

• Set container log limits when Docker is filling up /var/lib/docker with large log files.
• Configure logging drivers
• About images, containers, and storage drivers

2018.10.15 덧붙임

컨테이너 안에서 파일을 저장하려면 data volume을 이용하는 것이 좋다 (강력히 권장. data volume 사용이 애매하면 mount volume도 권장).

• 컨테이너 안에서의 파일 I/O는 storage driver에 의해 처리되며, 이는 일반 file I/O보다 큰 오버헤드를 감수해야 한다 (CoW 처리 때문)
• 하지만, data volume 을 이용한 (컨테이너 안에서의) 파일 I/O는 storage driver를 우회하여 처리되며, host 머신의 file I/O와 동일한 속도로 처리된다
• data volume (또는 mount volume)을 이용하려면 docker run 명령으로 컨테이너를 실행할 때, -v 옵션으로 볼륨을 지정하면 된다

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으로 설정/운영해야 함
• loopback device (loop-lvm)는 상용 서비스를 처리하기엔 성능이 너무 안 좋음 (https://forums.docker.com/t/loopback-storage-devices/22007/2)

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/

(이상)

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 하는 것을 권한다
      그러면, 어떤 파일이 바뀌었을 때 캐시-이미지를 활용할 가능성이 커진다

(이상)

Mesos 101 (Mesos 첫걸음)

개요

Mesos를 이용, 서버 클러스터를 운용해야 하는 상황이 되었다. Mesos 설치/운영 방법을 찾아야했는데, 정말 좋은 자료를 발견했다.

Mesos Advanced Course
https://open.mesosphere.com/advanced-course/
이름은 "Advanced Course" 이지만, Mesos 설치부터 운영까지 꼭 필요한 내용만 "쉽게" 설명한다. 동영상을 보며 따라 배우기도 좋고, 글로 요약된 내용을 뒤적이며 매뉴얼로 쓰기도 좋다.
열심히 집중하면 하루에 모든 진도를 끝내는 것도 가능할 것 같다.

특이했던 점

* ZooKeeper가 (의외로) 필수 컴포넌트
  . ZooKeeper는 HA 보장을 위한 optional 요소라고 생각했는데, 필수였다
  . ZooKeeper가 HA 보장 뿐 아니라 클러스터의 상태를 저장/관리 기능도 제공했다
  . 그래서 Mesos Master를 1개만 두는 구성에서도 ZooKeeper가 필요했다

* docker containerizer가 아닌 mesos containerizer가 디폴트
  . Mesos가 클러스터 위에서 실행시키는 모든 어플리케이션은 컨테이너다
  . 그런데 역사적으로 Mesos는 Docker보다 오래됐다
  . 그래서 Mesos의 디폴트 containerizer는 docker가 아니라 mesos containerizer 다
  . Mesos containerizer는 도커 이미지도(!) 실행시킬 수 있다

(이상)

k8s vs swarm 비교 요약

솔루션 특징 요약
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개 상태에 도달하는 방식

성능 테스트 결과

k8s vs swarm 테스트 스크립트 비교

(이상)