6. 도커 데몬

 지금까지 도커를 사용하는 방법에 대해 알아보았습니다. 가장 먼저 알아야 할 컨테이너부터 시작해서 컨테이너의 밑바탕이 되는 이미지, 이미지를 생성할 수 있는 Dockerfile을 알아보았습니다. 그렇다면 이제는 도커 자체를 다뤄볼 차례입니다. 도커 자체에 사용할 수 있는 여러 옵션을 익히면 컨테이너와 이미지를 좀 더 쉽게 사용할 수 있을뿐더러 도커를 이용한 개발이 수월해집니다.

 

도커의 구조

도커는 /usr/bin/docker 에 위치한 파일을 통해 사용되고 있습니다. 컨테이너와 이미지를 다루는 명령어는 /usr/bin/docker 에서 실행되지만 도커 엔진의 프로세스는 /usr/bin/dockerd 파일로 실행되고 있습니다. docker 명령어가 실제 도커 엔진이 아닌 클라이언트로서의 도커이기 때문입니다.

도커의 구조는 크게 2가지로 나뉘는데, 하나는 클라이언트로서의 도커와 서버로서의 도커입니다. 실제로 컨테이너를 생성하고 실행하며 이미지를 관리하는 주체는 도커 서버이고, 이는 dockerd 프로세스로서 동작합니다. 도커 엔진은 외부에서 API 입력을 받아 도커 엔진의 기능을 수행하는데, 도커 프로세스가 실행되어 서버로서 입력을 받을 준비가 된 상태를 도커 데몬이라고 이야기합니다.

 

도커 데몬은 API 입력을 받아 도커 엔진의 기능을 수행하는데, 이 API를 사용할 수 있도록 CLI(Command Line Interface)를 제공하는 것이 도커 클라이언트입니다. 사용자가 docker로 시작하는 명령어를 입력하면 도커 클라이언트를 사용하는 것이며, 도커 클라이언트는 입력된 명령어를 로컬에 존재하는 도커 데몬에게 API로서 전달합니다. 이때 도커 클라이언트는 /var/run/docker.sock에 위치한 유닉스 소켓을 통해 도커 데몬의 API를 호출합니다.

 

[ 일반적으로 도커 데몬을 제어하는 순서 ]

1. 사용자가 docker version과 같은 명령어를 입력합니다.

2. /usr/bin/docker는 /var/run/docker.sock 유닉스 소켓을 사용해 도커 데몬에서 명령어를 전달합니다.

3. 도커 데몬은 이 명령어를 파싱하고 명령어에 해당하는 작업을 수행합니다.

4. 수행 결과를 도커 클라이언트에게 반환하고 사용자에게 결과를 출력합니다.

 

 

도커 데몬 옵션

도커 데몬에 적용할 수 있는 옵션은 매우 많기에 간단하게 알아보도록 하겠습니다. 

 

1) 도커 데몬 제어 : -H

-H 옵션은 도커 데몬의 API를 사용할 수 있는 방법을 추가합니다. -H에 IP 주소와 포트 번호를 입력하면 원격 API인 Docker Remote API로 도커를 제어할 수 있습니다. Restful API 형식을 띠고 있으므로 HTTP 요청으로 도커를 제어할 수 있습니다. 만약 -H에 unix:///var/run/docker sock을 지정하지 않고, 옆과 같이 Remote API만을 위한 바인딩 주소를 입력했다면 유닉스 소켓은 비활성화되므로 도커 클라이언트를 사용할 수 없게 되며, docker로 시작하는 명령어를 사용할 수 없습니다. 그래서 일반적으로 도커 클라이언트를 위한 유닉스 소켓과 Remote API를 위한 바인딩 주소를 동시에 설정합니다.
#dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375 

 

2) 도커 데몬에 보안 적용 : --tlsverify

도커를 설치하면 기본적으로 보안 연결이 설정돼 있지 않습니다. 보안을 적용할 때 사용될 파일은 총 5개로 ca.pem, server-cert.pem, server-key.pem, cert.pem, key.pem입니다. 클라이언트 측에서 도커 데몬에 접근하려면 ca, cert, key.pem 파일이 필요합니다.

 

3) 도커 스토리지 드라이버 변경 : --storage-driver

