DinD vs. DooD 그리고 Jenkins
컨테이너 환경에서 다시 Docker를 실행하는 방법에는 DinD(Docker-in-Docker)와 DooD(Docker-outside-of-Docker) 두 가지 방식이 있습니다.
특히, CI/CD 파이프라인에서 Jenkins와 Docker를 함께 활용할 때 이 두 개념을 이해하고 적절한 방식을 선택하는 것이 중요합니다.
1. DinD(Docker-in-Docker)란?
DinD는 컨테이너 내부에서 별도의 Docker 데몬을 실행하여, 그 내부에서 추가적인 컨테이너를 생성하는 방식입니다.
✅ 특징
- 컨테이너 내부에서 자체적인 Docker 데몬을 실행
- 컨테이너 내부에서 실행된 Docker 엔진이 자체적인 컨테이너를 관리
- 격리된 환경을 제공하며, 테스트 및 빌드 환경을 독립적으로 운영 가능
- 실행을 위해
--privileged옵션이 필요할 수 있음
🔍 예제 실행 (DinD 컨테이너 실행)
docker run --privileged -d --name dind-container docker:dind위 명령을 실행하면 docker:dind 이미지를 기반으로 DinD 환경을 실행할 수 있습니다.
⚠️ 단점
- 추가적인 Docker 데몬 실행으로 인해 성능 오버헤드 발생
- 컨테이너 내부에서 또 다른 Docker 데몬을 실행하는 구조이므로 관리가 복잡해질 수 있음
- 보안 위험 증가 (
--privileged모드 사용 시 권한 상승 가능성)
2. DooD(Docker-outside-of-Docker)란?
DooD는 컨테이너 내부에 Docker CLI(명령어 인터페이스)만 설치하고, 실제 컨테이너 실행 요청을 호스트 머신의 Docker 데몬으로 전달하는 방식입니다.
✅ 특징
- 컨테이너 내부에서 직접 Docker 데몬을 실행하지 않음
- 컨테이너 내부의 Docker CLI가 호스트의 Docker 데몬과 통신하여 컨테이너 실행
- 보통
/var/run/docker.sock을 공유하여 Docker 명령을 전달 - 경량화된 방식으로 실행 가능
🔍 예제 실행 (DooD 방식으로 실행)
docker run -v /var/run/docker.sock:/var/run/docker.sock -it docker위 명령어는 컨테이너 내부에서 Docker CLI를 실행하지만, 실제 컨테이너는 호스트의 Docker 데몬에서 실행됩니다.
⚠️ 단점
/var/run/docker.sock을 공유하므로 보안 취약점이 발생할 수 있음- 컨테이너 내부에서 실행한 Docker 명령이 직접 호스트에 영향을 미침
2.5 DinD vs DooD
3. Jenkins에서 DinD vs. DooD 적용
Jenkins에서 Docker를 활용하여 CI/CD 파이프라인을 구축할 때, DinD와 DooD 방식 중 어떤 방식을 선택할지 고려해야 합니다.
✅ Jenkins에서 DinD 적용
사용 사례:
- CI/CD 파이프라인 실행 시 격리된 빌드 환경이 필요할 때
- 각 파이프라인이 서로 독립적인 Docker 환경을 가져야 할 때
예제 (DinD 방식으로 Jenkins 실행)
docker run --privileged -d --name jenkins-dind -p 8080:8080 jenkins/jenkins장점
✔️ 완전히 독립적인 환경 제공
✔️ Jenkins 에이전트마다 별도 Docker 환경을 제공 가능
단점
❌ --privileged 모드 필요 (보안 취약점 증가)
❌ 성능 오버헤드 발생
✅ Jenkins에서 DooD 적용
사용 사례:
- 빌드 속도를 최적화해야 할 때
- Jenkins의 컨테이너에서 실행하는 Docker 명령이 호스트의 Docker 데몬을 활용해야 할 때
예제 (DooD 방식으로 Jenkins 실행)
docker run -v /var/run/docker.sock:/var/run/docker.sock -d --name jenkins-dood -p 8080:8080 jenkins/jenkins장점
✔️ 성능이 빠르고 경량화된 방식
✔️ Jenkins 빌드 속도를 높일 수 있음
단점
❌ /var/run/docker.sock 공유로 인해 보안 취약점 존재
❌ Jenkins 컨테이너에서 실행한 Docker 명령이 호스트에 직접 영향을 미침
4. DinD vs. DooD vs. Jenkins 비교
| DinD (Docker-in-Docker) | DooD (Docker-outside-of-Docker) | |
|---|---|---|
| 실행 방식 | 컨테이너 내부에서 Docker 데몬 실행 | 컨테이너 내부에서 Docker CLI 사용하여 호스트의 Docker 데몬과 통신 |
| 독립성 | 각 컨테이너마다 별도 Docker 환경 제공 | 호스트의 Docker 환경을 그대로 사용 |
| 성능 | 추가적인 Docker 데몬 실행으로 오버헤드 발생 | 경량화된 방식으로 속도 향상 |
| 보안 | --privileged 모드 필요, 보안 위험 증가 | /var/run/docker.sock 공유로 보안 위험 존재 |
| Jenkins에서 활용 | CI/CD 파이프라인 실행 시 완전한 격리 환경 필요할 때 | 빠른 빌드 속도와 간단한 구성 필요할 때 |
5. 어떤 방식을 선택해야 할까?
✅ 독립적인 빌드 환경이 필요한 경우 → DinD 사용
✅ 빠르고 간단한 빌드가 필요한 경우 → DooD 사용
✅ 보안이 중요한 환경에서는?
- DinD 사용 시
--privileged사용을 최소화하고, 필요할 경우 Kubernetes 등으로 격리 - DooD 사용 시
/var/run/docker.sock을 공유할 때 읽기 전용(ro)으로 설정하거나 보안 강화 조치 적용
6. 결론
Jenkins에서 Docker를 활용할 때 DinD와 DooD 방식은 각각 장단점이 있으며, 사용 목적에 따라 적절한 방식을 선택해야 합니다.
- 격리된 환경이 필요하다면
DinD - 빠르고 간단한 실행이 필요하다면
DooD
