Docker study - 도커 엔진 (3)

목차

 

 

도커 이미지

도커는 기본적으로 도커 허브(Docker Hub)라는 중앙 이미지 저장소에서 이미지를 내려받습니다. 단, 도커 허브는 공식 라벨이 없는 이미지를 사용할 경우 사용법을 찾을 수 없거나 제대로 동작하지 않을 수 있습니다. 또한 비공개로 저장소를 사용하려면 비공개 저장소에 따라 요금을 지불해야 합니다. 도커 허브의 이미지를 찾으려면 search 명령어로 찾아볼 수 있습니다.

 

 

도커 이미지 생성

먼저 이미지를 만들기 위한 컨테이너를 생성한 후 commit 명령어를 통해 컨테이너를 이미지로 만듭니다.

docker run -i -t --name container_test ubuntu:14.04
docker commit [option] container [repository[:tag]]

이미지 생성 옵션

• -a : author 를 뜻하며 이미지의 작성자를 나타내는 메타데이터를 입력합니다.
• -m : 커밋 메세지를 뜻하며 이미지에 포함될 부가 설명을 입력합니다.

 

 

이미지 구조 이해

💡 inspect 명령어는 컨테이너 뿐 아니라 이미지, 네트워크, 볼륨등 모든 도커 단위의 정보를 얻을 때 사용할 수 있습니다. 이름이 중복될 경우 컨테이너에 대해 먼저 수행되므로 --type을 명시하는게 좋습니다.

 

여기서 inspect 명령어로 볼 때 가장 주의 깊게 봐야할 부분은 Layers 항목입니다.

이미지에서 3개가 있다고 가정할 때, ubuntu:14.04 이미지를 토대로 변경사항을 저장한게 commit_test:first

첫 번째 변경사항 이미지였던 commoit_testfirst 에서 다른 추가 변경사항을 저장한게 commit_tesst:second

이미지 입니다.

이 이미지들의 크기를 inspect 로 조회하면 각각 188MB라고 출력되더라도 실제 크기는 188MB + first 파일 크기 + second 파일 크기가 됩니다.

• docker history : 해당 레이어 구조를 확인할 수 있습니다
• docker rmi : 해당 이미지를 삭제합니다. 하지만 이미지를 사용중인 컨테이너가 존재할 경우 삭제할 수 없습니다. 강제로 삭제할 경우 -f 옵션으로 할 수 있으나 레이어 파일을 삭제하는게 아니라 이미지 이름만 지웁니다. 그러므로 먼저 컨테이너를 지우고 이미지를 삭제합니다.

 

 

이미지 추출

도커 이미지를 별도로 저장하거나 옮기는 등 이미지를 단일 바이너리 파일로 저장해야할 때 docker save 명령어로 컨테이너의 커맨드 , 이미지 이름과 태그 등 모든 메타데이터를 포함해 하나의 파일로 추출할 수 있습니다.

• -o : 옵션으로 추출될 파일명을 입력합니다
• load -i : 추출된 이미지를 load 명령어로 도커에 다시 로드할 수 있습니다.
• export : 컨테이너의 파일시스템을 tar 파일로 추출하며 컨테이너 및 이미지에 대한 설정 정보를 저장하지 않습니다.
• import : 이미지를 저장하며 컨테이너에서 변경 사항과 모드, 커맨드와 같은 정보도 포함됩니다.

 

 

이미지 배포

1. 가장 쉬운 방법은 도커 허브에 이미지 저장소를 사용하는 것 입니다. 하지만 공개적으로 올려도 되는 이미지만 올리거나, 비공개 저장소를 사용해야 하나 사용수 제한이 있고 추가하려면 유료로 사용할 수 있습니다.
2. 두 번째는 도커 사설 레지스트리(Docker Private Registry)를 사용하는 것으로서 사용자가 직접 이미지 저장소를 만들 수 있습니다. 다만 직접 서버를 구성하고 관리해야 하므로 도커 허브보다 까다로울 수 있습니다.

docker push alicek107/my-image-name:0.0 # push 명령어로 배포할 수 있다

 

 

