[Docker] 서버로서의 역할, Docker Daemon

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.

 

Docker

---

저번 포스팅까지는 도커 엔진을 사용하는 방법을 알아보았다. 구체적으로, 컨테이너, 이미지를 생성하고 관리하는 방법, 더 나아가 Dockerfile을 가지고 나만의 이미지를 생성하는 방법에 대해서도 학습했다. 이번 포스팅에서는 도커 자체를 다뤄볼 수 있는 도커 데몬에 대해서 알아보자. 도커 데몬에 대해 이해하고 도커 자체적으로 설정할 수 있는 여러가지 옵션을 활용하면 이미지와 컨테이너를 좀 더 쉽게 사용할 수 있게 될 것이다. 도커 데몬에 대해서 알아보기 전에 도커가 어떤 구성요소로 이루어져 있는지부터 이해해야 한다.

1. 도커의 구조

이제부터 '도커 엔진 = 도커'라고 간략히 부르도록 하자. 도커는 2가지의 요소로 구성되어 있는데, 한 가지는 클라이언트의 역할을 하는 도커 클라이언트, 서버의 역할을 하는 도커 데몬이 있다. 아니 도커가 무슨 웹서버도 아니고, 어떻게 도커 안에 클라이언트와 서버가 나뉘어져 있는 걸까?

 

일단, 우리는 도커를 사용하기 위해서 터미널에서 docker 라는 접두어를 사용한다. 그리고 이 명령어를 사용해서 컨테이너, 이미지를 생성하게 된다. 다시 말해, 도커를 사용하는 사용자인 클라이언트가 바로 이 docker 라는 접두어의 명령어가 되고, 이 명령어가 작성되어 있는 파일은 docker 라는 이름의 파일이다. 실제로 docker 명령어 파일이 어디있는지 아래 명령어를 통해 확인할 수 있다.

 

$ which docker

 

그러면 아마 MacOS의 경우 /usr/local/bin/docker 이거나 리눅스 계열의 OS일 경우, /bin/docker 가 표준출력으로 나올 것이다. 결국 이 docker 명령어 파일이 바로 도커를 구성하는 요소 중 하나인 도커 클라이언트가 된다.

 

그러면 이제 서버의 역할을 하는 도커 데몬에 대해 알아보자. 우선, 아래의 명령어를 통해 실행 중인 도커 프로세스에 대한 정보를 ps 명령어로 출력시켜보자.(ps 명령어에 대해 잘 모른다면 여기를 참고)

 

$ ps aux | grep -E "docker"

 

도커를 실행중인 프로세스를 출력

 

위 결과화면을 보면 docker를 실행하는 프로세스는 바로 /usr/bin 이라는 디렉토리의 dockerd 라는 파일이 실행하고 있음을 알 수가 있다. 즉, 이 dockerd 파일이 바로 서버의 역할을 하는 도커 데몬이 된다. 조금 더 자세하게, 도커는 외부에서 API 입력을 받아 도커의 기능을 수행하는데, 이 때 외부로부터 API 입력을 받으면 도커 프로세스(dockerd 파일이 실행)가 실행되어 서버로서 입력을 받을 준비가 된 상태가 된다. 이 '상태'를 바로 도커 데몬이라고 한다.

 

그리고 이쯤되면 눈치 챌 수도 있겠지만 도커 데몬을 설명하면서 언급한 '외부로부터의 API 입력'이 바로 도커 클라이언트가 된다. 이 때, 도커 클라이언트는 API를 '사람이 사용할 수 있도록' CLI(Command Line Interface) 형태로 제공하는 것이다. 그리고 그 CLI 명령어가 'docker' 라는 접두어로 시작하는 명령어이다. 결국, 도커의 구성요소를 그림으로 도식화하면 아래와 같다.

 

개발자, 도커 클라이언트, 도커 데몬 간의 소통 구조

 

위 그림에서 /var/run/docker.sock 이라는 유닉스 소켓이 뭔지 궁금할 수 있다. 자세한 건 아래에서 알아본다. 이 소켓은 도커 클라이언트가 도커 데몬의 API를 호출하기 위한 통신수단이라고 생각하면 된다. 위 그림의 순서 과정은 도커에 아무런 옵션 설정을 하지 않았을 때 일반적으로 도커 클라이언트가 도커 데몬을 제어하는 순서이다. 만약 도커 데몬에 여러가지 옵션을 추가하면 위 그림에서 또 다른 순서가 중간에 추가로 포함될 수 있다.

