ทำไมนักเทียบท่า in-Docker ถึงไม่ดี?


21

ในเดือนสิงหาคม 2013 Jérôme Petazzoni ได้สร้าง Docker in Docker dindเป็นระยะเวลาสั้น ๆ ทำให้ภาชนะบรรจุ Docker นั้นถูกสร้างขึ้นภายใน Docker Containers การทำงานนี้ได้รับความนิยมอย่างมากทำให้GitHub Repository ของJérômeได้รับดาวนับพันและสามร้อยส้อม

ตั้งแต่วันที่ 1.8 ของ Docker ซึ่งวางจำหน่ายสองปีต่อมาในเดือนสิงหาคม 2558 Docker in Docker ได้รับการสนับสนุนโดยตรงจาก Docker อย่างไรก็ตามการใช้ Docker ใน Docker นั้นมาพร้อมกับคำเตือนดูเหมือนว่าจะเกี่ยวข้องกับโพสต์ของJérôme: การใช้ Docker-in-Docker สำหรับ CI หรือสภาพแวดล้อมการทดสอบของคุณหรือไม่ คิดสองครั้ง ซึ่งมุ่งเน้นไปที่เหตุผลที่นักเทียบท่าใน Docker ไม่ใช่ตัวเลือกที่ยอดเยี่ยมสำหรับการรวมอย่างต่อเนื่อง

ทำไมการใช้งาน Docker ใน Docker จึงถือว่าไม่ดี มันเป็นเพียงแค่กรณีที่หลีกเลี่ยงเต่าตลอดทาง? หรือข้อควรพิจารณาด้านประสิทธิภาพ?

เต่าตลอดทางลง!


ฉันไม่คุ้นเคยกับนักเทียบท่านอกเหนือจากที่ได้อ่านเกี่ยวกับเรื่องนี้ แต่เมื่อคิดถึงมันรู้สึกว่าคุณมีโฮสต์ระบบปฏิบัติการบนฮาร์ดแวร์โฮสต์นั้นโหลดคอนเทนเนอร์จากนั้นโหลดคอนเทนเนอร์นั้นจะโหลดอีกอัน ดูเหมือนว่ามีค่าใช้จ่ายจำนวนมากเนื่องจากแนวคิดนี้คือการปรับใช้รูปภาพ รูปภาพของรูปภาพรูปภาพ ... นอกจากนี้ยังสนใจคำตอบที่แท้จริงของคำถามนี้
ไม่มีการคืนเงินไม่ส่งคืน

คุณกำลังเชื่อมโยงคำตอบกับคำถามของคุณ ... หรือฉันขาดอะไรไป?
AnoE

คำตอบ:


16

ข้อกังวลของการผนวกรวมอย่างต่อเนื่อง

ในระยะสั้น: นักเทียบท่าในนักเทียบท่า (dind) ไม่จัดการการทำงานพร้อมกันได้ดี

เหตุผลที่คุณไม่ควรใช้ dind สำหรับ CI คือเนื่องจาก Docker ได้รับการออกแบบให้มีการเข้าถึงแบบเอกสิทธิ์เฉพาะบุคคลในไดเรกทอรีที่ใช้สำหรับการจัดเก็บ (ปกติ/var/lib/docker) Dind ไม่เคารพสิ่งนี้เนื่องจากกระบวนการลูกทั้งหมดใช้ไดเรกทอรีนี้พร้อมกัน ทุกครั้งที่คุณสร้างใหม่ (จาก CI เป็นต้น) สิ่งที่เกี่ยวข้องกับแอปของคุณในไดเรกทอรีนี้อาจถูกลบออกและถูกบังคับให้เริ่มจากศูนย์ ผู้ใช้ของคุณจะชอบอย่างไรหากพวกเขาป้อนรายละเอียดการชำระเงินคลิก "สั่งซื้อ" และพบว่าพวกเขากลับมาที่หน้าจอเข้าสู่ระบบราวกับว่าพวกเขาไม่เคยทำอะไรเลย? นั่นเป็นเพียงไม่ดี UX มีการสร้างใหม่สองครั้งพร้อมกันหรือไม่ มันจะจบลงอย่างเลวร้ายสำหรับทุกคนที่เกี่ยวข้อง (รวมถึงความถูกต้องของข้อมูล)

ข้อกังวลอื่น ๆ

จากลิงค์ของ OP ที่โพสต์ปัญหาด้านความปลอดภัยเกิดขึ้นเนื่องจากระบบจะพยายามนำนโยบายความปลอดภัยมาใช้ในลักษณะ "คล้าย CSS" โดยที่คอนเทนเนอร์ที่ต่ำกว่าสามารถเข้าถึงทรัพยากรของคอนเทนเนอร์ภายนอกได้ จำไว้ว่าเมื่อใดที่คุณสามารถเข้าถึงทรัพยากรของเว็บเซิร์ฟเวอร์โดยทำเช่น "mywebsite.com/../another_folder/private_resource.txt" นอกจากนี้บางครั้งระบบไฟล์ก็ไม่สามารถเล่นกันได้ดีเมื่อซ้อนกันด้วยวิธีนี้

การแก้ไข

โชคดีที่การโพสต์บล็อกใน OP มีวิธีแก้ปัญหาที่ดี เว้นแต่ว่าคุณจะไม่ได้พบกับ "build / run / push Docker container จากระบบ CI ของคุณเองที่ทำงานบน Docker" คุณสามารถใช้-vโหมด (เพิ่มปริมาณข้อมูลลงในคอนเทนเนอร์ของคุณ) บนซ็อกเก็ต Docker (โดยปกติ/var/run/docker.sock:/var/run/docker.sock) เพื่อให้ชนิดของ การเข้าถึงที่คุณต้องการกับปริมาณข้อมูลที่ "แชร์" คอนเทนเนอร์เหล่านี้จะเริ่มต้นพร้อมกับผู้ปกครองแทนที่จะบังคับให้ซิงโครนัส IO ตอนนี้คุณมีสิ่งเดียวกัน (เกือบ) เป็น dind แต่ไม่มีข้อเสียที่มาพร้อมกับ Docker ที่ไม่ได้ถูกสร้างขึ้นเพื่อการทำงานพร้อมกัน

ข้อมูลอ้างอิง (จาก OP): การใช้ Docker-in-Docker สำหรับ CI หรือสภาพแวดล้อมการทดสอบของคุณหรือไม่ คิดสองครั้ง


นี่คือตัวอย่างหนึ่งของวิธีการอธิบาย (dood) สำหรับเจนกินส์ แต่ยังมีอีกหลายปัญหาที่รายงานขณะใช้งานมันhub.docker.com/r/psharkey/jenkins-dood
rombob

จากคำอธิบายนี้ฉันยังไม่สามารถบอกได้จริง ๆ ว่าควรหลีกเลี่ยงสิ่งสกปรกหรือไม่ในกรณีของฉัน ... ตัวแทนการสร้างของฉันทำงานในคอนเทนเนอร์นักเทียบท่าและทำสิ่งต่อไปนี้: 1. Checkout repo.2. Start container & mount repo.3. Run some build-/test script inside container.ต่อตัวแทนมีเพียงหนึ่งเดียว ' dind'-container กำลังทำงาน ยังมีปัญหากับ dind ในกรณีใช้งานนี้หรือไม่?
helmesjo
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.