도커는 스토리지 백엔드 기술을 사용해 도커 컨테이너와 이미지를 저장하고 관리합니다. 일부 운영체제는 도커를 설치할 때 기본적으로 사용하도록 설정된 스토리지 드라이버가 있는데, 우분투 같은 데비안 계열 운영체제는 overlay2를, 구 버전의 CentOS와 같은 운영체제는 deviceampper를 사용하는것이 대표적 예입니다.

 

 도커를 사용하는 환경에 따라 스토리지 드라이버는 자동으로 정해지지만 도커 데몬 실행 옵션에서 스토리지 드라이버를 변경할 수도 있습니다. 지원하는 드라이버는 OverlayFS, AUFS, Btrfs, Devicemapper 등이 있습니다. 도커가 AUFS 기본적으로 사용하도록 설정된 우분투에서 별도의 OverlayFS 컨테이너와 이미지를 사용하면 AUFS에서 사용했던 이미지와 컨테이너를 사용할 수 없습니다. 스토리지 드라이버는 각 장단점이 있기에 판단을 하고 선택해야 합니다.

 

 

스토리지 드라이버 원리

이미지는 읽기 전용 파일로 사용되며 컨테이너는 이 이미지 위에 얇은 컨테이너 레이어를 생성함으로써 컨테이너의 고유한 공간을 생성한다는 것이었습니다. 이것은 기본적인 개념이고, 실제로 컨테이너 내부에서 읽기와 새로운 파일 쓰기, 기존의 파일 쓰기 작업이 일어날 때는 드라이버에 따라 Copy-on-Write(CoW), Redirect-on-Write(RoW) 개념을 사용합니다. 

 

스냅샷은 사진 찍듯이 특정 시점에 스토리지의 파일 시스템을 포착해 보관하는 기술을 의미합니다. 원본 데이터를 그대로 복사해 다른 곳에 저장하는 백업과 달리 초기 생성 시 혹은 데이터의 변경이 있기 전까지는 스토리지의 공간을 차지하지 않습니다. 메타데이터의 복사본에 해당하기 때문에 생성시간이 적고, 장애 상황이 발생해도 데이터가 빠르게 복원됩니다.

 

CoW : 원본 데이터에 대한 메타데이터만 활용해 스냅샷을 생성하고, 추후 원본 데이터에 수정이 필요할 때 해당 데이터를 스냅샷이 저장된 스토리지 공간으로 복사합니다. 이후 데이터를 수정하기 때문에 스냅샷 데이터가 일관성을 유지하고, 변경된 데이터만을 저장해 스토리지 공간을 효율적으로 사용할 수 있습니다.

 

RoW : CoW 방식에서의 I/O 과정에서 발생하는 오버헤드를 줄입니다. 스냅샷을 위한 별도의 스토리지 공간을 확보할 필요가 없으며, 데이터 변경이 필요한 경우 기존 데이터와 스냅샷 리스트를 고정(Freeze) 한 채 새로운 공간에 수정된 데이터를 작성해 관리합니다.

 

 중요한점은 스냅샷 파일을 불변상태로 유지할 수 있다는 점입니다. 이를 도커 컨테이너와 이미지에 적용해보면, 이미지 레이어는 각 스냅숏에 해당하고, 컨테이너는 이 스냅숏을 사용하는 변경점입니다. 컨테이너 레이어에는 이전 이미지에서 변경된 사항이 저장돼 있으며, 컨테이너를 이미지로 만들면 변경된 사항이 스냅샷으로 생성되고 하나의 이미지 레이어로 존재하게 됩니다.

 도커 이미지는 Dockerfile로 만들어진 여러 레이어로 이루어져 있고 각 레이어는 읽기만 가능(Read-only)합니다. 이미지를 가지고 새로운 컨테이너를 생성하면 읽고 쓸 수 있는 레이어가 추가되는데 이를 컨테이너 레이어라고 합니다. 컨테이너를 가지고 작업을 수행할 때 생기는 변경 사항을 모두 컨테이너 레이어에 저장하고 읽을 때는 도커 이미지에 변경된 상항을 조합해서 데이터를 읽습니다. 컨테이너가 삭제되면 컨테이너 레이너는 사리지지만, 기존 이미지는 변경되지 않고 유지됩니다.

 

만약 컨테이너가 서로 데이터를 공유해야 한다면 도커 볼륨에 저장하고 컨테이너에 마운트하면 됩니다. 도커는 이러한 방식으로 레이어와 파일을 관리하기 위해 스토리지 드라이버를 사용하는 것이고, 리눅스 배포판 커널에 따라 다른 드라이버를 사용하는 것 입니다.

 

 