2. 도커 데몬 실행

그러면 이제 위에서 개념적으로 배운 도커 데몬을 직접 실행시켜보도록 하자. 우선 도커 데몬은 아래와 같이 service 명령어를 활용해 즉, 도커 서비스를 활용해서 시작 또는 정지시킬 수 있다. 여기서 도커 데몬을 시작한다라는 것은 곧 서버로서의 도커를 띄운다는 셈이다.(흔히 웹서버를 띄운다는 개념처럼!) 

 

$ service docker start 
$ service docker stop

 

하지만 위처럼 명령어를 사용해서 도커 데몬을 시작하는 것은 레드햇 계열의 운영체제(ex. CentOS)에서만이다. Mac에서는 Docker Desktop on Mac 아이콘을 클릭해 도커 데몬을 먼저 실행해주어야 하고, 우분투의 경우는 별다른 명령어를 입력해주지 않아도 자동으로 도커 데몬을 실행시켜준다. 물론 레드햇 계열의 운영체제에서도 위 명령어를 입력하지 않고도 우분투처럼 자동으로 도커 데몬을 실행시켜줄 수 있는데, 아래 명령어를 입력해주면 된다.

 

$ systemctl enable docker

 

위와 같이 service 명령어를 활용(도커 서비스를 활용)해서 도커 데몬을 실행시킬 수도 있지만, 위에서 배운 dockerd 명령어로도 도커 데몬을 실행시킬 수 있다.(바로 위에서 도커를 실행하는 프로세스는 dockerd 라는 파일을 통해서 실행된다고 배웠었다) 그러면 아래와 같이 service 명령어로 도커 데몬을 정지시킨 뒤 dockerd 명령어를 입력해서 도커 데몬을 실행시켜보자. 

 

$ service docker stop

 

간혹 위 명령어를 입력하더라도 도커 데몬이 정지하지 않아서 docker ps 와 같은 명령어를 입력해도 정상동작 할 수도 있다. 이 때는 docker.socket 이라는 파일이 여전히 도커 데몬을 실행시키고 있기 때문인데, 아래의 명령어로 docker.socket 이라는 것도 정지시켜주면 그 때는 정말 도커 데몬이 정지하여 docker ps 와 같은 명령어를 입력해도 에러 메세지가 뜨는 것을 볼 수가 있다.(이와 관련해서는 이 Stackoverflow에서 도움을 얻을 수 있었다)

 

$ systemctl stop docker.socket

 

그리고 이제 아래 명령어를 사용해서 직접 도커 데몬을 실행시키면  사진과 같은 표준출력이 쭉 뜬다.

 

$ dockerd

 

dockerd 명령어를 쳤을 때 발생하는 로그

위 사진의 로그 중 마지막 줄에 "API listen on /var/run/docker.sock" 이라는 것이 나타났다. 이는 곧 입력을 받을 수 있는 상태(listen)라는 메세지를 의미하고, 여기서의 입력은 바로 위에서 배웠던 사용자가 도커 클라이언트를 통한 즉, docker 명령어를 사용한 입력을 의미한다. 실제로 위 상태에서 터미널을 하나 더 켜서 docker 명령어를 사용하면 동작하는 것을 볼 수 있다.

 

그런데 위처럼 dockerd를 활용해서 도커 데몬을 실행시키는 장점은 무엇일까? 우선 디버깅이나 도커 자체의 트러블 슈팅이 쉬워진다. 우리가 흔히 하는 웹서버를 개발할 때도 웹서버를 포그라운드 잡으로 띄워놓은 터미널에서 실시간으로 에러 로그를 보고 손쉽게 디버깅할 수 있게 된다. 이것과 비슷하게 dockerd를 활용하면 도커 데몬의 실시간 로그를 계속 볼 수 있어 손쉬운 디버깅이 가능해진다.

3. 도커 데몬 설정