저장소 웹훅 추가 (Webhook)

저장소에 이미지가 Push 됐을 때 특정 URL로 http요청을 전송하도록 설정할 수 있는데, 이 기능을 웹훅 이라고 합니다. 저장소에 추가된 새로운 이미지를 각 서버에 배포하는 애플리케이션을 작성할 때 유용하게 활용할 수 있습니다.

 

 

도커 사설 레지스트리

개인 서버에 이미지를 저장할 수 있는 저장소로 만들 수 있습니다. 이 레지스트리는 컨테이너로서 구현되므로 이를 만들기 위한 이미지가 존재하며 도커에서 공식적으로 제공하기 때문에 손쉽게 사용할 수 있습니다.

레지스트리 컨테이너는 기본적으로 5000번 포트를 사용하므로 -p 옵션으로 컨테이너의 5000번 포트를 호스트의 5000번 포트와 연결했으며, 이 포트로 레지스트리 컨테이너의 Http API를 사용할 수 있습니다.

 

💡 레지스트리 컨테이너는 생성됨과 동시에 컨테이너 내부 디렉터리에 마운트되는 도커 볼륨을 생성합니다. 컨테이너를 삭제할 때 볼륨도 함께 삭제하려면 rm 명령어에 --volumes 옵션을 추가합니다

 

도커 데몬은 기본적으로 HTTPS를 사용하지 않은 접근을 허용하지 않습니다.

1. 인증서를 별도로 적용해서 설정하거나
2. --insecure-registry 옵션을 통해 해결할 수 있습니다

 

• 사설 레지스트리 RESTful API : 도커 엔진은 명령행 도구로 docker ps 와 같은 명령어를 사용할 수 있지만, 레지스트리 컨테이너는 별도의 인터페이스를 제공하지 않아 제어하려면 따로 RESTful API, 혹은 미리 설정한 레지스트리 제어 CLI등을 사용합니다.
• 사설 레지스트리 옵션 설정 : 컨테이너 내부의 환경변수를 써서 레지스트리 서비스를 설정합니다. 보통 yml 파일을 통해 환경변수를 설정합니다. -v 옵션을 통해 레지스트리 컨테이너에 존재하는 config.yml파일을 따로 작성한 설정파일로 교체합니다.

 

 

도커 파일

도커 파일 이미지 생성

도커 파일을 통해 기록하고 수행할 수 있는 빌드(build) 명령어를 제공하며 이미지를 생성하기 위해 컨테이너에 설치해야 하는 패키지, 추가해야 하는 소스코드, 실행할 명령어와 셸 스크립트 등을 하나의 파일에 기록해 두면 도커는 이 파일을 읽어 컨테이너에서 작업을 수행한 뒤 이미지로 만들어냅니다. 이 도커파일을 통해 애플리케이션의 빌드 및 배포를 자동화 할 수 있습니다.

 

 

도커 파일 작성

도커 파일은 한 줄이 하나의 명령어가 되고, 명령어(Instruction)를 명시한 뒤 옵션을 추가하는 방식입니다. 보통 대문자로 표기합니다.

