Add Makefile and Caddy config generator

[xrobau]

This adds some tools and helpers to make deploying a new instance
easier. I also encourage the use of Caddy, which allows reverse
proxy of the required paths, and a simple webserver for anything
that doesn't match anything known about by the API instance.

There is a very simple index.html which is copied to the webroot
folder (/var/lib/relay/webroot) which the end user can then modify
if wanted.

This consists of squashed commits:
    Put the default webroot in a sensible location
    Add a slightly better 404 string
    Add caddyfile generator
    Add config hooks
    Add basic Makefile

See https://git.artemai.art/xrobau/Activity-Relay for raw commits

Signed-Off-By: Rob Thomas <xrobau@gmail.com>

[lifeofguenter]

This might be adding some bloat? Go already comes with a webserver? Eg rather let the user chose between traefik, nginx or any other loadbalancer.

[xrobau]

This just connects to the Go webserver, but Caddy does all the SSL Certificate request/install/update for you. The other thing this adds is the ability to remap OTHER paths to a webroot, so that a relay instance doesn't just 404 - see https://relay.wig.gl/ vs https://relay.oi.au/

Basically, there needs to be SOMETHING that takes https:://... and maps it to http://localhost:8080 so why not use Caddy, as the config is much simpler than anything else.

The current known paths are here, and should be painless to update: https://github.com/yukimochi/Activity-Relay/pull/60/files#diff-104158face756c55045ed32564fe140ef2afd207b04608d7a0d9459bd513295dR7

[lifeofguenter]

I know what Caddy is and what your PR does :)

My question is around: why is this needed in first place, why Caddy and not xyz?

I am sure some setups already today do not have to worry about HTTPS as they would run docker behind k8s, a loadbalancer (AWS) or even traefik. So your setup with Caddy might be specific / opinionated, but not necessarily common.

If its just for adding additional pages/APIs, then I think this should belong into the core with templating, not having to manage another process which is against the grain on how docker should be running.

Maybe this can just be part of a documentation for scenario "self hosted on non-docker environments" or similar?

[xrobau]

Updated with recent commits from master, fixed conflict

[seano-vs]

My question is around: why is this needed in first place, why Caddy and not xyz?

I am sure some setups already today do not have to worry about HTTPS as they would run docker behind k8s, a loadbalancer (AWS) or even traefik. So your setup with Caddy might be specific / opinionated, but not necessarily common.

If its just for adding additional pages/APIs, then I think this should belong into the core with templating, not having to manage another process which is against the grain on how docker should be running.

Maybe this can just be part of a documentation for scenario "self hosted on non-docker environments" or similar?

Have to +1 this.

[xrobau]

Uh, because it's there? It's not ENFORCING anything, people were asking for help with setting this up. All this does is provide an example. I'm not sure what the big deal is?