47 lines
2.5 KiB
Markdown
47 lines
2.5 KiB
Markdown
# Cloudserve infrastructure
|
|
|
|
## Testing
|
|
|
|
This repository comes with a test-ready setup to try out the complete site setup locally.
|
|
It uses vagrant to accomplish this and create a locally available target host.
|
|
Install [vagrant](https://www.vagrantup.com/) on your system and to make tests repeatable also install the vagrant plugins `vagrant-hosts` and `vagrant-hostsupdater`,
|
|
which will set a static IP for the vagrant host to be reachable under.
|
|
|
|
```bash
|
|
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,
|
|
not just an IP address.
|
|
For now this is most simply accomplished through editing the hosts file, e.g.:
|
|
|
|
```hosts
|
|
192.168.56.2 ansible.test
|
|
192.168.56.2 git.ansible.test
|
|
192.168.56.2 links.ansible.test
|
|
```
|
|
|
|
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`.
|
|
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,
|
|
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.)
|
|
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).
|
|
|
|
To create such a file you can do `ansible-vault create group_vars/<group-name>/vault.yml` or
|
|
do `ansible-vault edit group_vars/<group-name>/vault.yml` to edit it.
|
|
|
|
Look into the `default/main.yml` files of the various roles to see which variables should be set or can be overridden.
|
|
The `README.md` files of the roles should also carry enough information about the individual variables to make sense.
|