• FROM : 생성할 이미지의 베이스가 될 이미지를 뜻하며 반드시 입력해야 합니다.
• MAINTAINER : 이미지를 생성한 개발자의 정보를 나타냅니다. 도커 1.13 버전부터 LABEL 로 대체
• LABEL : 이미지에 메타데이터를 추가합니다. 키:값의 형태로 저장되며 여러개를 저장할 수 있습니다 나중에 정보를 확인하려면 inpect 명령어로 이미지의 정보를 확인할 수 있습니다.
• RUN : 이미지를 만들기 위해 컨테이너 내부에서 사용할 명령어를 입력합니다. 단 추가 질의가 필요한 경우 에러로 간주하므로 미리 설정해야 합니다.
• ADD : 파일을 이미지에 추가합니다. 추가할 파일은 Dockerfile이 위치한 디렉터리인 컨텍스트에서 가져옵니다.
• WORKDIR : 명령어를 실행할 디렉터리를 나타냅니다. 배시 셸에서 cd 명령어를 입력하는 것과 같은 기능을 합니다.
• EXPOSE : Dockerfile의 빌드로 생성된 이미지에서 노출할 포트를 설정합니다. 다만 반드시 이 포트가 바인딩되는 것은 아니며 단지 컨테이너의 80번 포트를 지정하는 것 입니다.
• CMD : 컨테이너가 시작될 때 마다 실행할 명령어들을 설정하며, Dockerfile에서 한번만 사용할 수 있습니다. CMD를 명시함으로써 이미지에 apachectl -DFOREGROUND 라는 커맨드를 내장하면 컨테이너를 생성할 때 별도의 커맨드가 없어도 이미지에 내장된 커맨드가 적용되어 컨테이너가 시작될 때 자동으로 아파치 웹 서버가 실행될 것이며 아파치 웹 서버는 하나의 터미널을 차지하는 포그라운드 모드로 실행되기 때문에 -d옵션을 사용해 detached 모드로 컨테이너를 생성해야 합니다. CMD의 입력은 JSON 배열 형태인 [”파일”, “명령인자”, “명령인자”,… ] 형태로도 사용할 수 있습니다.

 

 

도커 파일 빌드

예제로 이미지부터 빌드까지 진행해 보겠습니다.

docker build -t mybuild:0.0 ./ # build 옵션(-t) 옵션값(mybuild) 도커파일저장경로(./)
# -t 옵션은 생성될 이미지의 이름을 설정하는 것으로 따로 설정하지 않으면 16진수로 저장되니 사용하자

docker run -d -P --name myserver mybuild:0.0
# -P 옵션은 이미지에 설정된 EXPOSE의 모든 포트를 호스트에 연결하도록 설정합니다. ps, port 로 확인

 

 

빌드 컨텍스트 (Conext)

이미지를 생성하는 데 필요한 각종 파일, 소스코드, 메타데이터 등을 담고 있는 디렉토리를 의미하며 Dockerfile이 위치한 경로의 디렉토리가 빌드 컨텍스트가 됩니다. 빌드 컨텍스트는 Dockerfile에서 빌드될 이미지에 파일을 추가할 때 사용되며 추가방법은 앞선 ADD 옵션 외에도 COPY가 있습니다.

💡 컨텍스트는 build 명령어의 맨 마지막 지정 위치에 있는 모든 파일을 포함하므로 Git의 .gitignore 와 유사한 .dockerignore 로 컨텍스트에서 제외할 수 있습니다. 해당 파일은 컨텍스트의 최상위 경로(Dockerfile 과 동일한 위치)에 위치해야 합니다.

 

 

Dockerfile을 이용한 컨테이너 생성과 커밋

build 명령어는 Dockerfile에 기록된 대로 컨테이너를 실행한 뒤 완성된 이미지를 만들어 냅니다. 이 때 각 절차는 Dockerfile에 기록된 명령어에 해당하며 ADD,RUN등의 명령어가 실행될 때마다 새로운 컨테이너가 하나씩 생성되며 이를 이미지로 커밋합니다.

 

캐시를 이용한 이미지 빌드

한번 이미지 빌드를 마치고 난 뒤 다시 같은빌드를 진행하면 이전 이미지 빌드의 캐시를 사용합니다. 이전에 사용한 이미지 레이어를 활용해서 생성합니다.

하지만 캐시 기능이 필요로 하지 않을 때는 build 명령어에 --no-cache 옵션을 통해 캐시를 사용하지 않고 빌드를 진행할 수 있습니다. 또한 캐시로 사용할 이미지를 직접 지정할 수도 있는데 --cache-from 이미지명 으로 캐시로 사용할 수 있습니다.

 

멀티 스테이지를 이용한 Dockerfile 빌드

일반적으로 애플리케이션을 빌드하기 위해선 많은 의존성 패키지와 라이브러리가 필요합니다. 하지만 도커 17.05버전 이상을 사용한다면 이미지의 크기를 줄이기 위해 멀티 스테이지를 사용할 수 있습니다.

