Sử dụng S3 làm container registry

Sử dụng S3 làm container registry

• Trong 4 tháng qua, tác giả đã hợp tác với Outerbounds để phát triển một trình xây dựng image container tùy chỉnh
• Đã phát hiện ra rằng có thể dùng S3 làm container registry
• Nếu public bucket S3 qua HTTP và tải image lên một đường dẫn cụ thể, có thể kéo image bằng lệnh docker pull

Demo

• Đã tạo một container image chạy cowsay và tải nó lên bucket S3
• Sử dụng R2 để cung cấp egress miễn phí
• R2 và S3 tương thích API với nhau

$ docker run --rm pub-40af5d7df1e0402d9a92b982a6599860.r2.dev/cowsay

Tại sao dùng S3?

• Theo truyền thống, người ta dùng DockerHub, GitHub Container Registry, ECR, v.v.
• S3 có lợi thế lớn về tốc độ upload
• Kết quả so sánh tốc độ upload giữa ECR và S3 cho thấy S3 nhanh hơn tới 8 lần

Vì sao S3 nhanh hơn

• S3 có thể upload song song các chunk của một layer đơn lẻ
• ECR tuân theo OCI Distribution Spec nên phải upload tuần tự
• Vì không thể upload song song, ECR không tận dụng được đầy đủ băng thông

S3 không phải là container registry

• Nói một cách chặt chẽ, S3 không phải là container registry
• Lệnh docker pull tải file thông qua các yêu cầu HTTP
• Nếu cấu hình bucket S3 phù hợp, có thể dùng nó như một container registry

Lưu ý

• Cách này vẫn còn rất mang tính thử nghiệm
• Nó không cung cấp các tính năng của container registry hiện có (ví dụ: quét bảo mật, kiểm soát truy cập, v.v.)
• Cần nghiên cứu thêm

PS. Còn con cá voi thì sao?

• Đây là một câu đùa ám chỉ logo Docker

Tổng hợp của GN⁺

• Bài viết này giải thích cách sử dụng S3 làm container registry
• Có thể tận dụng tốc độ upload nhanh của S3
• Cần lưu ý vì nó không cung cấp các tính năng của container registry hiện có
• Đây là một cách tiếp cận mang tính thử nghiệm nhưng thú vị
• Các dịch vụ khác cung cấp chức năng tương tự gồm DockerHub, GitHub Container Registry và ECR

[GN⁺]

Ý kiến Hacker News

• Có ý kiến cho rằng sẽ tốt hơn nếu đặc tả OCI Distribution hỗ trợ các tệp tĩnh

  • Khi đó có thể dùng trực tiếp máy chủ HTTP đơn giản hoặc giao thức tệp
  • Toàn bộ siêu dữ liệu đã có sẵn trong manifest
  • Content-Type: octet-stream có thể hoạt động tốt

• Có ý kiến cho rằng đặc tả OCI Distribution được thiết kế chưa tốt

  • Việc push layer phải được thực hiện tuần tự
  • Tải lên theo từng chunk không hoạt động đúng trên DockerHub và GHCR
  • Định dạng giá trị Content-Range không khớp với định dạng RFC7233
  • Đã bỏ lỡ cơ hội chuẩn hóa phân trang cho danh sách tag

• Có thông tin rằng Cloudflare đã mã nguồn mở một máy chủ container registry dùng R2

  • Họ thắc mắc không biết đã có ai dùng thử chưa

• Có ý kiến muốn biết vì sao trong đặc tả OCI, việc push layer phải diễn ra tuần tự

  • Nội dung của một layer đơn lẻ phải được push theo thứ tự tuần tự
  • Nhưng vẫn có thể push nhiều layer song song

• Có ý kiến về lý do sử dụng Nexus và các ưu, nhược điểm của nó

  • Hỗ trợ nhiều loại package và repository khác nhau
  • Việc cấu hình và mức sử dụng tài nguyên khá phiền phức
  • Yêu cầu Docker pull chỉ gồm các yêu cầu HEAD và GET đơn giản
  • Họ ngạc nhiên vì thiếu những container registry đơn giản hơn

• Có thông tin rằng Distribution của CNCF hỗ trợ sao lưu registry trên S3 thông qua URL ký bằng Cloudfront

• Có ý kiến cho rằng thật tiếc vì không có đề cập nào đến chi phí của S3 và R2

• Có thông tin rằng ECR hỗ trợ tải lên image layer thành nhiều phần

  • API liên quan:
    • InitiateLayerUpload API: được gọi khi bắt đầu tải lên từng image layer
    • UploadLayerPart API: được gọi khi tải lên từng chunk của layer (tối đa 20MB)
    • PutImage API: được gọi khi push image manifest sau khi tải xong layer
  • Việc phải tải lên chunk của layer bằng mã hóa base64 là một điểm khá lạ

• Có phàn nàn về Docker Registry

• Có ý kiến nói rằng họ không hiểu lý do tồn tại của container registry cá nhân

  • Có thể chỉ cần tạo và quản lý các tệp image thì sẽ tốt hơn