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.
14 lines
511 B
YAML
14 lines
511 B
YAML
---
|
|
# The Great Bear. Its name, tagline, icon, categories and menus live on the server under
|
|
# app_root and are edited in the admin; config/greatbear.site.json only seeds the
|
|
# theme and the first category list.
|
|
title: greatbear.in
|
|
host: 'menu.{{ title }}'
|
|
|
|
docker_container: 'menu-app.{{ title }}'
|
|
docker_network: '{{ docker_container }}_net'
|
|
|
|
# Everything the app writes — data/ and the untracked site.env. Deliberately the
|
|
# directory the old static menus were served from.
|
|
app_root: '/var/lib/{{ host }}'
|