Add example with init container fetching context for non-GCS remote contexts

[r2d4]

Kaniko can work without needing to fetch the remote context itself. This would open the workflow to non-GCS remote contexts.

1. Init container with with whatever auth helpers needed (gcloud, aws-cli) and credentials mounted in. Downloads context to shared volume
2. Kaniko container reads locally downloaded context

Alternatively, we could just target the S3 compatible API, which is supported by GCP and AWS. We'd need a more generic way of getting passing credentials (I think?)

[AkihiroSuda]

https://github.com/graymeta/stow seems providing abstract interface for GCS, S3, Azure storage, Swift, and Oracle storage.

[alexellis]

Hi @r2d4 I would be interested in this feature for using Minio or similar within a hybrid/on-premise solution.

Would fetching from a Git repo over SSH/HTTPs be within scope?

Alex

[priyawadhwa]

Hey @alexellis , I think that would be within scope since Docker allows for Github repos as build contexts.

Could you open a separate issue for this? It'll be easier to keep track of, and if you're interested in contributing this feature I can provide more details!

[alexellis]

This is how I did it via a Gist + init container. https://gist.github.com/alexellis/87d732a4b5fe056f5bf903aa6e6437ed

It'd be far cleaner within kaniko - I'd also be interested in some details, but am unsure if I can commit to contribute it until I get CLA approved and can size the work.

Alex

[jfrabaute]

Hi,

In our CI/CD environment, we are using gerrit and we can get the tar.gz of a particular commit from an https url.
kaniko does not allow using random https urls, as https:// scheme is checked against azure urls:

https://github.com/GoogleContainerTools/kaniko/blob/master/pkg/buildcontext/buildcontext.go#L61

What is the reason to limit https urls to Azure? Could the check for Azure url pattern be revmoed so any https url is accepted?

[jidaojiuyou]

why not support http in internal net