Tại sao Docker-in-Docker bị coi là xấu?


21

Vào tháng 8 năm 2013, Jérôme Petazzoni đã tạo Docker trong Docker, nói dindngắn gọn, điều này cho phép các container Docker được tạo bên trong Docker Container, chức năng này đã được chứng minh rất phổ biến dẫn đến Kho lưu trữ GitHub của Jérôme nhận được hơn một nghìn sao và ba trăm dĩa.

Kể từ Docker 1.8, được phát hành hai năm sau đó vào tháng 8 năm 2015, Docker trong Docker được Docker hỗ trợ trực tiếp ra khỏi hộp. Tuy nhiên, việc sử dụng Docker trong Docker đi kèm với một cảnh báo, dường như có liên quan đến Bài đăng của Jérôme: Sử dụng Docker-in-Docker cho CI hoặc môi trường thử nghiệm của bạn? Nghĩ cho kỹ. trong đó tập trung vào các lý do tại sao Docker trong Docker không phải là một lựa chọn tuyệt vời cho Tích hợp liên tục.

Tại sao nó được coi là xấu khi sử dụng Docker trong Docker? Có phải nó chỉ đơn giản là một trường hợp để tránh Rùa hết cỡ? hoặc cân nhắc hiệu suất?

Những con rùa đều lặn xuống dưới!


Tôi không quen thuộc với docker ngoài việc đọc về nó. Nhưng nghĩ về nó, có cảm giác như bạn có hệ điều hành máy chủ trên phần cứng, máy chủ đó tải một container, sau đó container đó tải một cái khác. Có vẻ như rất nhiều chi phí cho rằng ý tưởng là để triển khai một hình ảnh. Một hình ảnh của một hình ảnh của một hình ảnh ... Cũng quan tâm đến câu trả lời thực tế cho q này.
Không hoàn lại tiền Không trả lại

Bạn đang liên kết câu trả lời cho câu hỏi của bạn ... hoặc tôi đang thiếu một cái gì đó?
AnoE

Câu trả lời:


16

Mối quan tâm tích hợp liên tục

Nói tóm lại: Docker trong Docker (dind) không xử lý đồng thời tốt.

Lý do tại sao bạn không nên sử dụng dind cho CI là vì Docker được thiết kế để có quyền truy cập độc quyền vào thư mục mà nó sử dụng để lưu trữ (thông thường /var/lib/docker). Dind không tôn trọng điều này vì tất cả các tiến trình con sử dụng đồng thời thư mục này. Mỗi khi bạn xây dựng lại (từ CI chẳng hạn), mọi thứ liên quan đến ứng dụng của bạn trong thư mục này có thể bị xóa sổ và buộc phải bắt đầu từ con số không. Người dùng của bạn sẽ thích nó như thế nào nếu họ nhập chi tiết thanh toán, nhấp vào "Mua hàng" và đột nhiên thấy họ quay lại màn hình đăng nhập như thể họ chưa bao giờ làm gì? Đó chỉ là UX không tốt. Hai lần xây dựng lại xảy ra cùng một lúc? Điều đó thực sự sẽ kết thúc tồi tệ cho mọi người liên quan (bao gồm cả tính toàn vẹn dữ liệu của bạn).

Mối quan tâm khác

Từ liên kết mà OP đăng tải, các mối lo ngại về bảo mật xuất hiện khi hệ thống sẽ cố gắng áp dụng các chính sách bảo mật theo kiểu rất "giống CSS", nơi một container thấp hơn có thể có quyền truy cập vào tài nguyên của bên ngoài trừ khi bị cấm rõ ràng. Hãy nhớ khi nào bạn có thể truy cập tài nguyên máy chủ web bằng cách thực hiện một cái gì đó như "mywebsite.com/../another_folder/private_resource.txt"? Ngoài ra, đôi khi các hệ thống tệp chỉ không chơi tốt với nhau khi chúng được lồng theo cách này.

Sửa chữa

Rất may, bài đăng blog trong OP có một giải pháp tốt cho vấn đề này. Trừ khi nhu cầu của bạn không được đáp ứng bởi "xây dựng / chạy / đẩy các thùng chứa Docker từ chính hệ thống CI của bạn đang chạy trên Docker", bạn có thể sử dụng -vchế độ (thêm một khối lượng dữ liệu vào thùng chứa của bạn) trên ổ cắm Docker (thường /var/run/docker.sock:/var/run/docker.sock) để cho phép loại truy cập bạn cần vào khối lượng dữ liệu "chia sẻ". Các thùng chứa này sẽ được bắt đầu cùng với cha mẹ, thay vì bên dưới, buộc IO đồng bộ. Bây giờ bạn có điều tương tự (gần như) như dind nhưng không có nhược điểm đi kèm với Docker không được xây dựng để tương tranh.

Tham khảo (từ OP): Sử dụng Docker-in-Docker cho CI hoặc môi trường thử nghiệm của bạn? Nghĩ cho kỹ.


Đây là một ví dụ về cách tiếp cận được mô tả ( vẽ nguệch ngoạc
rombob

Từ lời giải thích này, tôi vẫn không thể thực sự biết liệu có nên tránh dind trong trường hợp của mình không ... Tác nhân xây dựng của tôi chạy trong một container docker và thực hiện như sau: 1. Checkout repo.2. Start container & mount repo.3. Run some build-/test script inside container.Mỗi tác nhân, chỉ có một ' dind'-container đang chạy. Vẫn còn vấn đề với dind trong trường hợp sử dụng này?
helmesjo
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.