Renameable binaries / path

[leongross]

ko defaults to placing binaries into the path /ko-app/<app-name>.
As for now it seems as if there is no way to set this name during the build process.

This is especially important if the containers are used in a Kubernetes environment where the entrypoint is overwritten and the absolute path of the binary is important, which is a common practice.

Although this path might be known it complicates the drop-in integration of ko containers in a production environment, since the deployments have to be adjusted to use the ko specific path.

The lines responsible for the naming seem to be these.

It would be great if a new flag such as -o / --out-path or something similar could be introduced that let the user set the output path to their needs.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.

[samox73]

Is there any update on this? I'd like to switch over to ko from docker's buildx, but I'm also facing the problem of using ko with pre-existing projects where the entrypoint may not change.

[imjasonh]

Sorry for not responding earlier.

I'm not opposed to this in general, but I'd like to understand a bit more what requirements are driving it. Is the problem that a runtime config might be specifying the image's entrypoint, and it breaks when migrating to build with ko?

Is there a reason the image's entrypoint can't be used directly, so that both the old buildx image and the new ko image both work?

ko in general aims to make details of the image like this invisible to users, as as UX feature. I understand if sometimes this is too optimistic, and folks need this low-level control.

[unmarshall]

If you use docker to build the images (multi-stage builds) then you build the binary in the builder step and copy the built binary to a specific location which also becomes the entry point. One has complete control over it. This is also then used to set the command in the k8s deployment yaml file. Now when moving to KO this changes as it decides to prefix the entry point with ko-app and has no way to overwrite it. This creates an issue for all existing deployment yaml files.

On the other hand we can just specify the args and not the command in the deployment and it will always pick up the entrypoint. So i would say its a good to have feature but there is a way around it.

[samox73]

As @unmarshall explained, having a fixed entrypoint poses the issue of breaking working systems and using ko as a drop-in replacement is not possible. Having the ability to change the default entrypoint would make adoption of ko into existing project much easier.

In my particular case, I am writing a k8s operator with the operator framework and when building the bundle manifests it is not documented how to change the k8s command of the container. I found that this is defined in /config/manager.yaml and could (as @unmarshall said) work my way around it, albeit somewhat clumsily.

[imjasonh]

I want to be clear that I'm not saying ko shouldn't support this.

So there seem to be workarounds to this that (IMO) simplify the deployment config, since it removes config from the deployment manifest and makes the path of the entrypoint binary completely owned by the image build process. This is compatible with existing docker-based build workflows, and compatible with ko's model, so folks can adopt that model before moving to ko, then have no issue moving to ko.

I understand it's a bit of a speedbump, but I think at the end of the road there's a cleaner deployment model where the deployment manifest doesn't have to know or care what the image's entrypoint is, and doesn't have to reiterate it when it's already defined elsewhere.

[UnseenWizzard]

Is this still being considered? I'd be happy to look into contributing this change.

As this thread seems to have mainly discussed this (not) being an issue/hurdle from a k8s perspective, I'll add another case where ko producing something different to what's possible with docker/buildx is making it hard to adopt:
Containers may be used in CI systems.
Some systems, like GitLab, assume that the entry point is a shell, so the entry point needs to be overwritten.
This means that users using a container in GitLab need to be told where they can find the binary they actually want to execute, as they can't just use the default entry-point.

For us this means that while a ko built image stays functionally the same to the previous one using the binary as entry-point, this will be a breaking change to some of our users' CI/CD pipelines.

Would be great to avoid things like this and make an internal tool change actually transparent to end users!

[calmh]

I'm mostly just slightly annoyed by the branding aspect and unexpectedness of /ko-app/. :p Had it been /bin/, or configurable to /bin/, I'd have been happier. This does come up all the time, when we need to run command manually on a container (kubectl exec ...).

So for me, by all means keep it invisible and unconfigurable, but make it something less unexpected: /bin/.

[kfox1111]

I'm hitting this problem to.

The problem is, file paths in the container are unfortunately, sometimes API.

If you release a container image before KO, your binary could be at, say, /myapp. You may have told users that path as part of your API contract. Other software, not build by you, may very well depend on that path being there. Its a breaking change to all the software on top if it moves.

It is a showstopper to some projects to go from Not KO -> KO, if there is no option to be able to specify the final binary, so that backward compatibility of images can be maintained.

This issue, and the one before the repo moved, has been around for a very long time (many years). Do we keep debating the need for it, and excluding users from using KO that find backwards compatibility of that API important, for more years, or will we just fix it? Its one config option, an os.Rename, and maybe an os.Makedir to unblock these users.