지금까지는 도커 클라이언트, 도커 데몬이 무엇인지 배워보면서 도커를 구성하는 요소를 배웠다. 그리고 도커 데몬을 직접 실행하는 방법도 배워보았다. 다음은 이제 도커 데몬을 좀 더 잘 활용할 수 있도록 도커 데몬에 부여할 수 있는 다양한 옵션에 대해서 배워보도록 하자.

 

이번 목차에서 배울 내용은 모두 dockerd 명령어를 활용해서 도커 데몬의 옵션을 설정한다. 하지만 도커 데몬 옵션을 설정하기 위해서는 보통 dockerd 명령어 보다는 도커 설정 파일을 수정한 뒤, 도커 데몬이 해당 설정 파일을 읽어 들여 변경된 도커 데몬 옵션을 반영하는 것이 일반적이다. 구체적으로, dockerd로 시작해 입력시킬 명령어들을 도커 설정 파일의 DOCKER_OPTS 라는 변수에 할당한 뒤 저장하면 된다. 여기에서는 도커 데몬 설정을 변경하고 바로 확인할 수 있도록 하기 위해 흔하지 않은(?) 방법인 dockerd 명령어를 직접적으로 사용해서 도커 데몬의 옵션에 대해 배워보도록 하자. 보안, 스토리지 드라이버와 같은 옵션도 있지만 이에 대해서는 해당 포스팅에서는 다루지 않으므로 원본 책을 참고하길 바란다. 여기서는 대표적인 옵션인 -H 옵션에 대해서만 배워보도록 하자.

3-1. 도커 데몬의 API를 사용할 수 있는 방법 추가하기, -H 옵션

-H 옵션을 도커 데몬의 API를 사용할 수 있는 방법을 추가해준다. 아무런 -H 옵션을 설정하지 않으면 기본적으로 도커 데몬을 실행하게 되면 도커 클라이언트를 위한 유닉스 소켓인 docker.sock을 사용한다. 위 목차에서 본 그림을 다시 갖고와 보자.

 

개발자, 도커 클라이언트, 도커 데몬 간의 소통 구조

 

위 그림에서 2번에 해당하는 부분이 바로 docker.sock인 유닉스 소켓이고 이것이 도커 클라이언트를 위해 도커 데몬을 사용할 수 있도록 해주는 역할을 한다. 기본 세팅이 이렇기 때문에 아래의 2개 명령어는 동일한 효과를 지닌다.

 

$ dockerd
$ dockerd -H unix:///var/run/docker.sock

 

위 명령어를 실행할 때는 반드시 도커 데몬이 정지된 상태에서 실행되어야 한다. 왜냐하면 이미 도커 데몬이 시작된 상태인데, 또 시작할 수는 없기 때문이다.

 

dockerd 명령어의 -H 옵션에는 IP 주소와 포트번호를 입력할 수가 있다. 이렇게 하면 원격 API인 Docker Remote API로 도커를 제어할 수 있게 된다. 즉, 로컬에 있는 도커 데몬이 아니더라도 다른 컴퓨터에 있는 도커 데몬을 제어할 수 있다는 것이다. 이 때 다른 컴퓨터의 도커 데몬을 제어할 때는 HTTP 요청으로 제어가 가능하다. 왜냐하면 도커 데몬이 RESTful API 형태를 띄고 있기 때문이다.

 

만약 다음과 같은 명령어로 도커 데몬을 실행하게 되면 호스트에 존재하는 모든 네트워크 인터페이스의 모든 IP 주소와 999번 포트를 바인딩하여 입력을 받게 된다. 즉, 다른 컴퓨터의 입장에서, 아래의 IP 주소 및 999번 포트를 통해 로컬(내 컴퓨터)의 도커 데몬을 원격으로 제어할 수 있게 된다.

 

$ dockerd -H tcp://0.0.0.0:999

 

그런데 만약 위와 같은 명령어 한 줄만 입력한다면, 로컬에서는 더이상 도커 클라이언트인 docker 접두어로 시작하는 명령어를 사용해서 로컬의 도커 데몬을 제어하지 못한다. 왜냐하면 바로 위에서 배운 docker.sock 이라는 유닉스 소켓파일을 -H 옵션에 추가해주지 않았기 때문이다. 그래서 일반적으로는 도커 클라이언트를 위한 유닉스 소켓과 Remote API를 위한 바인딩 주소를 동시에 아래처럼 설정한다. 아래처럼 설정하면 의미는 "도커 데몬은 docker.sock이라는 유닛스 소켓을 통한 입력 또는 0.0.0.0(호스트의 모든 네트워크 인퍼테이스의 모든 IP주소)의 999번 포트번호를 통한 입력을 받을 수 있는 대기상태(listen)에 있음!" 이라고 할 수 있다.

 

$ dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:999

 

그러면 다른 호스트에서 Remote API로 도커 데몬을 제어하는 구조를 그림으로 이해해보자. 일단, Remote API 나 도커 클라이언트나 둘 다 내부적으로 같은 API를 사용한다. 즉, 명령어의 생김새만 다를 뿐 내부적으로 구현되는 로직은 동일하다는 것이다. 만약 199.168.99.100 이라는 IP주소를 가진 컴퓨터에서 Z라는 개발자가 도커 데몬을 로컬에서 실행시켰다고 가정하자. 그리고 이 Z개발자는 dockerd -H 옵션을 주어 199.168.99.100이라는 IP 주소의 999번 포트번호를 개방하여 다른 원격 호스트에서 Remote API로 도커 데몬을 제어할 수 있도록 허용했다고 해보자. 이 때 동작하는 구조는 아래와 같다.

 

 

즉, 로컬 HOST에서 날린 docker version이라는 명령어는 원격 HOST에서 curl 명령어로 날린 HTTP 요청과 동일한 결과물을 내는 것이다. 위와 같은 구조를 사용해서 원격 호스트에서 도커 데몬을 제어할 수 있게 된다. Remote API 종류(위 그림에서 /version URL 처럼)는 도커 명령어 개수만큼 있으며 API에 따라서 사용 방법이 도커 클라이언트 명령어와 조금씩 다른 부분도 있다. 그래서 보통은 HTTP 도구로 직접(위 그림처럼) 요청하기 보다는 특졍 언어(ex. Python)로 바인딩된 라이브러리를 사용하는 것이 일반적이다.

 

또 다른 방법으로는 셸의 환경변수에 DOCKER_HOST 라는 변수 값에 IP 주소 및 포트번호를 할당함으로써 원격에 있는 도커를 제어할 수도 있다.  도커 데몬으로 접근할 원격 호스트(클라이언트)의 셸에서 아래처럼 환경 변수를 할당하면 도커 데몬을 원격으로 제어가 가능하다.

 

$ export DOCKER_HOST="tcp://199.168.99.100:999"
$ docker version

 

하지만 위처럼 Remote API를 이용해서 원격 호스트의 도커 데몬을 제어할 수 있는 경우는 보안이 설정되어 있지 않은 경우이다. 이렇게 아무 보안도 설정하지 않으면 누군가가 IP 주소와 포트번호만 알면 쉽게 원격 호스트의 도커 데몬을 제어할 수 있을 것이다. 그래서 도커에 대해서 보안을 설정해줄 수 있다. 서버(도커 데몬)측과 클라이언트(도커 클라이언트)측 에서의 보안 파일을 생성해 적용한다. 본 포스팅에서는 다루지 않지만 책에서는 보안을 설정할 수 있는 방법을 소개한다. 관심이 있다면 원본 책의 내용을 살펴보도록 하자.

4. 도커 데몬 모니터링

도커 데몬을 모니터링하는 이유는 뭘까? 많은 수의 도커 컨테이너 서버를 효율적으로 관리하기 위함일 수도 있고, 도커 컨테이너 기반으로 배포한 애플리케이션에 문제가 생겨서 그 원인을 찾기 위함일 수도 있다. 도커 데몬은 이러한 상황에 대비하기 위해 모니터링 기능을 제공한다. 우선 도커가 자체적으로 제공하는 모니터링이 있고, 도커 프로젝트에서 지원하는 다양한 오픈소스 대시보드도 존재한다. 우선 도커 자체적으로 제공하는 모니터링 기능부터 살펴보자.

4-1. 도커 데몬의 디버그 모드

