search

buildpacks / pack

CLI for building apps using Cloud Native Buildpacks
https://buildpacks.io
Apache License 2.0
2.56k stars 286 forks source link

Pack should allow setting a docker repository to pull lifecycle from #1083

Closed sambhav closed 3 years ago

sambhav commented 3 years ago

Description

Often times, enterprises prevent access to the internet and have private registries. In cases such as these, pack doesn't allow you to run pack build unless your builder is trusted.

This is useful to allow private buildpacks/builders to function without having to configure each internal builder as trusted.

Proposed solution

Allow creating a pack config subcommand to set a lifecycle mirror repository which can be used instead of https://github.com/buildpacks/pack/blob/main/build.go#L44

Describe alternatives you've considered

Adding each and every builder as trusted

Additional context

dfreilich commented 3 years ago

This may help fix https://github.com/buildpacks/pack/issues/904

ekcasey commented 3 years ago

@dfreilich fwiw I think configuring different (mirror) locations to find known lifecycle images is a bit different from allowing a user to pass an arbitrary lifecycle image. But doing the latter would provide a work around for the former.

@samj1912 I am curious, is you private registry truly a mirror of a public registry (same repo names, different registry hostname) or would you need to supply the reference for each mirrored image. I ask because it's possible to configure a a daemon with a mirror registry, but pack sometimes directly reaches out to image registries and I suspect would not respect this config. Enhancing pack to support mirror registries (rather than specific mirror images) might be another desirable feature, if this is a common use case.

sambhav commented 3 years ago

It is not an exact mirror, rather a filtered version of it. Passing in an arbitrary lifecycle image would work as well.

jromero commented 3 years ago

I lean towards arbitrary lifecycle image as suggested in the review. It would be more versatile.

Big picture-wise, there is also another similar issue #821 which should enable other transparent/caching proxies. I don't think that these issues conflict given the different use cases.

  1. I want to use this very specific lifecycle image
  2. I want all my images to be pulled through this proxy