ธุรกิจ Docker ปรับขนาดเพื่อรองรับนักพัฒนาหลายล้านคนได้อย่างไร ตอนที่ 2: ข้อมูลขาออก

นี่เป็นบทความที่สองในชุดบทความที่จะครอบคลุมข้อจำกัดเมื่อดาวน์โหลดอิมเมจคอนเทนเนอร์

В ส่วนแรก เราได้ตรวจสอบภาพที่จัดเก็บไว้ใน Docker Hub ซึ่งเป็นรีจิสตรีที่ใหญ่ที่สุดสำหรับคอนเทนเนอร์อิมเมจ เรากำลังเขียนสิ่งนี้เพื่อช่วยให้คุณเข้าใจได้ดีขึ้นว่าข้อกำหนดในการให้บริการที่อัปเดตของเราจะส่งผลกระทบต่อทีมพัฒนาที่ใช้ Docker Hub ในการจัดการคอนเทนเนอร์อิมเมจและไปป์ไลน์ CICD อย่างไร

ก่อนหน้านี้มีการประกาศขีดจำกัดความถี่ในการดาวน์โหลดในของเรา เงื่อนไขการให้บริการ. เรามาดูรายละเอียดเกี่ยวกับขีดจำกัดความถี่ที่จะมีผลบังคับใช้ในวันที่ 1 พฤศจิกายน 2020:

แผนฟรี ผู้ใช้นิรนาม: 100 ดาวน์โหลดใน 6 ชั่วโมง
แผนฟรี ผู้ใช้ที่ได้รับอนุญาต: 200 ดาวน์โหลดใน 6 ชั่วโมง
แผน Pro: ไม่จำกัด
แผนทีม: ไม่จำกัด

ความถี่ในการดาวน์โหลด Docker ถูกกำหนดเป็นจำนวนคำขอรายการไปยัง Docker Hub ขีดจำกัดความถี่ในการดาวน์โหลดรูปภาพขึ้นอยู่กับประเภทของบัญชีที่ขอรูปภาพ ไม่ใช่ประเภทของบัญชีเจ้าของรูปภาพ สำหรับผู้ใช้ที่ไม่ระบุชื่อ (ไม่ได้รับอนุญาต) ความถี่ในการดาวน์โหลดจะเชื่อมโยงกับที่อยู่ IP

NB คุณจะได้รับรายละเอียดเพิ่มเติมและกรณีปฏิบัติที่ดีที่สุด ในหลักสูตรนักเทียบท่าจากผู้ปฏิบัติงาน. ยิ่งกว่านั้นคุณสามารถดำเนินการได้เมื่อสะดวกสำหรับคุณ - ทั้งในเวลาและอารมณ์

เราได้รับคำถามจากลูกค้าและชุมชนเกี่ยวกับเลเยอร์อิมเมจคอนเทนเนอร์ เราไม่พิจารณาเลเยอร์รูปภาพเมื่อจำกัดความถี่ในการดาวน์โหลด เนื่องจากเราจำกัดการดาวน์โหลดรายการ และจำนวนเลเยอร์ (คำขอ Blob) ในปัจจุบันก็ไม่จำกัด การเปลี่ยนแปลงนี้ขึ้นอยู่กับความคิดเห็นของชุมชนเพื่อให้เป็นมิตรกับผู้ใช้มากขึ้น ผู้ใช้จึงไม่ต้องนับเลเยอร์ในทุกรูปลักษณ์ที่ใช้

การวิเคราะห์โดยละเอียดของความถี่การดาวน์โหลดอิมเมจของ Docker Hub

เราใช้เวลามากมายในการวิเคราะห์การดาวน์โหลดรูปภาพจาก Docker Hub เพื่อระบุสาเหตุของการจำกัดความเร็ว ตลอดจนวิธีการจำกัด สิ่งที่เราเห็นยืนยันว่าผู้ใช้เกือบทั้งหมดกำลังดาวน์โหลดรูปภาพในอัตราที่คาดเดาได้สำหรับเวิร์กโฟลว์ทั่วไป อย่างไรก็ตาม มีอิทธิพลที่เห็นได้ชัดเจนจากผู้ใช้ที่ไม่ระบุตัวตนจำนวนเล็กน้อย เช่น ประมาณ 30% ของการดาวน์โหลดทั้งหมดมาจากผู้ใช้ที่ไม่ระบุตัวตนเพียง 1%

