Apply prettier formatting
This commit is contained in:
parent
6b4c4ccde4
commit
c498b3ced8
76 changed files with 123 additions and 202 deletions
11
README.md
11
README.md
|
|
@ -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).
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue