Split compose & caddy files

[Lexy2]

Problem statement

We've got some configuration drift by virtue of having almost identical configurations in different docker-compose files and different Caddy configurations.

Solution

This PR attempts to mitigate those issues by making hierarchical structure of the Docker & Caddy configuration files used.

Compose

Development

The main configuration file is now docker-compose.yml which is paired with docker-compose.override.yml. docker compose commands automatically find and select those two files, making the development experience easier. This is equivalent to running docker compose -f docker-compose.yml -f docker-compose.override.yml

TLS local development is facilitated by running docker compose -f docker-compose.yml -f docker-compose.dev.ssl.yml

Deployment

Main deployment requires plugging in 3 docker-compose files: docker compose -f docker-compose.yml -f docker-compose.deploy.yml -f docker-compose.deploy.ssl.yml (or nonssl.yml).

The reason why it has to be so complicated is because list variables in compose files can't be overridden, they are only complemented in override files, so you can't define everything just in one file and then add just one override file, alas.

I also renamed the file parts from local to deploy which better reflects their purpose.

Caddy

Configuration

There is now one main Caddyfile that serves it all.

Its configurability is managed by environment variables and imported snippet files.

• *.tls.Caddyfile
• *.frontend.Caddyfile

Default files (off.tls.Caddyfile, dev.frontend.Caddyfile) can be copied as is.
Override files need to have their dash replaced with a dot (to on.tls.Caddyfile and deploy.frontend.Caddyfile) to provide updated behaviour. They are also mutually exclusive with the default files; only one of each should be copied.

Subdomains

We don't use or support subdomains in our prod, so I dropped its support from caddy.
www.orbitar.space / local is now redirected to orbitar.space / local.

CORS

I finally configured CORS the way it should work.

Only backend requests are responded with CORS policy allowing cross-domain requests from the frontend and frontend only. Even in development. You want access to backend directly - you always have your *:5001 server running.

The backend CORS-related headers are removed by caddy - this backend feature caught me by surprise and I puzzled for a little bit (I configured it right, why is it not working?)

Environment

Most of the changes in the environment variables were for Caddy.

• API_DOMAIN. This variable was always defined by never used. Instead, we used api.$SERVER_DOMAIN. I don't know why. Now API / backend host is defined exclusively by this variable.
• BACKEND_DOMAIN. Set to either host.docker.internal or backend respectively in the docker compose files.
• TLS_CERT_FILE & TLS_KEY_FILE. Default to orbitar.crt & orbitar.key respectively. Overridden by compose files.
• SERVER_HOST. Set to http://$SERVER_DOMAIN or https://$SERVER_DOMAIN, depending on the configuration.
• API_HOST. Set to http://$API_DOMAIN or https://$API_DOMAIN, depending on the configuration.

Other

Updated uses actions to their latest versions.