[도커/쿠버네티스] 도커 데몬

도커의 구조

 도커 명령어는 /usr/bin/docker 에 위치한 파일을 통해 사용되고 있다. 하지만, 도커 엔진의 프로세스는 /usr/bin/dockerd 파일로 실행되고 있다. 이렇게 되는 이유는 docker 명령어가 실제 도커 엔진이 아닌 클라이언트로서의 도커이기 때문이다. 

 

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

 

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

 

도커 데몬 실행

 도커 데몬은 일반적으로 아래와 같은 명령어로 시작, 정지할 수 있다. 우분투에서는 도커가 설치되면 자동으로 서비스로 등록되므로 호스트가 재시작되더라도 자동으로 실행된다.

$ service docker start

$ service docker stop

 레드햇 계열의 운영체제는 도커를 설치해도 자동으로 실행되도록 설정되지는 않습니다. 도커를 자동으로 실행하도록 설정하려면 아래의 명령어로 docker 서비스를 활성화합니다. 자동으로 실행하도록 설정하려면 docker 서비스를 활성화한다.

$ systemctl enable docker

 

 도커 서비스는 dockerd 로 도커 데몬을 실행한다. 그러나 서비스를 사용하지 않고 직접 도커 데몬을 실행할 수 있다. 도커 서비스를 정지한 뒤 명령어로 도커를 직접 실행해본다. (아래 명령어)

$ service docker stop
$ dockerd

 

 dockerd를 입력하면 도커 데몬이 실행된다. Ctrl+C입력하면 종료 가능하다.

 

 

 도커는 특정 스토리지 벡엔드 기술을 사용하여 도커 컨테이너와 이미지를 저장하고 관리합니다.

 

 일부 OS는 도커를 설치할 때 기본적으로 사용되도록 설정된 스토리지 드라이버가 있는데, 우분투와 같은 데비안 계열의 OS는 overlay2를, 구버전의 CentOS와 같은 OS는 devicemapper를 사용합니다.

• 이는 docker info 명령어로 확인할 수 있습니다. 

 

도커 모니터링

 도커 데몬을 모니터링하는 데에는 여러 가지 이유가 있다. 많은 수의 도커 서버를 효율적으로 관리하기 위해서일 수도 있고, 도커로 컨테이너 애플리케이션을 개발하다가 문제가 생겼을 때 그 원인을 찾아내기 위해서일 수도 있으며 도커를 PaaS로써 제공하기 위해 실시간으로 도커 데몬의 상태를 체크해야할 수도 있다.

 

 다양한 목적에 부합하는 모니터링 방법은 매우 많다. 그 중에는 도커 엔진 자체가 지원하는 모니터링 기능도 있고, 도커 프로젝트에서 지원하는 상용솔루션 및 각종 오픈소스 대시보드도 있다. 아래에서는 하나의 컨테이너뿐만 아니라 도커 데몬 자체를 모니터링하는 방법을 알아보겠다. 

 

도커 데몬 디버그 모드

 도커 데몬에서 어떤 일이 일어나고 있는지 가장 확실하고 정확하게, 그리고 자세히 알아내는 방법은 도커 데몬을 디버그 옵션으로 실행하는 것이다. 이렇게 하면 Remote API의 입출력뿐만 아니라 로컬 도커 클라이언트에서 오가는 모든 명령어를 로그로 출력한다. 디버그 모드는 도커 데몬을 실행할 때 -D 옵션을 추가해서 사용할 수도 있다.

 

 

 디버그 모드는 도커 데몬에 문제가 생겼을 때 무엇이 잘못됐는지 확인하는 가장 좋은 수단이다. 그러나 로그에는 원하지 않는 정보까지 너무 많이 출력되며, 호스트에 있는 파일을 읽거나 도커 데몬을 포그라운드 상태로 실행해야 한다는 단점이 있으므로 이 방법만으로는 뭔가 조금 부족해보인다. 도커 명령어로 도커 데몬을 모니터링하는 방법에 대해 알아본다.

 

events, stats, system df 명령어

events 명령어

도커를 사용하는 가장 쉬운 방법은 도커 자체가 제공하는 기능을 사용하는 것이며, events 명령어도 도커가 기본으로 제공하는 명령어이다. events 명령어는 도커 데몬에 어떤 일이 일어나고 있는지를 실시간 스트림 로그로 보여준다. 다음 명령어 중 하나를 입력하면 도커 데몬이 수행한 명령어의 결과를 실시간으로 볼 수 있다.

$ docker events
$ docker system events

 

 위 명령어를 입력한 직후에는 어떠한 이벤트도 도커 데몬에 발생하지 않았으므로 아무것도 출력되지 않는다. 새로운 터미널을 연 뒤에 ubuntu:14.04 이미지를 pull 해본다.

 이미지의 pull이 완료되면 docker events 명령어를 실행했던 터미널에서 다음과 같은 명령어가 출력되는 것을 확인할 수 있다. 

 

stats 명령어

 docker stats 명령어는 실행 중인 모든 컨테이너의 자원 사용량을 스트림으로 출력한다. stats 명령어도 다음과 같이 간단히 사용할 수 있다. 

