Skip to content

[proposal] How to implement image storage for sealer using Skopeo #1940

@jsparter

Description

@jsparter

Issue Description

background:

Now we always pull application images online at build stage, even if there are images in docker-daemon locally. And we pull blobs of images and manage all files by hands which is so inelegant. As #1874 said,we need to load offline images at build stage.

Skopeo is a image transporter, it can transport series of types of image from one to another, and skopeo copy ability can help us to implement load offline images. Skopeo operates on the following image and repository types: containers-storage:docker-referencedir:pathdocker://docker-referencedocker-archive:path[:docker-reference]docker-daemon:docker-referenceoci:path:tag. Skopeo can transport images between any two types above:

skopeo copy containers-storage:docker.io/library/alpine:3.13 docker://sea.hub:5000/library/alpine:3.13
skopeo copy docker-daemon:ubuntu:rolling docker://sea.hub:5000/library/ubuntu:rolling

docker://docker-referencedocker-daemon:docker-reference and oci:path:tag these three image types may match our needs. But, each image type mentioned above has different structure, docker://docker-reference needs there is a registry service running on.

So, there are three solutions tu implement image store i figured:

  1. Running a registry in build stage, and use skopeo copy ability to transport images to registry. It can help us fully make use of Skopeo, and completely offload loading image capability to Skopeo. Obviously, this approach relies on the Docker and registry containers, and brings complexity to the build stage.
  2. Partly make use of skopeo copy to connect docker-daemon and read local images, then still manage all files by hands. It's hard to implement, and still inelegant. In the long run, if the Registry store format changes, our maintenance costs will be high.
  3. Load images to a middle type at build stage using skopeo copy ability, and load middle type image to registry at run stage affter registry is running using skopy copy directly. For example, use oci:path:tag as middle type, so there are two step as follow:
    skopeo copy docker-daemon:docker.io/library/alpine:3.13 oci:$rootfs/ociimages:library/alpine:3.13
    skopeo copy oci:$rootfs/ociimages:library/alpine:3.13 docker://sea.hub:5000/library/alpine:3.13
    
    In this way, we seperate registry and image store, if user want to use their own registry to store image (eg. harbor) in the future, we retain the ability to do that. Additional costs is that we move images twice, making run stage be slower.

Each solution has its inherent weaknesses, and the design needs to determine which one to use, or if there is a better one

Describe what feature you want

Additional context

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureCategory issues or PRs related to feature request

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions