-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relocate the run image to the builder repo #1533
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,14 +2,15 @@ package cnb | |
|
||
import ( | ||
"context" | ||
"fmt" | ||
|
||
"github.com/google/go-containerregistry/pkg/authn" | ||
ggcrv1 "github.com/google/go-containerregistry/pkg/v1" | ||
"github.com/pivotal/kpack/pkg/cosign" | ||
corev1 "k8s.io/api/core/v1" | ||
|
||
buildapi "github.com/pivotal/kpack/pkg/apis/build/v1alpha2" | ||
corev1alpha1 "github.com/pivotal/kpack/pkg/apis/core/v1alpha1" | ||
"github.com/pivotal/kpack/pkg/cosign" | ||
"github.com/pivotal/kpack/pkg/registry" | ||
) | ||
|
||
|
@@ -30,15 +31,34 @@ type RemoteBuilderCreator struct { | |
ImageSigner cosign.BuilderSigner | ||
} | ||
|
||
func (r *RemoteBuilderCreator) CreateBuilder(ctx context.Context, builderKeychain authn.Keychain, stackKeychain authn.Keychain, fetcher RemoteBuildpackFetcher, clusterStack *buildapi.ClusterStack, spec buildapi.BuilderSpec, serviceAccountSecrets []*corev1.Secret) (buildapi.BuilderRecord, error) { | ||
buildImage, _, err := r.RegistryClient.Fetch(stackKeychain, clusterStack.Status.BuildImage.LatestImage) | ||
func (r *RemoteBuilderCreator) CreateBuilder( | ||
ctx context.Context, | ||
builderKeychain authn.Keychain, | ||
stackKeychain authn.Keychain, | ||
fetcher RemoteBuildpackFetcher, | ||
clusterStack *buildapi.ClusterStack, | ||
spec buildapi.BuilderSpec, | ||
serviceAccountSecrets []*corev1.Secret, | ||
resolvedBuilderRef string, | ||
) (buildapi.BuilderRecord, error) { | ||
|
||
buildImage, _, err := r.RegistryClient.Fetch(stackKeychain, clusterStack.Status.BuildImage.LatestImage) | ||
if err != nil { | ||
return buildapi.BuilderRecord{}, err | ||
} | ||
runImage, _, err := r.RegistryClient.Fetch(stackKeychain, clusterStack.Status.RunImage.LatestImage) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would it be possible to only save the image if it is in a different registry than the builder? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was thinking you might still run into a case where the pull rules could be different for a different repo There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair. There is a trade-off from having the run-image be relocated everywhere, though. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think I'm ok with just checking the registry and saying you need to be able to pull both. Maybe putting the original image in the run image mirror would also help as a backup There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thinking more about this, i'm seeing less of an issue with always relocating. In the event that the run image is in the same registry we will just cross repo blob mount. It will also tag the run image to prevent it from being being cleaned up. If the run image is in a different repo the value is much more apparent since you don't have to worry about run image access. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was thinking the downside is more about more confusing provenance. It is useful to see that the run image is but, I agree it is not a fatal flaw. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ya that is definitely a concern, but I was hoping the tags on the relocated run image would simplify this. It also makes registry management a bit easier so you can easily see the run image associated with a particular builder |
||
if err != nil { | ||
return buildapi.BuilderRecord{}, err | ||
} | ||
|
||
builderBldr := newBuilderBldr(r.KpackVersion) | ||
|
||
relocatedRunImage, err := r.RegistryClient.Save(builderKeychain, fmt.Sprintf("%s-run-image", resolvedBuilderRef), runImage) | ||
if err != nil { | ||
return buildapi.BuilderRecord{}, err | ||
} | ||
builderBldr.AddRunImage(relocatedRunImage) | ||
|
||
err = builderBldr.AddStack(buildImage, clusterStack) | ||
if err != nil { | ||
return buildapi.BuilderRecord{}, err | ||
|
@@ -72,7 +92,7 @@ func (r *RemoteBuilderCreator) CreateBuilder(ctx context.Context, builderKeychai | |
return buildapi.BuilderRecord{}, err | ||
} | ||
|
||
identifier, err := r.RegistryClient.Save(builderKeychain, spec.Tag, writeableImage) | ||
identifier, err := r.RegistryClient.Save(builderKeychain, resolvedBuilderRef, writeableImage) | ||
if err != nil { | ||
return buildapi.BuilderRecord{}, err | ||
} | ||
|
@@ -96,7 +116,7 @@ func (r *RemoteBuilderCreator) CreateBuilder(ctx context.Context, builderKeychai | |
builder := buildapi.BuilderRecord{ | ||
Image: identifier, | ||
Stack: corev1alpha1.BuildStack{ | ||
RunImage: clusterStack.Status.RunImage.LatestImage, | ||
RunImage: relocatedRunImage, | ||
ID: clusterStack.Status.Id, | ||
}, | ||
Buildpacks: buildpackMetadata(builderBldr.buildpacks()), | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is
clusterStack.Status.RunImage.Image
fully qualified?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya it's the resolved image
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like it just the spec runImage which is not necessarily fully qualified.
kpack/pkg/cnb/remote_stack_reader.go
Lines 71 to 74 in 03acfbb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that was intentional. The run image shouldn't necessarily be fully qualified. (E.g if you are using the builder with pack and the run image was updated it is useful to make use of that run image)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose here, it needs to be relocated by kpack so, it is not necessarily useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which I guess exposes the downside with this approach. It is only really useful if the source of the stack is not available otherwise, it provides a worse experience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya I guess the trade off is full build reproducibility though which a floating tag doesn't guarantee