이렇게 멀티 스테이지 빌드는 반드시 필요한 실행 파일만 최종 이미지 결과물에 포함시킴으로써 이미지 크기를 줄일 때 유용하게 사용할 수 있습니다.

 

기타 Dockerfile 명령어

• ENV : Dockerfile에서 사용할 환경변수를 설정합니다. ${ENV} 혹은 $ENV 형태로 사용합니다.
• VOLUME : 빌드된 이미지로 컨테이너를 생성했을 때 호스트와 공유할 컨테이너 내부의 디렉토리를 설정합니다.
• ARG : build 명령어를 실행할 때 추가로 입력을 받아 Dockerfile 내에서 사용될 변수의 값을 설정합니다.
• USER : 컨테이너 내에서 사용될 사용자의 이름이나 ID를 설정하면 그 아래의 명령어는 해당 사용자의 권한으로 실행됩니다.
• ONBUILD : 빌드된 이미지를 기반으로 하는 다른 이미지가 Dockerfile로 생성될 떄 실행할 명령어를 추가합니다. 이를 활용하는 좋은 방법 중 하나는 이미지가 빌드하거나 활용할 소스코드를 ONBUILD ADD 로 추가해 좀 더 깔끔하게 Dockerfile을 사용하는 것입니다.
• STOPSIGNAL : 컨테이너가 정지될 때 사용될 시스템 콜의 종류를 지정합니다. 아무것도 설정하지 않으면 기본적으로 SIGTERM으로 설정되지만 Dockerfile에 STOPSIGNAL을 정의해 컨테이너가 종료되는 데 사용될 신호를 선택할 수 있습니다.
• HEALTHCHECK : 이미지로부터 생성된 컨테이너에서 동작하는 애플리케이션의 상태를 체크하도록 설정하며 컨테이너 내부에서 동작중인 애플리케이션의 프로세스가 종료되지는 않으나 애플리케이션이 동작하고 있지 않은 상태를 방지하기 위해 사용될 수 있습니다.
• SHELL : Dockerfile에선 기본적인 셸이 리눅스에서 “/bin/sh -c”이며 이를 다른 셸을 쓰고싶을 때 따로 지정하여 사용할수 있습니다.
• COPY : 로컬 디렉토리에서 읽어 들인 컨텍스트로부터 이미지에 파일을 복사하는 역할을 합니다. 사용 방식이 ADD와 같아 차이점이 없는 것 처럼 보이지만, 기능만 같을 뿐 COPY는 로컬의 파일만 이미지에 추가할 수 있지만 ADD는 외부 URL 및 tar 파일에서도 파일을 추가할 수 있다는점이 다릅니다.
• ENTRYPOINT : CMD와 유사하게 컨테이너가 시작될 때 수행할 명령을 지정한다는 점은 같으나 ENTRYPOINT 는 커맨드를 인자로 받아 사용할 수 있는 스크립트의 역할을 할 수 있습니다.

 

Dockerfile로 빌드할 때 주의할 점

도커의 이미지 구조와 Dockerfile의 관계를 주의해야 합니다. Dockerfile을 아무렇게 작성하게 되면 저장 공간을 불필요하게 차지하는 이미지나 레이어가 너무 많은 이미지가 생성될 수 있습니다. 이럴 땐 Dockerfile을 작성할 때 &&로 각 RUN명령을 하나로 묶는 것입니다. 이 방법은 RUN이 하나의 이미지 레이거가 된다는 점을 이용해 다른 레이어로 생성될 명령어를 하나로 묶는 것입니다.

 

 

도커 데몬

도커 데몬과 도커 구조

도커의 구조는 크게 두 가지로 나뉩니다. 하나는 클라이언트 도커, 다른 하나는 서버 도커 입니다.

도커 엔진은 외부에서 API를 입력받아 도커 엔진의 기능을 수행하는데, 도커 프로세스가 실행되어 서버로서 입력을 받을 준비가 된 상태를 도커데몬이라고 합니다.

