CI 또는 테스트 환경에 Docker-in-Docker를 사용하기 전에 신중하게 생각하십시오.

Docker-in-Docker는 컨테이너 이미지를 빌드하기 위해 컨테이너 자체 내에서 실행되는 가상화된 Docker 데몬 환경입니다. Docker-in-Docker를 만드는 주요 목적은 Docker 자체 개발을 돕는 것이었습니다. 많은 사람들이 이를 사용하여 Jenkins CI를 실행합니다. 처음에는 이것이 정상적인 것처럼 보이지만 Jenkins CI 컨테이너에 Docker를 설치하면 피할 수 있는 문제가 발생합니다. 이 기사에서는 이를 수행하는 방법을 설명합니다. 세부 사항 없이 최종 해결 방법에 관심이 있다면 기사의 마지막 섹션인 "문제 해결"을 읽어 보십시오.

Docker-in-Docker: "좋음"

XNUMX년여 전에 저는 Docker를 사용했습니다. 플래그 –특권을 갖고 글을 썼다 DIND의 첫 번째 버전. 목표는 핵심 팀이 Docker를 더 빠르게 개발하도록 돕는 것이었습니다. Docker-in-Docker 이전의 일반적인 개발 주기는 다음과 같았습니다.

• 해킹 해킹;
• 짓다;
• 실행 중인 Docker 데몬을 중지합니다.
• 새로운 Docker 데몬을 시작합니다.
• 테스트;
• 사이클을 반복하십시오.

아름답고 재현 가능한 어셈블리(즉, 컨테이너 내)를 만들고 싶다면 다음과 같이 더욱 복잡해집니다.

• 해킹 해킹;
• Docker의 작동 버전이 실행 중인지 확인하세요.
• 기존 Docker로 새 Docker를 빌드합니다.
• Docker 데몬을 중지합니다.
• 새로운 Docker 데몬을 시작하십시오.
• 시험;
• 새 Docker 데몬을 중지합니다.
• 반복.

Docker-in-Docker의 출현으로 프로세스가 더욱 단순해졌습니다.

• 해킹 해킹;
• 한 단계에서 조립 + 출시;
• 사이클을 반복하십시오.

이 방법이 훨씬 낫지 않나요?

Docker-in-Docker: "나쁨"

그러나 대중의 믿음과는 달리 Docker-in-Docker는 100% 스타, 조랑말, 유니콘이 아닙니다. 내 말은 개발자가 알아야 할 몇 가지 문제가 있다는 것입니다.

그 중 하나는 AppArmor 및 SELinux와 같은 LSM(Linux 보안 모듈)과 관련이 있습니다. 컨테이너를 실행할 때 "내부 Docker"는 "외부 Docker"와 충돌하거나 혼동하는 보안 프로필을 적용하려고 시도할 수 있습니다. 이는 –privileged 플래그의 원래 구현을 병합하려고 할 때 해결하기 가장 어려운 문제입니다. 내 변경 사항은 효과가 있었고 모든 테스트는 Debian 시스템과 Ubuntu 테스트 VM에서 통과했지만 Michael Crosby의 시스템에서는 충돌이 발생하고 화상을 입었습니다(제가 기억하기로 그는 Fedora를 사용했습니다). 문제의 정확한 원인은 기억나지 않지만 Mike가 SELINUX=enforce(저는 AppArmor를 사용했습니다)로 작업하는 현명한 사람이고 변경 사항에서 SELinux 프로필을 고려하지 않았기 때문일 수 있습니다.

Docker-in-Docker: "악"

두 번째 문제는 Docker 스토리지 드라이버와 관련이 있습니다. Docker-in-Docker를 실행하면 외부 Docker는 일반 파일 시스템(EXT4, BTRFS 또는 기타 모든 것) 위에서 실행되고 내부 Docker는 쓰기 중 복사 시스템(AUFS, BTRFS, Device Mapper) 위에서 실행됩니다. 등). , 외부 Docker를 사용하도록 구성된 항목에 따라). 이로 인해 작동하지 않는 많은 조합이 만들어집니다. 예를 들어, AUFS 위에서 AUFS를 실행할 수 없습니다.

BTRFS 위에서 BTRFS를 실행하면 처음에는 작동하지만 중첩된 하위 볼륨이 있으면 상위 하위 볼륨 삭제가 실패합니다. Device Mapper 모듈에는 네임스페이스가 없으므로 여러 Docker 인스턴스가 동일한 시스템에서 실행되는 경우 모두 서로 및 컨테이너 백업 장치의 이미지를 보고 영향을 미칠 수 있습니다. 이것은 나쁘다.

이러한 많은 문제를 해결할 수 있는 해결 방법이 있습니다. 예를 들어 내부 Docker에서 AUFS를 사용하려면 /var/lib/docker 폴더를 볼륨으로 바꾸면 됩니다. Docker는 여러 Docker 호출이 동일한 시스템에서 실행되는 경우 서로 밟지 않도록 Device Mapper 대상 이름에 일부 기본 네임스페이스를 추가했습니다.

그러나 이러한 설정은 다음에서 볼 수 있듯이 전혀 간단하지 않습니다. 조항 GitHub의 DIND 저장소에 있습니다.

