🐳 DinD vs DooD: Docker 기반 Jenkins/Argo CI/CD 전략 분석

Docker 기반의 CI/CD 파이프라인을 구성할 때, Jenkins나 Argo 같은 자동화 도구에서 Docker를 어떻게 실행할지에 따라 DinD(Docker-in-Docker) 와 DooD(Docker-outside-of-Docker) 두 가지 방식 중 선택하게 된다.

DinD (Docker-in-Docker)

graph TD
  Host[Host Machine]
	subgraph OuterDinD ["Outer 컨테이너(도커 데몬 실행 중)"]
	  Inner1["Inner 컨테이너 1"]
	  Inner2["Inner 컨테이너 2"]
	end

  Host --> |previleged 권한 부여| OuterDinD

  classDef outer fill:#44f,stroke:#fff,stroke-width:2px;
  classDef inner fill:#88f,stroke:#333,stroke-width:1px;
  classDef host fill:#000,stroke:#000,stroke-width:2px;

  class Host host;
  class OuterDinD outer;
  class Inner1,Inner2 inner;

dind

컨테이너 내부에서 자체적으로 Docker 데몬을 실행하여, 완전한 격리 환경을 제공한다.

예를 들어, Jenkins Job이 실행되는 컨테이너 안에서 독립적인 Docker 데몬을 구동하여, 그 안에서 다시 컨테이너를 실행하는 구조이다. 이러한 방식은 테스트 환경을 완전히 분리하고자 할 때 유용하다.

그러나 —privileged 권한이 필요하며, 보안상 위험이 존재하고 리소스 사용량이 많을 수 있다.

DooD (Docker-outside-of-Docker)

graph TD
	Host["Host Machine"]
  subgraph Group1 [병렬 실행]
	  Pararrel1["Inner 컨테이너 1"]
	  OuterDooD["Outer 컨테이너 (docker CLI 사용, 도커데몬 없음)"]
	  Pararrel2["Inner 컨테이너 2"]
	end
  

  Host --> |docker.sock만 공유| OuterDooD
  

  classDef outer fill:#44f,stroke:#fff,stroke-width:2px;
  classDef inner fill:#44f,stroke:#333,stroke-width:1px;
  classDef host fill:#000,stroke:#000,stroke-width:2px;

  class Host host;
  class OuterDooD outer;
  class Pararrel1,Pararrel2 inner;

dood

컨테이너에서 호스트의 Docker 소켓(/var/run/docker.sock)을 공유하여 Docker 명령어를 실행한다.

즉, Jenkins나 Argo의 컨테이너가 호스트의 Docker 데몬에 접근하여 직접 Docker 명령어를 실행하는 방식이다. 이러한 방식은 설정이 간단하고 성능이 우수하지만, 호스트의 Docker 권한을 공유받기 때문에 보안상 주의가 필요하다.

비교 분석: DinD vs DooD

구분	DinD (Docker-in-Docker)	DooD (Docker-outside-of-Docker)
실행 방식	컨테이너 내부에서 Docker 데몬 구동	호스트 Docker 소켓을 공유
권한 필요	—privileged 권한 필요	소켓 마운트만으로 가능
격리성	완전한 격리 (테스트용 유리)	호스트와 공유 (속도 빠름)
보안성	낮음 (권한 높음)	소켓 공유 위험 존재
성능	느릴 수 있음 (내부 데몬)	빠름 (호스트 직접 실행)
대표 사용 사례	테스트 컨테이너 분리, Lab 환경	실전 배포, Docker 빌드/푸시

Jenkins에서의 활용

DooD 방식

docker run \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v $(pwd):/workspace \
  jenkins/jenkins:lts

Jenkins 컨테이너는 호스트의 Docker 엔진에 접근
docker build, docker push 등 쉽게 실행 가능
주의: 호스트의 Docker 전체 권한을 공유받음 → 보안 고려 필요

DinD 방식

docker run --privileged \
  -v $(pwd):/workspace \
  docker:dind

Jenkins Job에서 자체 Docker 데몬 구동
격리된 테스트 환경 구성에 적합
리소스 사용량이 많고 보안 리스크 존재

Argo Workflow에서의 활용

DooD 기반 구성 예시

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: dood-example-
spec:
  entrypoint: docker-job
  templates:
    - name: docker-job
      container:
        image: docker
        command: ["docker", "build", "-t", "myimage", "."]
        volumeMounts:
          - name: docker-socket
            mountPath: /var/run/docker.sock
  volumes:
    - name: docker-socket
      hostPath:
        path: /var/run/docker.sock

호스트의 Docker 소켓 공유
빠른 빌드, 배포 작업에 적합

DinD 기반 구성 예시

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: dind-example-
spec:
  entrypoint: docker-job
  templates:
    - name: docker-job
      container:
        image: docker:dind
        securityContext:
          privileged: true
        command: ["dockerd-entrypoint.sh"]

독립적인 Docker 데몬 실행
격리된 테스트 환경에 적합하나 보안/자원 이슈 고려 필요

정리

DooD는 속도와 간편함을 중시할 때 사용
DinD는 격리성과 테스트 환경 독립성이 중요할 때 사용
Jenkins, Argo 환경 모두 목적에 따라 두 방식을 선택적으로 활용할 수 있음

DinD (Docker-in-Docker)
DooD (Docker-outside-of-Docker)
비교 분석: DinD vs DooD
Jenkins에서의 활용
- DooD 방식
- DinD 방식
Argo Workflow에서의 활용
- DooD 기반 구성 예시
- DinD 기반 구성 예시
정리