• 서버 도커 : 실제로 컨테이너를 생성하고 실행하며 이미지를 관리하는 주체입니다. dockerd 프로세스로 동작
• 클라이언트 도커 : 도커 데몬은 API입력을 받아 도커 엔진의 기능을 수행하는데 이 API를 사용할 수 있도록 CLI를 제공하는 것이 도커 클라이언트입니다. 사용자가 docker로 시작하는 명령어를 수행하는 것이 도커 클라이언트의 사용방식입니다.기본 설정상태에서 일반적인 도커 데몬을 제어하는 순서입니다.
  1. 사용자가 docker version 같은 도커 명령어를 입력합니다.
  2. /usr/bin/docker 는 /var/run/docker.sock 유닉스 소켓을 사용해 도커 데몬에게 명령어를 전달합니다.
  3. 도커 데몬은 이 명령어를 파싱하고 명령어에 해당하는 작업을 수행합니다.
  4. 수행 결과를 도커클라이언트에게 반환하고 사용자에게 결과를 출력합니다.

 

 

도커 데몬 실행

dockerd 명령어로 직접 도커 데몬을 실행할 수 있습니다만 보통은 운영체제에서 서비스를 이용해서 실행합니다.

 

 

도커 데몬 설정

--help 명령어를 통해 다양한 옵션을 확인할 수 있습니다.

• --insecure-registry : 레지스트리 컨테이너를 구축할 때 사용합니다.
• --log-driver : 컨테이너의 로깅을 설정할 때 사용합니다.
• --storage-opt : 스토리지 백엔드를 변경할 때 사용합니다.

 

도커 데몬 제어 : -H

이 옵션을 도커 데몬의 API를 사용할 수 있는 방법을 추가합니다.

• 아무 설정없이 실행한다면 유닉스 소켓인 /var/run/docker.socket 을 사용합니다.
• IP주소와 포트 번호를 입력하면 원격 API인 Docker Remote API로 도커를 제어할 수 있습니다.
• 다른 옵션이 설정되면 유닉스 소켓은 비활성화 됩니다.
• 다른 옵션과 함께 유닉스 소켓도 사용하려면 -H 옵션을 두번 사용하면 됩니다.
• dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375

 

 

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

기본적인 도커 데몬에는 보안이 설정돼 있지 않습니다. 이번에는 TLS보안을 설정하는 것입니다.

1. 서버측 파일 생성 :
   1. 인증서에 사용될 키를 생성합니다.
   2. 공용 키(public key)를 생성합니다. 입력하는 모든 항목은 공백으로 둬도 상관없습니다.
   3. 서버 측에서 사용될 키를 생성합니다.
   4. 서버측에서 사용될 인증서를 위한 인증 요청서 파일을 생성합니다.
   5. 접속에 사용될 IP주소를 extfile.cnt 파일로 저장합니다.
   6. 서버 측의 인증서 파일을 생성합니다.
2. 클라이언트 측에서 사용할 파일 생성
   1. 클라이언트 측의 키 파일과 인증 요청 파일을 생성하고, extfile.cnt 파일에 extendedKeyUsage항목을 추가합니다.
   2. 클라이언트 측의 인증서를 생성합니다.
   3. 필요한 파일 5개가 모두 생성됐는지 확인합니다.
   4. 생성된 파일의 쓰기 권한을 삭제해 읽기 전용 파일로 만듭니다.
   5. 도커 데몬의 설정 파일이 존재하는 디렉터리인 ~/.docker 로 도커 데몬 측에서 필요한 파일을 옮깁니다. (이것은 필수는 아니지만 한곳에 모아둠으로써 관리가 쉬워집니다.)

 

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

도커는 특정 스토리지 백엔드 기술을 사용해 도커 컨테이너와 이미지를 저장하고 관리합니다. 도커 환경에 따라 스토리지 드라이버는 자동으로 정해지지만 실행 옵션에서 --storage-driver 옵션으로 변경할 수 있습니다.

 

 

스토리지 드라이버의 원리

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

 

 

스냅숏

