cache: support single manifest cache images
Remote cache handling assumes that every cache image root is either a Docker manifest list or an OCI image index. That is not true for single-platform cache images. A cache image with only one platform can be stored as a normal image manifest, and registries may return application/vnd.oci.image.manifest.v1+json as the resolved root media type.
When such a cache image is used by a later conversion, Fetch rejects the resolved descriptor before importing any cache records. The conversion then fails while updating and pushing the cache with an unsupported media type error, even though the cache manifest itself contains valid Nydus cache layer records.
Accept Docker schema2 manifests and OCI image manifests as cache image roots. Store the fetched manifest in the local content store and import its layer records directly. Share that import path with manifests that are selected from an index so version checks, source digest validation, source descriptor lookup, and cache record population stay consistent between both layouts.
Push the descriptor returned by update instead of always constructing an image index. New single-platform cache images remain image manifests, existing single-manifest cache images are updated in place, and existing index or multi-platform cache images keep the index layout. This keeps the cache image shape aligned with the number of platforms and avoids a synthetic index for the single-manifest case.
Add unit coverage for importing a single-manifest cache image, creating a new single-platform manifest cache, and updating an existing single manifest cache without converting it into an index.
Signed-off-by: Xing Ma maxing.lan@bytedance.com
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
Acceleration Service
Acceleration Service provides a general service to Harbor with the ability to automatically convert user images to accelerated images. When a user does something such as artifact push, Harbor will request the service to complete the corresponding image conversion through its integrated Nydus, eStargz, zstdchunked etc. drivers.
See more details in the design doc.
Quickstart
GETTING STARTED
Get Harbor
Deploy a local harbor service if you don’t have one, please refer to the harbor documentation.
Get binaries from release page
Currently, Acceleration Service includes the following tools:
accelddaemon to work as an HTTP service to handle image conversion requests from harbor oraccelctl.accelctlCLI tool to manage acceleration service (acceld) and can do image conversion in one-time mode.Get
accelctlandacceldbinaries from acceleration-service release.Configuration
Configure Habor
Login to the Harbor web interface.
Select one project and add a new Webhook configuration with the following fields:
<acceleration service address>/api/v1/conversions<configured in acceleration service>Create a system robot account with following fields:
<by your choice>When you get the robot account
robotlt;robot-name>, please copy the secret and generate a base64 encoded auth string like this:Configure Acceleration Service
provider.sourcewith your own harbor service hostname, theauthandwebhook.auth_headershould also be configured as the one generated by the above step.converter.driverfiled according to your requirements.Convert Image with Acceleration Service
Convert by acceld service
accelctlCLI tool. Or you can create a conversion task over the HTTP API bycurl. Please refer to the development document.One-time mode
One-time mode allows to do a conversion without starting the acceld service, using accelctl like this:
Check Converted Image
You can see the converted image and source oci image in the some repo, they have different tag suffix.
Documentation