tanshu
33a8d56e8b
One image serves every Site, so a new Site is three small files: an inventory entry, a vars file naming its web address and data root, and a config that seeds its theme and first category list (baked into the image, which is why a new Site needs a new tag). Both reuse the directory their old static menus were served from, and the caddy role drops the snippet the retired nginx-menu playbook wrote for each hostname, so a deploy repoints each address at its own container with nothing else to do. The seeded category lists are a starting point, not a decision: categories, names and icons are all editable in each Site's own admin. A test now checks the inventory, config and vars agree for every Site and that no config is orphaned, because a half-added Site was the obvious way to get this wrong.
18 lines
737 B
INI
18 lines
737 B
INI
# The Ansible inventory for the menus. Every Site runs on the same box, so each
|
|
# entry names it and points at the vars file that describes it.
|
|
#
|
|
# cd ansible
|
|
# ansible-playbook --inventory=hosts playbook.yml # every Site
|
|
# ansible-playbook --inventory=hosts playbook.yml --limit hopsngrains
|
|
#
|
|
# ansible_host is written as the resolvable name rather than an ssh alias so the
|
|
# inventory works on any machine, whatever its ~/.ssh/config says.
|
|
|
|
[menus]
|
|
hopsngrains ansible_host=monoco.tanshu.com var_file=vars/hopsngrains.yml
|
|
greatbear ansible_host=monoco.tanshu.com var_file=vars/greatbear.yml
|
|
hngmohali ansible_host=monoco.tanshu.com var_file=vars/hngmohali.yml
|
|
|
|
[all:vars]
|
|
ansible_python_interpreter=/usr/bin/python3
|