원본 파일은 읽기 전용으로 사용하되 해당 파일이 변경되면 새로운 공간을 할당하는 것 입니다. 스토리지를 스냅숏으로 만들면 스냅숏 안에 어느파일이 어디에 저장돼 있는지가 목록으로 저장됩니다. 그러다 변화가 생기면 변경된 내역을 따로 관리함으로써 스냅숏을 사용합니다.

원본 파일을 유지하면서도 변경된 사항을 저장해야 할때 이를 해결하는 방식에 따라 CoW, RoW로 나눕니다.

 

 

CoW

스냅숏의 파일에 쓰기 작업을 수행할 때 스냅숏 공간에 원본파일을 복사한 뒤 쓰기 요청을 반영합니다. 이때 파일읅 읽는 작업, 파일을 스냅숏 공간에 쓰고 변경사항을 반영하는 작업으로 총 2번의 쓰기 작업이 일어나므로 오버헤드가 발생할 수 있습니다.

 

 

RoW

파일을 스냅숏 공간에 복사하는 것이 아니라 스냅숏에 기록된 원본 파일은 스냅숏 파일로 묶은(Freeze) 뒤 변경된 사항을 새로 할당받아 덮어쓰는 방식입니다. 곧 스냅숏 파일은 그대로 사용하되, 새로운 블록은 변경사항으로 사용하는 것입니다.

 

 

AUFS 드라이버

AUFS 드라이버는 데비안 계열에서 기본으로 사용하는 드라이버이며, 도커에서 오랫동안 사용해왔기에 안정성 측면에서 우수하다고 평가받습니다. 그러나 기본 커널에 포함돼 있지 않으므로 일부 운영체제에서는 사용할 수 없으며, 사용할 수 없는 대표적인 운영체제는 RHEL, CentOS등이 있습니다.

 

 

Devicemapper 드라이버

레드햇 계열의 리눅스 배포판을 위해 개발된 스토리지 드라이버입니다. 보편적인 운영체제에서 사용할 수 있다는 장점이 있지만 성능상의 이슈로 deprecated된 드라이버 입니다.

 

 

OverlayFS 드라이버

레드햇 계열 및 라즈비안(Raspbian),우분투 등 대부분 운영체제에서 도커를 설치하면 자동으로 사용되도록 설정되는 드라이버입니다. AUFS와 비슷한 원리로 동작하지만 좀 더 간단한 구조로 사용되며 성능또한 조금 더 좋기에 최신 버전의 도커는 OverlayFS를 기본적으로 사용합니다.

 

 

Btrfs 드라이버

리눅스 파일시스템 중 하나로 SSD 최적화, 데이터 압축등 다양한 기능을 제공합니다. 다른 드라이버와 다르게 별도로 구성하지 않으면 도커에서 사용할 수없으며 btrfs 파일시스템을 사용하는 공간에 마운트돼 있어야만 도커는 Btrfs를 스토리지 드라이버로 인식합니다.

Btrfs 드라이버는 이미지와 컨테이너를 서브 볼륨(subvolume)과 스냅숏 단위로 관리합니다. 구조 자체는 AUFS, devicemapper등 다른 스토리지 드라이버와 유사합니다. Btrfs 드라이버는 자체적으로 SSD에 최적화돼 있으며 대체적으로 우수한 성능을 보여줍니다. 또한 리눅스의 파일시스템이 제공하지 않는 다양한 기능을 제공한다는 장점도 있습니다.

 

 

ZFS 드라이버

ZFS는 썬 마이크로시스템즈에서 개발했으며 Btrfs처럼 압축, 레프리카, 데이터 중복 제거등 다양한 기능을 제공합니다. 그러나 ZFS는 라이선스문제로 리눅스 커널에 기본적으로 탑재돼 있지 않아 별도의 설치를 해야합니다.

 

 

컨테이너 저장 공간 설정

컨테이너 내부에서 사용되는 파일시스템의 크기는 도커가 사용하고 있는 스토리지 드라이버에 따라 조금씩 다릅니다. 도커 엔진이 AUFS나 orverlay2등의 스토리지를 드라이버로 사용하도록 설정돼 있다면 컨테이너는 호스트와 저장 공간의 크기를 공유합니다.

 

 