도커 데몬 모니터링

 도커 데몬을 모니터링하는 데는 여러 가지 이유가 있을 수 있습니다. 많은 수의 도커 서버를 효율적으로 관리하기 위해서일 수도 있고, 도커로 컨테이너 애플리케이션을 개발하다가 문제가 생겼을 때 그 원인을 찾아내기 위해서일 수도 있으며, 도커를 Paas로써 제공하기 위해 실시간으로 도커 데몬의 상태를 체크해야 할 수도 있습니다. 이러한 목적에 부합하는 모니터링 방법은 매우 많은데, 제한적으로나마 도커 엔진 자체가 지원하는 모니터링 기능도 있고, 도커 프로젝트에서 지원하는 상용 솔루션 및 각종 오픈소스 대시보드도 있습니다. 이번에는 하나의 컨테이너뿐만 아니라 도커 데몬 자체를 모니터링하는 방법을 알아보겠습니다.

 

1) 도커 데몬 디버그 모드 -> 도커 데몬에서 어떤 일이 일어나고 있는지 가장 확실하고, 정확하게 자세히 알아내는 방법은 도커 데몬을 디버그 옵션으로 실행하는 것입니다. 이렇게 하면 Remote API의 입출력뿐만 아니라 로컬 도커 클라이언트에서 오가는 모든 명령어를 로그로 출력합니다. 디버그 모드는 도커 데몬에 문제가 생겼을 때 무엇이 잘못됐는지 확인하기 좋은 수단이지만, 로그에는 원하지 않는 정보까지 너무 많이 출력되어 호스트에 있는 파일을 읽거나 도커 데몬을 포그라운드 상태로 실행해야 한다는 단점이 있습니다.

 

2) events, stats, system df 명령어

events -> 도커 데몬에 어떤 일이 일어나고 있는지 실시간 스트림 로그로 보여줍니다. 도커 클라이언트에서 입력하는 모든 명령어가 출력되는 것은 아니며, attach, commit, copy, create 등 컨테이너 관련 명령어, delete, import, load, pull, push 등의 이미지 관련 명령어, 볼륨, 네트워크, 플러그인 등에 관한 명령어의 수행결과가 출력 됩니다. --filter 타입으로 특정 항목에 대한 출력 결과를 지정할 수 있습니다.

stats -> docker stats 명령어는 실행 중인 모든 컨테이너의 자원 사용량을 스트림으로 출력합니다. stats 명령어는 실행 중인 모든 컨테이너의 CPU, 메모리 제한 및 사용량 정보 등 출력합니다.

system df -> 도커에서 사용하고 있는 이미지, 컨테이너, 로컬 볼륨의 총 개수 및 사용 중인 개수, 크기, 삭제함으로써 확보 가능한 공간을 출력합니다. RECLAIMABLE 항목은 사용 중이지 않은 이미지를 삭제함으로써 확보할 수 있는 공간을 의미합니다. 사용중이지 않은 컨테아너와 볼륨은 docker container prune, docker volume prune, docker image prune 명령어로 사용 중이지 않은 댕글링(dangling) 이미지를 삭제합니다.

 

3) CAdvisor

CAdvisor는 구글이만든 컨테이너 모니터링 도구로, 컨테이너로서 간단히 설치할 수 있고 컨테이너별 실시간 자원 사용량 및 도커 모니터링 정보등을 시각화해서 보여줍니다. CAdvisor는 오픈소스로서 깃허브에서 소스코드로 사용할 수 있으며, 도커 허브에서 도커 이미지로도 배포되고 있습니다. Cadvisor에서는 생성된 모든 컨테이너의 자원 사용량을 확인할 수 있을 뿐만 아니라 도커 데몬의 정보, 상태, 호스트의 자원 사용량까지 한번에 확인할 수 있습니다.

한번 볼만한 정보는 CAdvisor 생성할 때 옵션으로 설정한 호스트 볼륨 공유 부분인데, CAdvisor는 이렇게 많은 정보를 어떻게 사용자에게 보여줄 수 있는지 생각해봅시다. 답은 도커 데몬의 정보를 가져올 수 있는 호스트의 모든 디렉터리를 CAdvisor 컨테이너에 볼륨으로 마운트했기 때문입니다. /var/run에는 도커를 로컬에서 제어하기 위한 유닉스 소켓이 있고,  /sys에는 도커 컨테이너를 위한 cgroup 정보가 저장돼 있으며, /var/lib/docker에는 도커의 컨테이너, 이미지 등이 파일로 존재합니다.

그러나 CAdvisor은 단일 호커 도스트만을 모니터링할 수 있다는 한계가 있습니다. 이를 위해 보통은 쿠버네티스나 스웜 모드 등과 같은 오케스트레이션 툴을 설치한 뒤에 프로메테우스 등을 이용해 여러 호스트의 데이터를 수집하는 것이 일반적입니다.