Apply prettier formatting

This commit is contained in:
Marty Oehme 2024-06-24 20:36:55 +02:00
parent 6b4c4ccde4
commit c498b3ced8
Signed by: Marty
GPG key ID: EDBF2ED917B2EF6A
76 changed files with 123 additions and 202 deletions

View file

@ -12,7 +12,7 @@ vagrant plugin install vagrant-hosts vagrant-hostsupdater
```
Additionally, since the test setup mirrors the production setup in that it makes use of subdomains for the individual hosted applications,
the server needs to be reachable under a domain name,
the server needs to be reachable under a domain name,
not just an IP address.
For now this is most simply accomplished through editing the hosts file, e.g.:
@ -23,21 +23,20 @@ For now this is most simply accomplished through editing the hosts file, e.g.:
```
This will allow you to reach the main domain under `http(s)://ansible.test` and sets up two subdomains that can be reached.
Be aware that the hosts file does not support subdomain wildcards.
You will have to specify each hostname individually or use a tool such as `dnsmasq`.
Be aware that the hosts file does not support subdomain wildcards.
You will have to specify each hostname individually or use a tool such as `dnsmasq`.
Read more [here](https://serverfault.com/questions/118378/in-my-etc-hosts-file-on-linux-osx-how-do-i-do-a-wildcard-subdomain).
Then you are ready to run the complete infrastructure setup locally,
Then you are ready to run the complete infrastructure setup locally,
simply by executing `ansible-playbook site.yml`.
You can of course pick and choose what should be executed with host limits, tags, group variables, and so on,
but this should provide an easy way to see if a) the playbook is working as intended and b) what it does is useful.
## Deployment
Most variables to be changed should be set either through `group_variables` or `host_variables`.
For my deployment I have a `production` group under `group_variables` which houses both a `vars.yml` containing basic variables
(like `server_domain`, `caddy_email`, etc.)
(like `server_domain`, `caddy_email`, etc.)
and a `vault.yml` which houses everything that should ideally not be lying around in plain-text
(individual container and database passwords for the various roles etc).