젠킨스를 실습하는 중에 Docker Out of Docker이라는 단어를 알게되었고, 막연하게 알고 있었던 "Docker-in-Docker"와 어떤 차이가 있는지 궁금해 찾아보게 되었다.
일단 어떤 상황이었는지에 대해 먼저 말해보자면, 젠킨스를 도커 컨테이너로 실행한 후에 도커와 SSH 서버가 설치된 도커 컨테이너 이미지를 실행하였다. 로컬에서 docker ps 했을때 보여지는 컨테이너는 두개. 젠킨스(이하 젠킨스 컨테이너) 와 도커와 SSH가 설치된 컨테이너(이하 도커 컨테이너)이다.
젠킨스에서 빌드한 .war 파일을 도커 컨테이너로 복사한 후에 도커 컨테이너 안에서 해당 패키지 파일을 복사하여 톰캣 컨테이너를 실행한다. 따라서 정리해보면 아래와 같은 구조가 된다. 여기서 Docker in Docker가 등장한다.
Docker in Docker, Docker out of Docker는 둘다 도커안에서 도커를 사용할 수 있다는 것인데
Docker in Docker의 경우 도커 agent(daemon)가 설치된 도커 이미지를 사용한다. 도커 이미지를 구동할때 privileged option을 이용하여 실행하면 host에서 할 수 있는 많은 가능성을 가진 모드로 실행할 수 있다. (커널접근이나 장치접근 등) 따라서 보안관점에서 보면 취약하다.
docker run --privileged ...
Docker out of Docker는 도커안에서 도커를 설치하는 방식이 아닌 도커안에서 소켓파일을 이용해서 호스트에서 사용하는것처럼 도커를 사용할 수 있다. 이 소켓파일은 /var/run/docker.sock으로 해당 파일을 마운트함으로써 공유하게 된다. 이또한 내부 컨테이너에서 외부 컨테이너에 액세스할 수 있으므로 보안적으로 좋지않다.
docker run -v /var/run/docker.sock:/var/run/docker.sock ...
https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/
Using Docker-in-Docker for your CI or testing environment? Think twice.
The primary purpose of Docker-in-Docker was to help with the development of Docker itself. Many people use it to run CI (e.g. with Jenkins), which seems fine at first, but they run into many “interesting” problems that can be avoided by bind-mounting t
jpetazzo.github.io
위 블로그에서도 CI환경에서 Docker in Docker를 사용하기전에 다시 생각해보라고 말하고 있다.(대신 socket방식을 사용하라고 말하고 있긴한데, 이 또한 보안에 취약하다는 점을 참고하자) 나는 테스트 환경이라서 저런 환경으로 실습을 진행해본것이고, 이런것이 있다는 것 정도로만 알고 있으면 될 것 같다.