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.
Problem statement
We've got some configuration drift by virtue of having almost identical configurations in different
docker-composefiles 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.ymlwhich is paired withdocker-compose.override.yml.docker composecommands automatically find and select those two files, making the development experience easier. This is equivalent to runningdocker compose -f docker-compose.yml -f docker-compose.override.ymlTLS local development is facilitated by running
docker compose -f docker-compose.yml -f docker-compose.dev.ssl.ymlDeployment
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(ornonssl.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
Caddyfilethat serves it all.Its configurability is managed by environment variables and imported snippet files.
*.tls.Caddyfile*.frontend.CaddyfileDefault files (
off.tls.Caddyfile,dev.frontend.Caddyfile) can be copied as is. Override files need to have their dash replaced with a dot (toon.tls.Caddyfileanddeploy.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/localis now redirected toorbitar.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
*:5001server 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 usedapi.$SERVER_DOMAIN. I don't know why. Now API / backend host is defined exclusively by this variable.BACKEND_DOMAIN. Set to eitherhost.docker.internalorbackendrespectively in the docker compose files.TLS_CERT_FILE&TLS_KEY_FILE. Default toorbitar.crt&orbitar.keyrespectively. Overridden by compose files.SERVER_HOST. Set tohttp://$SERVER_DOMAINorhttps://$SERVER_DOMAIN, depending on the configuration.API_HOST. Set tohttp://$API_DOMAINorhttps://$API_DOMAIN, depending on the configuration.Other
Updated
usesactions to their latest versions.