[Docker] Dind (Docker in docker) / Dood(Docker out of docker)

Jenkins와 같이 CI/CD 툴을 Docker 컨테이너로 이용할 때, 타 WAS의 이미지를 빌드하고 컨테이너로 사용하려고 하면 아래와 같은 고민사항이 있을 것이다.

 

Jenkins 컨테이너 내부에서는 로컬호스트와 격리된 환경이기 때문에 이미지를 빌드할 때 이용될 때에는 어떤 도커를 기반으로 이미지를 생성할지, 컨테이너의 각 환경은 어떻게 외부와 통신을 할 것인지 등의 의문이 들 것이다.

 

그렇기 때문에 다음과 같은 개념이 생기게 되었다.

 

1. Dind(Docker in docker)

Dind(Docker in docker)는 문자의 의미 그대로 도커 내부에서 로컬 호스트에서 이용하는 도커와는 다른 별도의 도커를 사용한다는 의미이다.

 

그 예시로 Jenkins 컨테이너에서 도커 이미지를 빌드하려면 도커가 필요한데, 컨테이너 내부에 도커를 추가로 설치하고 설치한 도커를 기반으로 이미지를 빌드하고 사용하는 것이다.

 

[예시 : Dind(Docker in docker)]

하지만 이 방식은 호스트 대신으로 이용될 Jenkins 컨테이너가 privilieged mode로 실행이 되어야 한다는 단점을 가지고 있고, 이는 일개의 컨테이너에 호스트의 권한을 위임함으로써 보안의 위험을 초래하기 때문에, Docker 레퍼런스에서도 Dind 방식을 권장하지 않는다.

# 이미지로 컨테이너 생성 명령어
$ docker run --privileged [이미지 ID/이미지 TAG]

 

2. Dood(Docker out of docker)

Dood(Docker out of docker)는 도커 내부에서 로컬 호스트의 도커 소켓(docker.sock)을 마운트 하여 컨테이너 내부에서 로컬 호스트의 도커를 기반으로 사용한다는 의미이다.

 

Jenkins 이미지를 빌드할 때, 도커를 설치하고(Dockerfile을 이용) 이미지로 컨테이너를 생성할 때, 로컬 호스트의 도커 소켓을 마운트 해주면 되는 것이다.

[예시 : Dood(Docker out of docker)]

 

Dood 방식은 도커의 소켓만을 공유하여 컨테이너 내부에서 이용하는 도커가 외부에서 같이 이용되게끔 구축한 것이기 때문에 Dind 방식과 같은 보안 이슈도 존재하지 않고 상대적으로 권장되고 있는 방법이다.

# 볼륨 마운트로 실행 - 도커의 소켓파일 위치확인 필수
 $ docker run -v /var/run/docker.sock:/var/run/docker.sock [이미지 ID/이미지 TAG]