-
Notifications
You must be signed in to change notification settings - Fork 361
Description
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-reference、dir:path、docker://docker-reference、docker-archive:path[:docker-reference]、docker-daemon:docker-reference、oci: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-reference、 docker-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:
- Running a registry in build stage, and use
skopeo copyability 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. - Partly make use of
skopeo copyto 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. - Load images to a middle type at build stage using
skopeo copyability, and load middle type image to registry at run stage affter registry is running usingskopy copydirectly. For example, useoci:path:tagas middle type, so there are two step as follow: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.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
Each solution has its inherent weaknesses, and the design needs to determine which one to use, or if there is a better one