인 2013 년 8 월 제롬 Petazzoni가 고정 표시기 도커을 생성, dind짧게,이 도커 컨테이너 부두 노동자 컨테이너의 내부를 생성 할 수,이 기능의 결과로 매우 인기가 입증 제롬의 GitHub의 저장소 천 별과 삼백 포크를 통해 수신하는 단계를 포함한다.

2 년 후 2015 년 8 월에 출시 된 Docker 1.8에서 Docker in Docker는 Docker에서 바로 지원됩니다. 그러나 Docker에서 Docker를 사용하면 Jérôme의 Post : CI 또는 테스트 환경에 Docker-in-Docker 사용 과 관련하여 경고가 나타납니다 . 두 번 생각. Docker in Docker가 Continuous Integration에 적합하지 않은 이유에 중점을 둡니다.

Docker에서 Docker를 사용하는 것이 왜 나쁜 것으로 간주됩니까? 거북을 완전히 피하는 경우 일까요? 또는 성능 고려 사항?

지속적인 통합 문제

한마디로 : Docker in Docker (dind)는 동시성을 잘 처리하지 못합니다.

CI에 dind를 사용하지 않아야하는 이유는 Docker가 스토리지에 사용하는 디렉토리 (일반적으로 /var/lib/docker)에 독점적으로 액세스 할 수 있도록 설계 되었기 때문 입니다. 모든 하위 프로세스가이 디렉토리를 동시에 사용하므로 Dind는이를 존중하지 않습니다. CI를 사용하여 다시 빌드 할 때마다이 디렉토리의 앱과 관련된 모든 항목이 지워지고 0부터 시작될 수 있습니다. 사용자가 결제 세부 정보를 입력하고 "구매"를 클릭 한 후 갑자기 아무 일도하지 않은 것처럼 로그인 화면에서 자신을 다시 발견 한 경우 사용자가이를 어떻게 좋아합니까? 그것은 좋은 UX가 아닙니다. 두 번의 재 구축이 한 번에 발생합니까? 그것은 데이터 무결성을 포함하여 관련된 모든 사람들에게 나쁜 결과를 초래할 것입니다.

다른 문제

OP가 게시 한 링크에서 시스템은 명시 적으로 금지되지 않는 한 하위 컨테이너가 외부 컨테이너의 리소스에 액세스 할 수있는 매우 "CSS와 같은"방식으로 보안 정책을 적용하려고 할 때 보안 문제가 발생합니다. "mywebsite.com/../another_folder/private_resource.txt"와 같은 작업을 수행하여 웹 서버 리소스에 액세스 할 수있는 시점을 기억하십니까? 또한 때때로 파일 시스템은 이런 방식으로 중첩 될 때 서로 잘 작동하지 않습니다.

수정

고맙게도 OP의 블로그 게시물에는이 문제에 대한 좋은 해결책이 있습니다. "Docker에서 실행되는 CI 시스템 자체에서 Docker 컨테이너 빌드 / 실행 / 푸시"로 사용자 요구가 충족되지 않는 한, Docker 소켓 (일반적으로 )의 -v모드 를 사용 하여 컨테이너에 데이터 볼륨을 추가 할 수 있습니다. /var/run/docker.sock:/var/run/docker.sock"공유"데이터 볼륨에 액세스해야합니다. 이 컨테이너는 동기 IO를 강제 ​​실행하는 대신 상위와 함께 시작됩니다. 이제는 거의 동일한 것과 거의 동일하지만 Docker와 함께 제공되는 단점은 동시성을 위해 빌드되지 않습니다.

참조 (OP에서) : CI 또는 테스트 환경에 Docker-in-Docker를 사용하십니까? 두 번 생각.