도커 엔진에서 자체적으로 제공하는 도커 데몬을 모니터링하는 방법은 도커 데몬을 실행할 때 디버그 모드로 실행하는 것이다. 디버그 모드로 도커 데몬을 실행하게 되면 Remote API로 도커 데몬을 제어할 때 발생되는 입/출력 뿐만 아니라 로컬의 도커 클라이언트에서 오가는 명령어(docker 접두어로 시작하는 명령어)를 로그로 모두 출력한다. 디버그 모드로 실행하는 방법은 -D 옵션을 주어 아래처럼 실행해주면 된다.

 

$ dockerd -D

 

그러면 아래처럼 도커 데몬이 입력 대기 상태(listen)로 시작된 것을 알 수 있다.

 

dockerd -D 옵션을 주어 디버그 모드로 도커 데몬을 실행

 

위 표준출력의 마지막 줄을 보면 GET으로 RESTFul API를 날린 것을 볼 수 있는데, 이는 필자가 도커 데몬을 디버그 모드로 실행한 후, 다른 셸에서 docker ps 라는 컨테이너 목록을 출력하는 도커 클라이언트 명령어를 날렸기 때문이다. 여기서도 알 수 있듯이, docker ps라는 도커 클라이언트 명령어는 RESTFul API로 벼환하면 /v1.42/containers/json 이라는 URL로 HTTP 통신을 한 것을 알 수 있다.

 

