Jenkins에서 DooD, DinD와 권장 사항

 

서론

Jenkins에서 컨테이너 빌드 및 실행 파이프라인을 활용할 때, DooD(Docker-outside-of-Docker)와 DinD(Docker-in-Docker)는 대표적인 접근법입니다. 이 글에서는 두 방식의 개념, 차이점, 실제 사례, 보안 및 운영상의 권장사항을 정리하였습니다.

1. DooD(Docker-outside-of-Docker)란?

• Jenkins 컨테이너가 호스트(또는 VM)의 도커 엔진 소켓(/var/run/docker.sock)에 직접 접근해 컨테이너를 실행·관리하는 방식입니다.
• Jenkins 빌드 환경에서 스크립트나 플러그인으로 실제 도커 엔진을 호출합니다.
• 장점:
  • 실제 호스트의 네트워크, 스토리지를 활용 가능
  • 추가 컨테이너 실행이 빠르고 간단함
• 단점:
  • 소켓 노출로 인해 호스트의 권한이 직접적으로 전달(보안 위험)
  • 여러 빌드가 동일한 도커 엔진에 경쟁적으로 접근하며 환경 격리 약함

2. DinD(Docker-in-Docker)란?

• Jenkins 컨테이너 내부에서 도커 엔진을 직접 실행시키는 방식 (즉, 컨테이너 안의 컨테이너)
• 보통 Jenkins 파이프라인에서 docker:dind 이미지를 사용
• 장점:
  • 각 파이프라인이 독립적인 도커 환경을 보장, 환경 간 격리 강화
  • 멀티테넌시 상황에서 컨테이너 영향 최소화
• 단점:
  • 네트워크 오버헤드, 퍼포먼스 저하
  • 내부 볼륨·네트워크 관리 복잡, 종료 시 데이터 유실 리스크
  • 일부 기능(예: privileged 모드 필수)에서 추가 보안 위험

3. 보안 및 운영 권장사항

구분	보안 위험	운영상 특징	권장도
DooD	도커 소켓 노출(=호스트 권한)	빠르지만 호스트 전체 공격 위험	낮음
DinD	Privileged 필요, 도커 엔진 공격면	환경 격리↑, 퍼포먼스↓, 관리 복잡	중간
BuildKit, Kaniko	도커엔진 불필요, 쿠버네티스 네이티브	Container Registry 직접 빌드; 관리 쉬움	높음(권장)

• 중요:
  • 보안 기준이 강화되는 최근 DevOps 환경에서는 Kaniko, BuildKit, Tekton 등 “도커 엔진 비의존적” 방식이 표준으로 자리잡고 있습니다.
  • 불가피하게 DooD 환경을 쓸 경우, 빌드 머신의 별도 네임스페이스, 접근제어 강화, 그리고 네트워크 격리가 반드시 필요합니다.

4. 결론

Jenkins에서 Docker 작업을 할 때, 과거에는 DooD/DinD 방식 모두 널리 쓰였으나, 점차 보다 안전하고 쿠버네티스 친화적이며, 도커 엔진을 직접 노출하지 않는 Kaniko, BuildKit 등 대안으로 전환 중입니다.

설계 단계부터 빌드 방식의 보안과 유지보수성을 꼭 검토하여, 환경에 맞는 안전한 방식을 선택하세요.

이 내용을 복사해 노션에 붙여넣으면 체계적인 한글 블로그 글로 바로 활용하실 수 있습니다! 추가 요청이나 세부 확장이 필요하면 말씀해 주세요.