Build docker images with ko (goreleaser)

[kradalby]

Move away from the complicated docker release setup and use ko within goreleaser.

[ohdearaugustin]

Generally I think this is a good idea. We should just discuss one or two things I mentioned in the review to make sure we don't break stuff.

[ohdearaugustin]

I understand the move to kos, which makes things way easier.

I just want to make aware of one drawback. Users can't build the dockercontainers by themselves anymore. Manual builds for testing use then a different container than the released ones. For testing in the pipeline we would use docker.io/golang:1.21-bookworm as basic and the kos settings would use gcr.io/distroless/base-debian11.

This just reminds me of the discussion that distroless containers are to "complicated" to maintain.

[kradalby]

This is a good point, for the time being, I am willing to give the distroless part another chance, and then keep the Dockerfile.debug around for "build your own".

I'm not sure if we can make the goreleaser push containers if there is no release, but that would be useful.

Goreleaser supports a docker mode which is more traditional, but it requires more stuff, I would prefer to try ko first and then potentially switch to that if its not working out.

This just reminds me of the discussion that distroless containers are to "complicated" to maintain.
I appreciate this comment ;), luckily I've right now forgotten all the pain points and will try this and then curse in the future.

let me know what you think.

[ohdearaugustin]

We can try it of course.

I would also add the debug image of distroless, as a lot of people use stuff like portainer and so and they normally want to have a shell inside the container. This is the same we did before we got rid of the old distroless containers. Furthermore the question is if ko can create our folders inside the container. As we had the problem beforehand: #1417

So a bit of a general blueprint:

1. Container with distroless-debian12
2. Container with distroless-debian12:debug

I guess testing the whole thing on a fork with "fake releases" would be our best option to get this thing working and tested before merging into main.

I hope I didn't reminded you of too much pain, because I'm still a huge fan of distroless images.

[kradalby]

hehehe, no worries, I've added debug but based on regular debian image as a compromise for now. Would you have time to help me test it?

[kradalby]

or could merge it and test it as part of the next alpha.

[juanfont]

Would it make sense to add in the comment that we generate the official container using goreleaser ?

[kradalby]

We can do that after testing this.

[paralin]

How do we build headscale/headscale now after this change?

[ohdearaugustin]

The idea is that then there is just a debug dockerfile and the containers are only released by goreleaser. So no dockerfiles for released container anymore.

[paralin]

But I'd like to build it myself, how can I do that?

[ohdearaugustin]

As said with the debug dockerfile or you bring your own.

Edit: Or you fork it and release your own version.

[paralin]

Okay, I was looking for something like "goreleaser build" or "ko build" or similar. Will figure it out

[ohdearaugustin]

Yeah goreleaser doesn't support that. Docu about the build process can be found here. You probably can get the configuration out of the .goreleaser.yml, edit it a bit and then try to build it with kos standalone.

But this is still work in progress. So we will see how it will turn out.

[sevenrats]

this has a negative impact on the apparent trustworthiness of headscale. I'm further from being able to reproduce your build, the images themselves look very suspect because the build commands are all blank on dockerhub. Looking at the included dockerfile its not immediately apparent what complexity is being resolved by this switch. Why make these sacrifices? What do you gain by moving to ko? ntm that it seems really odd to use docker to ship a service which contains a cli interface but no cli. am I really supposed to docker exec headscale headscale literally every single command?

[kradalby]

Docker isn’t a priority and we release them as a nice to have, considering Headscale is a single binary it isn’t really necessary.

The switch was made to simplify our build and lessen the burden on maintainers, which it did so it’s been a success and it’s easier for us to reason about

[sevenrats]

whether or not a service is a single binary is not really a factor in whether or not people reach for a dockerized solution. its just the nature of their stack that dictates it typically, and with over 500k downloads on your official image I think there is an onus to deliver the docker image well and in a standard way.
I would be willing to help shoulder some of the burden of delivering more standard docker containers if there is a way.

[kradalby]

Sorry we are not interested in changing it