Docker 내에서 Docker를 실행하면 이미 컨테이너화된 환경 내에서 이미지를 빌드하고 컨테이너를 시작할 수 있습니다. 자식 컨테이너를 시작할지 형제 컨테이너를 시작할지에 따라 두 가지 가능한 접근 방식이 있습니다.
Docker 컨테이너 내부에서 Docker에 액세스하는 것은 CI 및 CD 시스템의 맥락에서 가장 바람직합니다. Docker 컨테이너 내에서 파이프라인을 실행하는 에이전트를 호스팅하는 것이 일반적입니다. 파이프라인 단계 중 하나가 이미지를 빌드하거나 컨테이너와 상호 작용하는 경우 Docker-in-Docker 전략을 사용하게 됩니다.
Docker-in-Docker 이미지
Docker는 다음을 통해 자체 포함된 이미지로 제공됩니다. docker:dind Docker Hub의 태그. 이 이미지를 시작하면 새 컨테이너 내부에 작동하는 Docker 데몬 설치가 제공됩니다. 실행 중인 호스트의 데몬과 독립적으로 작동합니다. dind 컨테이너, 그래서 docker ps 컨테이너 내부는 다른 결과를 줄 것입니다. docker ps 당신의 호스트에.
docker run -d --privileged --name docker
-e DOCKER_TLS_CERTDIR=/certs
-v docker-certs-ca:/certs/ca
-v docker-certs-client:/certs/client
docker:dind
이러한 방식으로 Docker-in-Docker를 사용하면 한 가지 큰 주의 사항이 있습니다. 권한 모드를 사용해야 합니다. 이 제약 조건은 루트가 없는 컨테이너를 사용하는 경우에도 적용됩니다. 특권 모드는 다음에 의해 활성화됩니다. --privileged 위에 표시된 명령에서 플래그를 지정합니다.
권한 모드를 사용하면 컨테이너에 호스트 시스템에 대한 완전한 액세스 권한이 부여됩니다. 이것은 Docker-in-Docker 시나리오에서 필요하므로 내부 Docker가 새 컨테이너를 생성할 수 있습니다. 그러나 일부 환경에서는 수용할 수 없는 보안 위험이 있을 수 있습니다.
다른 문제가 있습니다 dind 도. 특정 시스템은 AppArmor 및 SELinux와 같은 Linux 보안 모듈(LSM)과 충돌이 발생할 수 있습니다. 이는 내부 Docker가 외부 데몬이 예측할 수 없는 LSM 정책을 적용할 때 발생합니다.
또 다른 문제는 컨테이너 파일 시스템에 관한 것입니다. 외부 데몬은 다음과 같은 호스트의 일반 파일 시스템 위에서 실행됩니다. ext4. 내부 Docker 데몬을 포함한 모든 컨테이너는 CoW(기록 중 복사) 파일 시스템에 있습니다. 내부 데몬이 기존 CoW 파일 시스템 위에서 사용할 수 없는 스토리지 드라이버를 사용하도록 구성된 경우 비호환성이 발생할 수 있습니다.
대신 호스트의 Docker 소켓 탑재
와 관련된 과제 dind 사용을 완전히 피하는 것이 가장 좋습니다. 많은 시나리오에서 호스트의 Docker 소켓을 일반 docker 컨테이너:
docker run -d --name docker
-v /var/run/docker.sock:/var/run/docker.sock
docker:latest
내부의 Docker CLI docker 이미지는 찾은 Docker 데몬 소켓과 상호 작용합니다. /var/run/docker.sock. 호스트의 소켓을 이 경로에 마운트하는 것은 docker 컨테이너 내부에서 실행되는 명령은 기존 Docker 데몬에 대해 실행됩니다.
즉, 내부 Docker에 의해 생성된 컨테이너는 Docker 컨테이너 자체와 함께 호스트 시스템에 상주합니다. 중첩된 Docker가 부모의 자식인 것처럼 느껴지더라도 모든 컨테이너는 형제로 존재합니다. 달리기 docker ps 호스트에서 실행하든 컨테이너 내부에서 실행하든 동일한 결과를 생성합니다.
이 기술은 구현 문제를 완화합니다. dind. 또한 Docker 소켓을 탑재하는 것 자체가 잠재적인 보안 문제이지만 권한 모드를 사용할 필요가 없습니다. 소켓에 대한 액세스 권한이 있는 모든 항목은 Docker 데몬에 지침을 보내 호스트에서 컨테이너를 시작하거나 이미지를 가져오거나 데이터를 삭제할 수 있는 기능을 제공합니다.
각 접근 방식을 사용해야 하는 경우
Docker-in-Docker를 통해 dind 역사적으로 CI 환경에서 널리 사용되었습니다. 이는 “내부” 컨테이너에 호스트와 격리된 레이어가 있음을 의미합니다. 단일 CI 실행기 컨테이너는 호스트의 Docker 데몬을 오염시키지 않고 모든 파이프라인 컨테이너를 지원합니다.
종종 작동하지만 부작용이 있으며 의도된 사용 사례가 아닙니다. dind. 중첩된 Docker 설치에 대한 최종 사용자 지원을 제공하지 않고 Docker 자체의 개발을 용이하게 하기 위해 추가되었습니다.
창시자 Jérôme Petazzoni에 따르면 dind 구현 시 소켓 기반 접근 방식을 채택하는 것이 선호하는 솔루션이어야 합니다. 호스트의 데몬 소켓을 바인딩하는 것이 더 안전하고 유연하며 시작하는 것만큼 기능이 완벽합니다. dind 컨테이너.
사용 사례가 절대적으로 필요한 경우 dind, 배포하는 더 안전한 방법이 있습니다. 최신 Sysbox 프로젝트는 권한 모드를 사용하지 않고 다른 런타임을 중첩할 수 있는 전용 컨테이너 런타임입니다. Sysbox 컨테이너는 VM과 유사해져서 일반적으로 물리적 또는 가상 머신에서 베어 메탈로 실행되는 소프트웨어를 지원할 수 있습니다. 여기에는 특별한 구성이 없는 Docker 및 Kubernetes가 포함됩니다.
결론
Docker 내에서 Docker를 실행하는 것은 비교적 일반적인 요구 사항입니다. 사용자 생성 파이프라인 내에서 컨테이너 이미지 빌드를 지원해야 하는 CI 서버를 설정하는 동안 가장 많이 볼 수 있습니다.
사용 docker:dind 자체 컨테이너 내에서 실행되는 독립 Docker 데몬을 제공합니다. 호스트에서 직접 볼 수 없는 자식 컨테이너를 효과적으로 만듭니다. 강력한 격리를 제공하는 것처럼 보이지만, dind 실제로 많은 엣지 케이스 문제와 보안 문제가 있습니다. 이는 Docker의 운영 체제 상호 작용 때문입니다.
호스트의 Docker 소켓을 다음을 포함하는 컨테이너에 마운트합니다. docker 바이너리는 더 간단하고 예측 가능한 대안입니다. 이렇게 하면 중첩된 Docker 프로세스가 자체 형제가 되는 컨테이너를 시작할 수 있습니다. 소켓 기반 접근 방식을 사용할 때는 추가 설정이 필요하지 않습니다.
