- Container registry nhìn bề ngoài có vẻ đơn giản, nhưng để debug các vấn đề như tag sai, lệch nền tảng, thiếu layer, hoặc xóa không thành công trên thực tế thì bắt buộc phải hiểu cơ chế hoạt động bên trong
- Cốt lõi của registry là kho lưu trữ blob theo cơ chế định địa chỉ bằng nội dung (content-addressable), nơi mọi layer, file cấu hình và artifact đều được lưu với digest làm địa chỉ
- Quá trình push image diễn ra theo thứ tự upload blob rồi gói lại bằng manifest, còn pull thì theo cấu trúc ngược lại: lấy manifest trước rồi tải các blob xuống tuần tự
- Xóa image không thể loại bỏ hoàn toàn chỉ bằng untag; cần kiểm tra trước các layer đang được manifest khác dùng chung rồi mới trực tiếp xóa đến mức blob
- Image đa nền tảng được triển khai bằng cách chỉ thêm một lớp gián tiếp là image index (manifest list), trong khi vẫn giữ nguyên các API endpoint hiện có
Tổng quan Registry API
- Phần lớn container registry hiện đại triển khai OCI Distribution Specification, là đặc tả định nghĩa giao thức API để chuẩn hóa việc phân phối nội dung
- Registry API thực tế khá gọn và dễ hiểu, thậm chí có thể thao tác trực tiếp chỉ với
curl
Upload và download blob
- Registry về bản chất là kho blob định địa chỉ theo nội dung: file được hash ở máy cục bộ trước, rồi upload với digest làm địa chỉ
- Cách upload đơn giản nhất là Monolithic PUT, gồm 2 bước: khởi tạo session bằng
POST, sau đó gửi blob bằng PUT
- Với file lớn, cách upload theo chunk bằng
POST + PATCH + PUT hiệu quả hơn, nhưng với blob nhỏ thì Monolithic PUT là đủ
- Khi upload thành công, sẽ nhận phản hồi
HTTP/2 201 Created cùng header Location trỏ đến vị trí của blob mới
- Việc download có thể thực hiện trực tiếp nếu biết digest, qua
GET /v2/<repo>/blobs/<digest>
Push image
- Quy trình push image: (1) upload blob của từng rootfs layer → (2) upload blob image configuration → (3) push file manifest gói toàn bộ digest vào một tài liệu JSON
- Manifest được upload qua endpoint
PUT /v2/<repo>/manifests/<tag>, và tag được tạo ở thời điểm này
- Client thực tế (ví dụ
docker push) thường upload blob song song, nhưng để hiểu nguyên lý thì cũng có thể xử lý tuần tự
- Ví dụ cấu trúc thư mục image:
config.json, layer-1.tar.gz, layer-2.tar.gz, manifest.json
Liệt kê danh sách tag
- Có thể truy vấn toàn bộ danh sách tag của một repository cụ thể qua endpoint
GET /v2/<repo>/tags/list
- Tính năng này không được lộ ra trong CLI
docker, mà chỉ có thể truy cập bằng curl hoặc các công cụ như crane, regctl
crane, regctl thực chất là bọc cùng endpoint này dưới lệnh ls
Pull image
- Quy trình pull là đảo ngược của push: (1) truy vấn manifest bằng
GET /v2/<repo>/manifests/<tag> → (2) download toàn bộ blob theo các digest được chỉ ra trong manifest
- Manifest hiện đại ngoài rootfs layer và cấu hình image còn được dùng như một kho lưu trữ tổng quát để tham chiếu blob của các artifact tùy ý như Helm chart, SBOM, provenance attestation, trọng số LLM
Xóa image
- Xóa image không hề đơn giản, và chỉ xóa tag (untag) thì không đồng nghĩa manifest đã bị xóa
- Quy trình xóa hoàn toàn:
- (1) xóa tag bằng
DELETE /v2/<repo>/manifests/<tag>
- (2) truy vấn manifest theo digest để kiểm tra mọi blob đang được tham chiếu
- (3) chỉ chọn xóa những blob không bị manifest khác dùng chung
- (4) xóa manifest blob bằng
DELETE /v2/<repo>/blobs/<manifest-digest>
- Vì registry là kho lưu trữ định địa chỉ theo nội dung, nhiều image có thể dùng chung cùng một rootfs layer; do đó khi xóa có thể ảnh hưởng đến mọi image đang tham chiếu layer đó
- Một cách khác là xóa toàn bộ tag rồi dựa vào cấu hình garbage collection của registry, nhưng với registry công cộng thì tính năng này không phải lúc nào cũng được bật
Image đa nền tảng
- Image đa nền tảng được triển khai mà không cần thay đổi cấu trúc Registry API — không thêm hay sửa endpoint nào, chỉ tận dụng nguyên API hiện có
- Cách tổ chức:
- Trước hết push từng biến thể nền tảng đơn lẻ (amd64, arm64...) dưới dạng digest-based cùng manifest riêng
- Sau đó push manifest cấp trên gọi là image index (manifest list) kèm tag
- Khi gọi
GET /v2/<repo>/manifests/<tag>, kết quả trả về sẽ là một manifest đơn nền tảng hoặc image index; bên gọi phải phân biệt bằng content type của tài liệu nhận được
- Kết quả là hỗ trợ đa nền tảng chỉ bổ sung cho cấu trúc sẵn có một lớp gián tiếp và một bước upload/download tài liệu index
Bảo vệ Registry API
- OCI Distribution Spec không quy định chặt chẽ cơ chế xác thực, nhưng phần lớn registry ngoài thực tế dùng HTTP Basic authentication
- Để ngăn thông tin xác thực bị gửi dưới dạng văn bản thuần, bắt buộc phải vận hành trên HTTPS
Chưa có bình luận nào.