devicemapper에서 컨테이너 저장 공간 설정

devicemapper와 같은 일부 드라이버같은 경우 기본적으로 컨테이너는 10GB의 저장 공간을 할당받습니다. 각 스토리지 드라이버마다 컨테이너에게 저장 공간을 할당하는 방식이 다릅니다. 그러나 스토리지 드라이버에 상관없이 컨테이너의 저장 공간을 제한하는 기능을 도커 엔진에서 자체적으로 제공하고 있지는 않지만 일부 드라이버 (devicemapper , overlay2 등)는 저장 공간을 제한하는것이 가능합니다.

 

DOCKER_OPTS = ... --storage-driver=devicemapper --storage-opt dm.basesize=20G ..

--storage-driver 는 백엔드 스토리지 드라이버로서 devicemapper를 설정하고, --storage-opt dm.basezie는 컨테이너의 기본 저장 공간의 크기를 20GB로 설정하는 예제입니다. 기본 크기는 10GB입니다.

 

 

overlay2에서의 컨테이너 저장 공간 설정

overlay2를 스토리지 드라이버로 사용하면서 도커 데이터 디스크가 xfs파일 시스템일 경우 project quota라는 기능을 이용해 저장 공간을 제한할 수 있습니다. 다음은 준비 과정입니다.

1. 호스트 서버에 새로운 디스크를 추가합니다.
2. 해당 디스크를 xfs 파일 시스템으로 포맷하고, 호스트 서버에 마운트합니다.
3. 도커 엔진이 데이터를 저장하는 경로를 xfs 파일 시스템의 디렉터리로 변경합니다.

 

 

도커 데몬 모니터링

도커 데몬을 모니터링 하는 이유는 수 많은 도커 서버를 효율적으로 관리하기 위해서거나, 도커로 컨테이너 애플리케이션을 개발하다가 문제가 생겼을 때 확인하기 위해서거나, 도커를 PaaS로써 제공하기 위해 실시간으로 도커 데몬의 상태를 모니터링해야 할 수도 있습니다.

 

 

도커 데몬 디버그 모드

도커 데몬을 정확하고 확실히 디버깅하기 위해서는 도커 데몬을 디버그 모드로 실행하는 것 입니다. 방법은 도커 데몬을 실행할 때 -D 옵션을 추가해서 사용할 수 있습니다.

dockerd -D

하지만 디버그 모드는 로그에서 너무 많은 정보까지 출력되어 찾기 힘들거나 파일을 읽거나 도커 데몬을 포그라운드 상태로 실행해야 한다는 단점이 있으므로 부족합니다.

 

 

events, stats, system df 명령어

• events

  docker events
  docker system events
  

• 도커가 기본으로 제공하는 명령어로 실시간 스트림 로그로 확인할 수 있습니다.
• stats

  docker stats
  docker stats --no-stream #스트림 방식이 아닌 한 번만 출력하는 방식으로 설정
  

• 실행 중인 모든 컨테이너의 자원 사용량(CPU, 메모리 제한 및 사용량, 네트워크 입출력, 블록 입출력등)을 스트림으로 출력합니다.
• system df

  docker system df
  

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

 

 

CAdvisor

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

그러나 CAdvisor는 단일 도커 호스트만을 모니터링할 수 있다는한계가 있습니다. 여러 호스트로 도커를 사용하거나 PaaS같은 도커 클러스터를 구축했다면 단일 CAdvisor 컨테이너는 용도에 맞지 않을 수 있습니다. 이를 위해 보통은 쿠버네티스나 도커 스웜 모드같은 컨테이너 오케스트레이션 툴을 통해 프로메테우스, InfluxDB등을 이용해 여러 호스트의 데이터를 수집하는 것이 일반적입니다.

 

 

Remote API 라이브러리를 이용한 도커

도커를 제어하고 싶을 경우 일일히 Remote API에 대한 요청을 소스코드로 제작할 필요 없이 이미 제작된 라이브러리를 이용할 수 있습니다. 도커 SDK 페이지에서 확인할 수 있으며, 다양한 언어를 오픈소스로 지원합니다.