참고로, 도커 데몬을 디버그 모드가 아닌 일반적인 즉, 서비스 모드로 구동했을 경우에는 위와 같은 로그를 실시간으로 확인할 수 없다. 하지만 서비스 모드일 때도 로그를 확인할 수 있는데, upstart 기반의 리눅스에서는 /var/log/upstart/docker.log 파일에서, systemd를 기반으로 하는 우분투 16.04 이상의 리눅스에서는 jorunalctl -u docker 명령어로 확인할 수 있다.(Q. upstart linux vs systemd linux?https://fossbytes.com/systemd-vs-sys-v-vs-upstart/)

 

하지만 이런 도커 데몬의 디버그 모드는 몇가지 단점이 존재한다. 우선 로그에 사용자에게 꼭 필요하지 않는 정보도 출력이된다. 또한 위 결과화면 처럼 도커 데몬을 포그라운드 잡 상태로 무조건 돌려야 하기 때문에 셸 하나를 무조건 차지하게 된다.

4-2. 도커 데몬의 정보를 출력해, events, stats, system df 명령어

위에서 알아본 도커 데몬의 디버그 모드의 단점들을 보완하는 명령어들이 존재한다. 우선 도커 데몬을 서비스 모드로 구동해보자. 위에서 시작시켜놓은 도커 데몬 디버그 모드를 중지해주고 아래 명령어로 도커 데몬을 서비스 모드로 시작시켜보자.

 

$ service docker start

 

이제 명령어 종류 하나씩 알아보자. 먼저 events 명령어이다. events 명령어는 도커 데몬에 어떤 일이 일어나고 있는지 실시간으로 스트림 로그를 보여준다. 아래 2개의 명령어 중 하나를 입력해보자. 입력하고 아무런 출력이 발생하고 있지 않다면 정상적인 상태이다. 

 

events 명령어를 사용해 도커 데몬의 로그를 실시간으로 관찰

 

이제 다른 셸로 가서 Ubuntu14.04 이미지를 Pull 해보자. 현재 서버용 리눅스를 사용하기 때문에 불가피하게 필자는 tmux라는 터미널 멀티플렉서를 사용했다.

 

 

그런 다음 events 명령어를 입력했던 셸로 돌아가서 실시간 로그를 살펴보자.

 

 

보면 방금 다른 셸에서 Ubuntu:14.04 이미지를 Pull한 로그가 남아있는 것을 볼 수가 있다. 이렇게 events 명령어는 도커 데몬에서 실행되는 명령어의 결과를 로그로 출력한다. 하지만 도커 클라이언트의 모든 명령어가 출력되는 것은 아니며, attach, commit, copy, create 과 같은 컨테이너 관련 명령어와 delete, import, load, pull, push 와 같은 이미지 관련 명령어, 볼륨, 네트워크, 플러그인 등과 같은 명령어의 수행결과만 출력된다.

 

또한 events 명령어는 --filter 옵션을 사용해서 원하는 로그 정보만 출력할 수 있도록 할 수 있다. 이전에 이미지를 배우면서 --filter 옵션을 배웠던 적이 있다. 형식은 아래와 같이 사용되며 type이라는 키워드에 들어갈 인자로는 container, image, volume, network, plugin, daemon으로 나뉜다. 아래는 events 명령어에 --filter 옵션을 사용한 예시이다.

 

$ docker events --filter 'type=image'

 

다음은 stats 명령어이다. stats 명령어는 실행 중인 모든 컨테이너의 자원 사용량을 실시간으로 출력해준다. 특히 실행중인 모든 컨테이너의 CPU, 메모리 제한 및 사용량, 네트워크 입출력, 블록 입출력(=하드웨어 입출력) 정보를 출력해준다. 만약 실시간이 아닌 한 번만 일시적으로 출력시키고 싶다면 --no-stream 옵션을 추가하면 된다.

 

$ docker stats
$ docker stats --no-stream

 

참고로 Remote API를 사용해서 stats 명령어를 사용하게 되면 도커 클라이언트 명령어를 이용해 stats를 쓰는 것보다 더 자세한 정보를 반환한다고 한다.

 

마지막으로 system df 명령어에 대해 알아보자. system df 명령어는 도커에서 사용하고 있는 이미지, 컨테이너, 볼륨의  총 개수 및 사용중인 개수, 크기, 삭제함으로써 확보 가능한 공간을 출력한다. 삭제함으로써 확보 가능한 공간은 RECLAIMABLE 이라는 항목에 표시된다.

 

$ docker system df

4-3. 단일 도커 호스트에서 모니터링 해보기, CAdvisor

다음으로는 구글이 만든 컨테이너 모니터링 도구인 CAdvisor를 한번 사용해보도록 하자. CAdvisor는 구글이 만든 오픈소스로서, CAdvisor 애플리케이션 자체를 컨테이너로 만들어 놓았기 때문에 컨테이너로서 간단히 설치가 가능하다. 게다가 Docker Hub에도 이미지 형태로 올라가 있기도 하다. 그리고 CAdvisor는 컨테이너 별 실시간 리소스 사용량 및 도커 모니터링 정보 등을 시각화해서 보여준다. CAdvisor의 오픈 깃헙 소스코드는 여기를 참조하면 된다.

 

그러면 이제 CAdvisor를 사용해보자. 리눅스에서 설치를 해보려 했지만, 필자가 설치한 리눅스는 서버용 리눅스라서 GUI 화면이 제공되지 않는다. CAdvisor를 설치하고 웹 브라우저를 통해 접속을 해보려고 하기 때문에 필자 노트북(맥북)과 리눅스 CentOS가 깔려있는 VirtualBox(VM)과 포트 포워딩을 하고, 이 VM안에서의 호스트와 VM 안에서 실행시킨 CAdvisor 컨테이너와 포트 포워딩 즉, 총 2번의 포트 포워딩을 하려고 한다. 노트북과 VM 간의 포트 포워딩을 하는 방법은 여기를 참고해보자.

 

(참고로 맥북 자체에서 즉, Docker Desktop on Mac에서 CAdvisor 컨테이너를 생성하려고 했지만 생성 시 바로 컨테이너가 종료(Exit)되버리는 문제가 자꾸 발생해서 이 방법을 사용하지는 않았다. 참고로 깃헙 이슈에도 이와 관련된 문제 제기가 되었었는데 해결된 외국인 분들..도 계시니 혹시라도 디버깅 해보려고 한다면 해당 글을 참고해보자)

 

맥북과 VM 간의 포트포워딩을 완료(맥북과 VM 간에도 8080 포트번호를 개방함)했다고 가정하고, VM안의 리눅스에서 아래 명령어를 사용해서 CAdvisor 컨테이너를 생성해보자. 생성 후, docker ps 명령어를 쳤을 때 잘 동작 중이면 성공한 것이다.

 

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

 

그리고 이제 맥북에서 http://localhost:8080 URL을 통해 접근하면 아래와 같이 웹브라우저 화면에 CAdvisor 화면이 나타난다.

 

CAdvisor 화면

 

위 화면에서 [/docker] 를 눌러보면 도커 데몬의 정보, 컨테이너의 목록을 보여주는 페이지로 이동하고 이동한 페이지 이후에 나타나는 아래 화면에서 [Subcontainers]에 해당하는 목록은 현재 VM안의 도커 데몬에서 실행중인 컨테이너들을 의미한다. 아래에서는 2개의 컨테이너가 실행중인데, 이는 CAdvisor를 설치하면서 생성된 하나의 컨테이너를 의미하고 나머지 하나는 필자가 따로 실습하면서 생성한 Nginx 컨테이너 1개를 의미한다.

 

Subcontainers는 실행중인 컨테이너 목록을 의미

 

현재 필자의 VM안의 도커 데몬에서 실행중인 컨테이너들

 

위 정보 이외에 CPU 사용량, 메모리 사용량, 네트워크, 파일 시스템 관련하여 모니터링 정보를 제공해준다. 이런 유용한 CAdvisor 모니터링 도구도 한계점이 있는데, 바로 하나의 호스트만 모니터링이 가능하다. 예를 들어, 만약 추가 VM 머신을 할당받아서 그 VM 머신에서도 도커 데몬을 실행시키고 있다면, 하나의 CAdvisor로 추가한 VM의 도커 데몬을 모니터링할 수는 없다. 이런 한계점 때문에 여러 호스트의 도커 데몬을 모두 모니터링할 수 있는 Grafana 나 Prometheus 등과 같은 도구를 사용한다.

5. Python Remote API 라이브러리인 docker-py를 이용해 도커 사용하기

이번 목차에서는 [목차 3-1]에서 잠시 언급한 원격 호스트의 도커 데몬을 이용하기 위해 Remote API를 사용하는데, 이 때 특정 언어로 바인딩된 라이브러리에 대해서 살펴보자. 여기에서는 Python으로 바인딩된 라이브러리에 대해 알아본다.

 

위에서 Remote API를 사용하는 목적으로 원격 호스트의 도커 데몬을 이용하기 위함이라고 했다. 하지만 꼭 원격 호스트의 도커 데몬 이용이 목적이 아니더라도 예를 들어, 컨테이너 애플리케이션이 수행해야 할 작업이 많거나 애플리케이션 초기화 등 복잡한 과정이 포함되어 있다면 특정 언어로 바인딩된 Remote API 라이브러리를 사용하는 것이 유용하기도 하다.  바인딩 지원이 되는 언어로는 Go, C#, C++, Python, Dart, PHP, Java 등이 있다. 

 

Python으로 Remote API를 이용하려면 일단 Python 버전이 3.0 이상이어야 한다. Python Remote API 라이브러리의 이름은 docker-py 이다. docker-py는 pip을 이용해 설치할 수 있다. 우선 리눅스에 먼저 pip 설치 후, docker-py 라이브러리를 설치해보자.

 

$ yum install epel-release -y
$ yum install python3-pip -y
$ pip3 install docker

 

이제 docker-py가 정상적으로 설치되었다. 그러면 아래처럼 리눅스에서 python3 인터프리터를 열고 아래 코드를 입력시켜서 도커 엔진의 정보를 출력시킬 수 있다.

 

$ python3
>>> import docker
>>> client = docker.DockerClient(base_url="unix://var/run/docker.sock")
>>> client.info()

 

그럼 간단한 예시로, docker-py를 이용해서 Nginx 컨테이너를 Detached 상태로 실행하는데, 호스트의 80/tcp 포트를 컨테이너의 80번 포트에 바인딩하는 코드를 작성해보자. 아래와 같은 main.py 파일을 하나 작성하고 python3 main.py 명령어를 입력해보자.

 

# docker-py.py
import docker

client = docker.DockerClient(base_url="unix://var/run/docker.sock")
container = client.containers.run('nginx', detach=True, ports={'80/tcp': 80})

print("Created container info:", container.name, container.id)

 

필자는 아래와 같이 결과가 나왔다. docker-py를 사용하는 다른 방법들을 더 알고 싶다면 여기 문서도 참고해보도록 하자.

 

main.py 파일 실행의 결과

---

이렇게 까지 해서 도커 데몬에 대한 기본적인 내용에 대해서 배워보았다. 다음 포스팅에는 도커 스웜에 대해 알아보도록 하자.