add Dockerfile and GitHub action for building image

[willnorris]

This largely mirrors the default Caddy image. (I generally use chainguard images to limit dependencies, but stuck with alpine, since that's what Caddy uses for it's main images)

The GitHub Action is duplicated from what we have for tailscale/golink. I don't really know a lot of best practices for Dockerfiles, so am really looking for any input. I have this using the simple.caddyfile as the default config, which is easy to override.

Updates #14

[willnorris]

wow, 16 minutes to build the image for two platforms :(

[irbekrm]

Makes sense in general, I've left two suggestions.

I think ko would be faster than Docker build, but it seems like it is not possible to expose ports using ko ko-build/ko#472

[irbekrm]

Nice

[irbekrm]

Suggested change

	RUN go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest && \
	xcaddy build v${CADDY_VERSION} --with github.com/tailscale/caddy-tailscale@main --output /usr/bin/caddy
	RUN go run github.com/caddyserver/xcaddy/cmd/xcaddy@latest build v${CADDY_VERSION} \
	--with github.com/tailscale/caddy-tailscale@main --output /usr/bin/caddy

maybe makes it a little faster?

[irbekrm]

Also, I'm wondering if we can use the tailscale-caddy repo checkout available to this action rather than refer to github.com/tailscale/caddy-tailscale@main? The checkout should presumably bet the one corresponding to the push event

[willnorris]

I'd be surprised if go run was actually any faster, but certainly doesn't hurt so let's give it a try.

And oops, totally forgot to instruct it to use the local source for building. I'll add that.

[willnorris]

I think ko would be faster than Docker build, but it seems like it is not possible to expose ports using ko ko-build/ko#472

EXPOSE is really just to document what ports are exposed mapped, right? But it's not really necessary to be able to map ports?

It also looks like ko really wants a simple main package that it can build. That would mean bypassing xcaddy entirely for our builds and having our own simple cmd. Which is totally fine, that's actually what I do for my personal website. I'll actually do that first as a separate PR.

[irbekrm]

It also looks like ko really wants a simple main package that it can build. That would mean bypassing xcaddy entirely for our builds and having our own simple cmd.

We also have our own container builder that is a stripped down version of ko and that allows to include multiple binaries https://github.com/tailscale/mkctr. But I think we don't have an option to include static files with that

[irbekrm]

EXPOSE is really just to document what ports are exposed mapped, right? But it's not really necessary to be able to map ports?

That is my understanding, yes. Also, we don't expose ports for any of the other images we build (for example the k8s-operator that runs a server and listens on 443 and the tsrecorder)