ขีดจำกัดใหม่ขึ้นอยู่กับการวิเคราะห์นี้ ดังนั้นผู้ใช้ส่วนใหญ่ของเราจะไม่ได้รับผลกระทบ ขีดจำกัดเหล่านี้สร้างขึ้นเพื่อสะท้อนถึงการใช้งานตามปกติของนักพัฒนา เช่น การเรียนรู้ Docker, การพัฒนาโค้ด, การสร้างอิมเมจ และอื่นๆ

ช่วยให้นักพัฒนาเข้าใจขีดจำกัดความถี่ในการดาวน์โหลดได้ดียิ่งขึ้น

ตอนนี้เราเข้าใจผลกระทบและขอบเขตที่ควรจะเป็นแล้ว เราต้องกำหนดเงื่อนไขทางเทคนิคสำหรับการดำเนินการของข้อจำกัดเหล่านี้ การจำกัดการดาวน์โหลดรูปภาพจาก Registry Docker นั้นค่อนข้างยาก คุณจะไม่พบ API สำหรับการดาวน์โหลดในคำอธิบายรีจิสทรี - ไม่มีอยู่จริง จริง ๆ แล้ว การดาวน์โหลดรูปภาพเป็นการรวมกันของคำขอรายการและ Blob ใน API และดำเนินการต่างกันออกไปขึ้นอยู่กับสถานะของ ลูกค้าและภาพที่ร้องขอ

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

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

ปรากฎว่าการดาวน์โหลดรูปภาพเป็นคำขอรายการหนึ่งหรือสองรายการรวมถึงจากศูนย์ถึงไม่มีที่สิ้นสุด - คำขอสำหรับเลเยอร์ (หยด) ในอดีต Docker ได้ติดตามความถี่ในการดาวน์โหลดเป็นชั้นต่อชั้น เนื่องจากสิ่งนี้เกี่ยวข้องกับการใช้แบนด์วิธมากที่สุด แต่อย่างไรก็ตาม เรารับฟังชุมชนซึ่งยากกว่า เพราะคุณต้องติดตามจำนวนเลเยอร์ที่ร้องขอ ซึ่งจะนำไปสู่การเพิกเฉยต่อแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับการทำงานกับ Dockerfile และยังใช้งานง่ายกว่าสำหรับผู้ใช้ที่ต้องการเพียงแค่ ทำงานกับรีจิสทรีโดยไม่เข้าใจรายละเอียดมากนัก

ดังนั้นเราจึงจำกัดจำนวนคำขอตามคำขอรายการ สิ่งนี้เกี่ยวข้องโดยตรงกับการดาวน์โหลดรูปภาพซึ่งผู้ใช้เข้าใจได้ง่าย มีข้อแม้เล็กน้อยจริงๆ - หากคุณพยายามดาวน์โหลดภาพที่มีอยู่แล้ว คำขอจะยังคงถูกนำมาพิจารณา แม้ว่าคุณจะไม่ได้ดาวน์โหลดเลเยอร์ก็ตาม ไม่ว่าในกรณีใด เราหวังว่าวิธีการจำกัดความถี่ของการดาวน์โหลดนี้จะยุติธรรมและเป็นมิตรกับผู้ใช้

รอคอยที่จะแสดงความคิดเห็นของคุณ

เราจะตรวจสอบข้อจำกัดและทำการปรับเปลี่ยนอย่างเหมาะสมตามกรณีการใช้งานทั่วไป เพื่อให้แน่ใจว่าข้อจำกัดนั้นเหมาะสมกับผู้ใช้แต่ละประเภท และโดยเฉพาะอย่างยิ่ง เราจะพยายามไม่ขัดขวางนักพัฒนาจากการทำงานของตน

โปรดติดตามในอีกไม่กี่สัปดาห์ข้างหน้าสำหรับบทความอื่นเกี่ยวกับการปรับแต่ง CI และระบบการต่อสู้ในแง่ของการเปลี่ยนแปลงเหล่านี้

สุดท้ายนี้ ในฐานะส่วนหนึ่งของการสนับสนุนชุมชนโอเพ่นซอร์ส เราจะนำเสนอแผนการกำหนดราคาใหม่สำหรับโอเพ่นซอร์สจนถึงวันที่ 1 พฤศจิกายน หากต้องการสมัคร โปรดกรอกแบบฟอร์ม ที่นี่.

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงข้อกำหนดในการให้บริการล่าสุด โปรดไปที่ คำถามที่พบบ่อย.

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

ที่มา: will.com