ใช้ S3 เป็นคอนเทนเนอร์รีจิสทรี

 (ochagavia.nl)
1 คะแนน โดย GN⁺ 2024-07-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การใช้ S3 เป็นคอนเทนเนอร์รีจิสทรี

  • ตลอด 4 เดือนที่ผ่านมาได้ร่วมมือกับ Outerbounds เพื่อพัฒนาตัวสร้างอิมเมจคอนเทนเนอร์แบบคัสตอม
  • พบว่าสามารถใช้ S3 เป็นคอนเทนเนอร์รีจิสทรีได้
  • หากเปิดเผย S3 bucket ผ่าน HTTP และอัปโหลดอิมเมจไปยังพาธที่กำหนด ก็สามารถดึงอิมเมจด้วยคำสั่ง docker pull ได้

เดโม

  • สร้างอิมเมจคอนเทนเนอร์ที่รัน cowsay แล้วอัปโหลดไปยัง S3 bucket
  • ใช้ R2 เพื่อให้ egress ฟรี
  • R2 และ S3 เข้ากันได้ในระดับ API
$ docker run --rm pub-40af5d7df1e0402d9a92b982a6599860.r2.dev/cowsay

ทำไมต้องใช้ S3?

  • โดยปกติจะใช้ DockerHub, GitHub Container Registry, ECR เป็นต้น
  • S3 มีข้อได้เปรียบอย่างมากในด้านความเร็วการอัปโหลด
  • จากการเปรียบเทียบความเร็วอัปโหลดระหว่าง ECR และ S3 พบว่า S3 เร็วได้สูงสุดถึง 8 เท่า

เหตุผลที่ S3 เร็วกว่า

  • S3 สามารถอัปโหลดชังก์ของเลเยอร์เดียวแบบขนานได้
  • ECR ปฏิบัติตาม OCI Distribution Spec จึงต้องอัปโหลดแบบลำดับ
  • ECR ที่ไม่สามารถอัปโหลดแบบขนานได้จึงใช้แบนด์วิดท์ได้ไม่เต็มที่

S3 ไม่ใช่คอนเทนเนอร์รีจิสทรี

  • หากพูดอย่างเคร่งครัด S3 ไม่ใช่คอนเทนเนอร์รีจิสทรี
  • คำสั่ง docker pull จะดาวน์โหลดไฟล์ผ่าน HTTP request
  • หากตั้งค่า S3 bucket อย่างเหมาะสม ก็สามารถใช้เป็นคอนเทนเนอร์รีจิสทรีได้

ข้อควรระวัง

  • วิธีนี้ยังอยู่ในขั้นทดลองอย่างมาก
  • ไม่ได้มีฟีเจอร์ของคอนเทนเนอร์รีจิสทรีแบบเดิมครบถ้วน (เช่น security scanning, access control เป็นต้น)
  • ยังต้องมีการศึกษาเพิ่มเติม

PS. แล้ววาฬล่ะ?

  • เป็นมุกให้ไปดูโลโก้ Docker

สรุปโดย GN⁺

  • บทความนี้อธิบายวิธีใช้ S3 เป็นคอนเทนเนอร์รีจิสทรี
  • สามารถใช้ประโยชน์จากความเร็วการอัปโหลดที่สูงของ S3 ได้
  • ควรระวังเพราะไม่ได้มีฟีเจอร์ของคอนเทนเนอร์รีจิสทรีแบบเดิม
  • เป็นแนวทางที่ยังอยู่ในขั้นทดลองแต่ก็น่าสนใจ
  • โปรเจ็กต์อื่นที่มีฟังก์ชันคล้ายกัน ได้แก่ DockerHub, GitHub Container Registry, ECR เป็นต้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-13
ความเห็นจาก Hacker News

  • มีความเห็นว่าอยากให้สเปก OCI Distribution รองรับไฟล์แบบสแตติก

    • จะทำให้สามารถใช้ HTTP server แบบง่าย ๆ หรือ file protocol ได้โดยตรง
    • เมตาดาต้าทั้งหมดมีอยู่ใน manifest แล้ว
    • Content-Type: octet-stream น่าจะทำงานได้ดี

  • มีความเห็นว่าสเปก OCI Distribution ออกแบบมาได้ไม่ดีนัก

    • การ push เลเยอร์ต้องทำแบบลำดับต่อเนื่อง
    • การอัปโหลดแบบ chunk บน DockerHub และ GHCR ทำงานได้ไม่ถูกต้อง
    • รูปแบบค่าของ Content-Range ไม่ตรงกับรูปแบบ RFC7233
    • พลาดโอกาสในการทำมาตรฐาน pagination ของรายการแท็ก

  • มีข้อมูลว่า Cloudflare ได้โอเพนซอร์สเซิร์ฟเวอร์ container registry ที่ใช้ R2

    • สงสัยว่ามีใครเคยลองใช้บ้างหรือไม่

  • มีความเห็นว่าอยากรู้เหตุผลว่าทำไมในสเปก OCI จึงกำหนดให้การ push เลเยอร์ต้องทำแบบลำดับต่อเนื่อง

    • เนื้อหาของเลเยอร์เดียวต้องถูก push แบบลำดับต่อเนื่อง
    • แต่สามารถ push หลายเลเยอร์แบบขนานกันได้

  • มีความเห็นเกี่ยวกับเหตุผลที่ใช้ Nexus รวมถึงข้อดีข้อเสีย

    • รองรับแพ็กเกจและรีโพซิทอรีได้หลากหลาย
    • การตั้งค่าและการใช้ทรัพยากรค่อนข้างยุ่งยาก
    • คำขอ Docker pull มีเพียงคำขอ HEAD และ GET แบบง่าย ๆ
    • แปลกใจที่ยังขาด container registry ที่เรียบง่ายกว่านี้

  • มีข้อมูลว่า Distribution ของ CNCF รองรับความสามารถในการแบ็กอัป registry จาก S3 ผ่าน URL ที่เซ็นด้วย Cloudfront

  • มีความเห็นว่าน่าเสียดายที่ไม่มีการพูดถึงต้นทุนของ S3 และ R2

  • มีข้อมูลว่า ECR รองรับการอัปโหลด image layer เป็นหลายส่วน

    • API ที่เกี่ยวข้อง:
      • InitiateLayerUpload API: เรียกเมื่อเริ่มอัปโหลดแต่ละ image layer
      • UploadLayerPart API: เรียกเมื่ออัปโหลดแต่ละ chunk ของเลเยอร์ (สูงสุด 20MB)
      • PutImage API: เรียกเมื่อ push image manifest หลังอัปโหลดเลเยอร์เสร็จ
    • จุดที่แปลกคือจำเป็นต้องอัปโหลด layer chunk แบบเข้ารหัส base64

  • มีความไม่พอใจต่อ Registry ของ Docker

  • มีความเห็นว่าไม่เข้าใจเหตุผลในการมี private container registry

    • อาจจะดีกว่าหากเพียงสร้างและจัดการไฟล์ image โดยตรง