DooD ( Docker out of Docker )

 

**DooD(Docker out of Docker)**는 Docker 컨테이너에서 호스트 시스템의 Docker 엔진을 직접 사용하는 설정 방식입니다. 이는 컨테이너 내부에서 별도의 Docker 설치 없이, 호스트 시스템의 Docker를 활용하여 컨테이너를 실행하거나 관리할 수 있도록 해줍니다.

 

 

DooD의 원리

DooD는 두 가지 주요 요소를 공유하여 동작합니다:

1. Docker CLI 실행 파일 공유:
   • /usr/bin/docker를 컨테이너에 마운트하여 Docker CLI(Command Line Interface)를 사용 가능하게 함.
    volume:

   - /usr/bin/docker:/usr/bin/docker
2. Docker 데몬 소켓 공유:
   • /var/run/docker.sock을 컨테이너에 마운트하여 컨테이너 내부에서 호스트 Docker 데몬과 통신 가능.
   volume:
   

   - /var/run/docker.sock:/var/run/docker.sock

    

   DooD의 작동 방식

   1. 컨테이너 내부에서 실행된 Docker CLI 명령은 /var/run/docker.sock을 통해 호스트의 Docker 데몬과 통신.
   2. 컨테이너 내부에서 실행된 Docker 명령은 실제로 호스트에서 컨테이너를 생성/관리.

    

   DooD의 특징

   장점

   1. 리소스 절약:
      • 컨테이너 내부에 Docker 엔진을 설치할 필요가 없음.
      • 중복된 Docker 데몬을 실행하지 않아 메모리와 CPU를 절약.
   2. 간단한 설정:
      • Docker CLI와 데몬 소켓만 공유하면 설정 가능.
   3. 기존 환경 활용:
      • 호스트 시스템의 Docker 리소스와 네트워크를 그대로 활용.

    

   단점

   1. 보안 문제:
      • /var/run/docker.sock은 호스트 Docker 데몬과의 직접적인 통신을 허용하므로, 컨테이너 내부에서 호스트 시스템 전체를 제어할 수 있는 권한을 가지게 됨.
      • 컨테이너가 침해될 경우 호스트 시스템 전체가 위험에 노출될 수 있음.
   2. 컨테이너 간 격리 부족:
      • 컨테이너 내부에서 실행된 Docker 명령이 호스트 환경의 컨테이너를 직접 제어하므로, 컨테이너 간의 명확한 격리성이 없어짐.
   3. 의존성:
      • 컨테이너가 호스트의 Docker 데몬에 의존하기 때문에, Docker 버전 호환성 문제가 발생할 수 있음.

    

   DooD 사용 사례

   1. CI/CD 파이프라인:
      • Jenkins와 같은 도구에서 도커 이미지를 빌드하고 배포.
      • Jenkins 컨테이너 내부에서 Docker 명령을 실행하려면 DooD를 사용.
   2. 테스트 환경:
      • 컨테이너 내부에서 새로운 컨테이너를 실행하여 테스트 자동화.
   3. 복잡한 컨테이너 배포 관리:
      • 컨테이너 내부에서 Kubernetes 클러스터나 Docker Swarm을 제어하는 스크립트를 실행.