search

GoogleContainerTools / kaniko

Build Container Images In Kubernetes
Apache License 2.0
14.22k stars 1.4k forks source link

[Feature Request]: Optional webserver #3041

Open BeyondEvil opened 3 months ago

BeyondEvil commented 3 months ago

If Kaniko would support a simple webserver (can be a separate image to not inflate the standard one), you could use Kaniko as a sidecar.

That would solve some of the use-cases where people (like myself) need to use Kaniko as a "library".

JeromeJu commented 3 months ago

Thanks @BeyondEvil for the request, the original design and the existing uses cases are to run kaniko as an image. Could you provide more specific uses cases for the usage as a sidecar so that we could delve into the implementation requirements and respective pros and cons?

BeyondEvil commented 3 months ago

Hi @JeromeJu

Essentially, any use-case that requires that you extend to or from the Kaniko image (which currently isn't supported) or use it as a binary (which currently isn't supported as well) would likely be solvable if Kaniko exposed an HTTP endpoint in addition to the CLI.

As a concrete example: We're using GitLab self-hosted CI runners with the AWS Fargate plugin.

The image used for the runner requires that the gitlab-runner binary/application is installed and it requires an ENTRYPOINT that accepts an SSH public key and that starts the SSHd daemon.

Obviously this isn't compatible with Kaniko. And since Fargate doesn't expose the docker socket or allow privileged access - any DIND-solution isn't possible either.

Given a webserver/HTTP endpoint, we could launch Kaniko as a sidecar to the GitLab runner and given the shared network could call it with something like:

curl localhost:<configurable_port> -d '{"context":"./docker",...etc...}'

This likely relevant for self-hosted Github runners and strictly governed Kubernetes as well.

Happy to expand further.

I should note that we've solved it for now, but it's not optimal and unnecessarily complex.