Docker-in-Docker: 상황이 더욱 악화됨

빌드 캐시는 어떻습니까? 이것도 상당히 어려울 수 있습니다. 사람들은 종종 "Docker-in-Docker를 실행하는 경우 모든 것을 내부 Docker로 가져오는 대신 호스트에 호스팅된 이미지를 어떻게 사용할 수 있습니까?"라고 묻습니다.

일부 진취적인 사람들은 호스트의 /var/lib/docker를 Docker-in-Docker 컨테이너에 바인딩하려고 시도했습니다. 때로는 여러 컨테이너와 /var/lib/docker를 공유합니다.

데이터를 손상시키고 싶나요? 이것이 바로 데이터를 손상시키는 것이기 때문입니다!

Docker 데몬은 /var/lib/docker에 독점적으로 액세스할 수 있도록 설계되었습니다. 이 폴더에 있는 Docker 파일을 "만지거나 찌르거나 자극"해서는 안 됩니다.

왜 그럴까요? 이는 dotCloud를 개발하면서 배운 가장 어려운 교훈 중 하나의 결과이기 때문입니다. dotCloud 컨테이너 엔진은 여러 프로세스가 /var/lib/dotcloud에 동시에 액세스하도록 하여 실행되었습니다. 원자 파일 교체(내부 편집 대신), 권고 및 필수 잠금이 포함된 코드 추가, SQLite 및 BDB와 같은 보안 시스템을 사용한 기타 실험과 같은 교묘한 트릭이 항상 작동하는 것은 아닙니다. 결국 Docker가 된 컨테이너 엔진을 재설계할 때 중요한 설계 결정 중 하나는 모든 컨테이너 작업을 단일 데몬으로 통합하여 모든 동시성 문제를 없애는 것이었습니다.

오해하지 마십시오. 여러 프로세스와 현대적인 병렬 제어를 포함하여 훌륭하고 안정적이며 빠른 것을 만드는 것은 전적으로 가능합니다. 하지만 우리는 Docker를 유일한 플레이어로 사용하여 코드를 작성하고 유지하는 것이 더 간단하고 쉽다고 생각합니다.

즉, 여러 Docker 인스턴스 간에 /var/lib/docker 디렉터리를 공유하면 문제가 발생합니다. 물론 이는 특히 테스트 초기 단계에서 효과가 있을 수 있습니다. “엄마, 들어보세요. 저는 도커로 우분투를 실행할 수 있어요!” 하지만 두 개의 서로 다른 인스턴스에서 동일한 이미지를 가져오는 등 좀 더 복잡한 작업을 시도하면 세상이 불타는 것을 보게 될 것입니다.

즉, CI 시스템이 빌드 및 재구축을 수행하는 경우 Docker-in-Docker 컨테이너를 다시 시작할 때마다 핵이 캐시에 떨어질 위험이 있습니다. 이건 전혀 멋지지 않아요!

솔루션

한발 뒤로 물러나 보자. Docker-in-Docker가 정말로 필요합니까, 아니면 CI 시스템 자체가 컨테이너에 있는 동안 Docker를 실행하고 CI 시스템에서 컨테이너와 이미지를 빌드하고 실행할 수 있기를 원하십니까?

대부분의 사람들은 후자의 옵션을 원할 것입니다. 즉, Jenkins와 같은 CI 시스템이 컨테이너를 실행할 수 있기를 원한다는 의미입니다. 가장 쉬운 방법은 Docker 소켓을 CI 컨테이너에 삽입하고 -v 플래그와 연결하는 것입니다.

간단히 말해서 CI 컨테이너(Jenkins 또는 기타)를 실행할 때 Docker-in-Docker와 함께 무언가를 해킹하는 대신 다음 줄로 시작하십시오.

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

이제 이 컨테이너는 Docker 소켓에 액세스할 수 있으므로 컨테이너를 실행할 수 있습니다. 단, "하위" 컨테이너를 실행하는 대신 "형제" 컨테이너를 실행합니다.

공식 Docker 이미지(Docker 바이너리가 포함되어 있음)를 사용하여 이를 시도해 보세요.

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

Docker-in-Docker처럼 보이고 작동하지만 Docker-in-Docker는 아닙니다. 이 컨테이너가 추가 컨테이너를 생성하면 최상위 Docker에 생성됩니다. 중첩으로 인한 부작용이 발생하지 않으며 어셈블리 캐시가 여러 호출에서 공유됩니다.

참고: 이 문서의 이전 버전에서는 Docker 바이너리를 호스트에서 컨테이너로 연결하는 것을 권장했습니다. Docker 엔진이 더 이상 정적 또는 거의 정적 라이브러리를 다루지 않기 때문에 이는 이제 신뢰할 수 없게 되었습니다.

따라서 Jenkins CI에서 Docker를 사용하려면 다음 두 가지 옵션이 있습니다.
Docker API를 사용하여 기본 이미지 패키징 시스템(예: 이미지가 Debian 기반인 경우 .deb 패키지 사용)을 사용하여 Docker CLI를 설치합니다.

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com