uber-archive / makisu

Fast and flexible Docker image building tool, works in unprivileged containerized environments like Mesos and Kubernetes.
Apache License 2.0
2.41k stars 156 forks source link

Network access to registry required during build to retrieve manifests #355

Open bburky opened 3 years ago

bburky commented 3 years ago

I noticed that makisu does save all manifests to disk, but when building never loads them during image pull. This causes the build step to always need internet access to reach out to the registry for the manifest, even if all the layers and manifests are cached in makisu-storage.

A three line patch is almost enough to support this:

 func (c DockerRegistryClient) PullManifest(tag string) (*image.DistributionManifest, error) {
+    if manifest, err := c.loadManifest(tag); err == nil {
+            return manifest, nil
+    }

This almost works, but the base64 encoded manifest names don't include the registry (they're only library/busybox:latest not index.docker.io/library/busybox:latest). This means that if an image registry.example.com/library/busybox:latest was already pulled it would get used instead of the docker.io image. Currently the manifest files don't include the registry name anywhere.

Is this a feature you would be interested in supporting? It wouldn't be too complicated to write out a duplicate manifest on disk with a name that includes the registry name.

The following is a sketch of the behavior I was hoping would work:

mkdir makisu-storage context
cat >context/Dockerfile <<EOF
FROM busybox
RUN touch foo
EOF

# Load images into local cache with internet access
docker run -v "${PWD}/makisu-storage:/tmp/makisu-storage" makisu:latest pull busybox

# Build images without internet access, using only cached images and the local context directory
docker run --network=none -v "${PWD}/makisu-storage:/makisu-storage" -v "${PWD}/context:/context" makisu:latest build --modifyfs -t foo /context/