stats 명령어는 실행 중인 모든 컨테이너의 CPU, 메모리 제한 및 사용량, 네트워크 입출력(I/O), 블록 입출력(하드웨어 입출력) 정보를 출력한다. 기본적으로 스트림 형태로 출력되며, 스트림이 아닌 한 번만 출력하는 방식으로 사용하고 싶다면 --no-stream 옵션을 추가한다.

$ docker stats --no-stream

 

system df 명령어

system df 명령어는 도커에서 사용하는 이미지, 컨테이너, 로컬 볼륨의 총 개수 및 사용 중인 개수, 크기, 삭제함으로써 확보 가능한 공간을 출력한다.

 지금 현재 내 컴퓨터에서의 총 이미지의 개수는 10개이고, 사용 중인 이미지는 5개이고 이미지가 차지하는 공간은 2.49GB인 것을 알 수 있다. RECLAIMABLE 항목은 사용 중이지 않은 이미지를 삭제함으로써 확보할 수 있는 공간을 의미한다.

 

 사용 중이지 않은 컨테이너와 볼륨은 각각 아래의 명령어로 한꺼번에 삭제할 수 있다. docker image prune 를 사용하면 사용 중이지 않은 댕글링(dangling) 이미지를 삭제한다.

// 사용 중이지 않는 컨테이너 삭제
$ docker container prune

// 사용 중이지 않는 볼륨 삭제
$ docker volume prune

// 사용 중이지 않는 이미지 삭제
$ docker image prune

 

CAdvisor

CAdvisor는 구글이 만든 컨테이너 모니터링 도구로, 컨테이너로서 간단히 설치할 수 있는 컨테이너별 실시간 자원 사용량 및 도커 모니터링 정보 등을 시각화해서 보여준다. CAdvisor는 오픈소스로서 깃허브에서 소스코드로 사용할 수 있으며, 도커 허브에서 도커 이미지로도 배포되고 있다.

 

CAdvisor를 사용하기 위해 다음 명령어를 입력한다. CAdvisor는 컨테이너 에이전트의 형태로 도커 모니터링에 필요한 자료를 수집한다.

$ docker run \
--volume=/:/rootfs:ro \
--volume=/var/run:/var/run:ro \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker/:/var/lib/docker:ro \
--volume=/dev/disk/:/dev/disk:ro \
--publish=8080:8080 \
--detach=true \
--name=cadvisor \
google/cadvisor:latest

 

 실행한 Public IPv4에 8080번 포트로 접속하면, 아래와 같은 화면이 나온다. 이렇게 화면이 정상적으로 나오면 CAdvisor 컨테이너가 정상적으로 생성된 것이다.

 

 CAdvisor 에서는 생성된 모든 컨테이너의 자원 사용량을 확인할 수 있을 뿐만 아니라 도커 데몬의 정보, 상태, 호스트의 자원 사용량까지 한 번에 확인할 수 있다. IP 주소와 8080번 포트로 접속했을 때 확인할 수 있는 페이지는 호스트의 프로세스, 자원 사용량 등을 보여준다. 

 

 [/SubContainers]의 [/docker]를 클릭하면 도커 데몬의 정보, 컨테이너의 목록을 보여주는 페이지로 이동한다. [SubContainers] 항목의 컨테이너 이름을 컨테이너의 자원 사용률도 실시간으로 확인할 수 있다.

 

 CAdvisor의 대시보드는 60초간의 모니터링 정보만 보여주지만 InfluxDB나 Prometheus 등과 같이 사용하면 장기간의 모니터링 정보를 수집하고 분석할 수 있다.

 여기서 짚고 넘어가야할 부분이 있다.

 

어떻게 CAdvisor는 이렇게 많은 정보를 사용자에게 보여줄 수 있는 것인가??

 

답은 도커 데몬의 정보를 가져올 수 있는 호스트의 모든 디렉토리를 CAdvisor 컨테이너에 볼륨으로서 마운트했기 때문이다. /var/run 에는 도커를 로컬에서 제어하기 위한 유닉스 소켓이 있고, /sys에는 도커 컨테이너를 위한 cgroup 정보가 저장돼 있으며 /var/lib/docker에는 도커의 컨테이너, 이미지 등이 파일로 존재한다.

 

 그러나 CAdvisor는 단일 도커 호스트만을 모니터링할 수 있다는 한계가 있다. 여러 개의 호스트로 도커를 사용할 수 있으며, 이를 기반으로 PaaS(Platform as a Service) 같은 도커 클러스터를 구축했다면 단일 CAdvisor 컨테이너는 용도에 맞지 않을 수 있다. 이를 위해서 보통은 Kubernetes나 Docker Swarm 모드 등과 같은 오케스트레이션 툴(Orchestration)을 설치한 뒤에 프로메테우스(Prometheus), InfluxDB 등을 이용해 여러 호스트의 데이터를 수집하는 것이 일반적이다.

• 컨테이너 배포 관리는 흔히 컨테이너 오케스트레이션 (Container Orchestration) 이라고 불립니다.
• 컨테이너 오케스트레이션의 목적은 여러 컨테이너의 배포 프로세스를 최적화 하는데 있으며, 이것은 컨테이너와 호스트의 수가 증가함에 따라 점점 더 가치가 있게 됩니다. 이러한 유형의 자동화를 오케스트레이션이라고 합니다.