chore: Cleaned up ansible and added control script

readme.md

@@ -11,6 +11,7 @@ Infrastructure-as-code and service definitions for luke-else.co.uk's self-hosted
 - [Architecture](#architecture)
 - [Repository layout](#repository-layout)
 - [Prerequisites](#prerequisites)
+- [Control panel (`control.sh`)](#control-panel-controlsh)
 - [Provisioning the infrastructure](#provisioning-the-infrastructure-infra)
 - [Bootstrapping and deploying with Ansible](#bootstrapping-and-deploying-with-ansible-ansible)
 - [Service inventory](#service-inventory)
@@ -84,7 +85,7 @@ Each host's stateful data lives in local named Docker volumes, backed up nightly
 │       └── dns/                # Hetzner DNS zones + A records for every domain in var.dns_zones
 ├── ansible/                   # Ansible: bootstraps each server and deploys/starts services/<host>/ onto it
 │   ├── inventory/hcloud.yml   # dynamic inventory — queries the Hetzner API, groups by the role label above
-│   ├── group_vars/            # deploy_user, dev_runner_count, backup_s3_*, etc.
+│   ├── group_vars/            # deploy_user, service_group, backup_s3_*, etc.
 │   ├── roles/
 │   │   ├── bootstrap/          # Docker, deploy user, sshd hardening, unattended-upgrades
 │   │   └── deploy/             # copies services/<host>/, renders .env (S3 backup credentials) + Runners/docker-compose.yml
@@ -115,6 +116,16 @@ OpenTofu and Ansible have a clean split: OpenTofu only ever provisions cloud res
 
 Docker + the Compose plugin, the non-root `deploy` user, and SSH hardening no longer need doing by hand — Ansible's `bootstrap` role handles all of that (see below).
 
+## Control panel (`control.sh`)
+
+If you'd rather not remember the exact command order, [`control.sh`](control.sh) at the repo root is an interactive menu that steps you through the whole pre-setup and bring-up. Run it from anywhere:
+
+```sh
+./control.sh
+```
+
+It offers a **Check prerequisites** option (tools, `HCLOUD_TOKEN`/`BACKUP_S3_*` env vars, `terraform.tfvars`, SSH key, the `hetzner.hcloud` collection), individual OpenTofu (`init`/`plan`/`apply`/`output`/`destroy`) and Ansible (bootstrap/deploy/spinup/spindown per role) actions, and a **Guided full setup** that runs everything in the firewall-imposed order — vpn first, pause for you to connect the VPN, then dev/prod. It's only a wrapper around the same `tofu` and `ansible-playbook` commands documented below, so you can always fall back to running them by hand.
+
 ## Provisioning the infrastructure (`infra/`)
 
 ```sh
@@ -189,11 +200,11 @@ docker compose -f backup-docker-compose.yml exec backup backup   # force an imme
 docker compose -f backup-docker-compose.yml run --rm restore     # restore any currently-empty volumes
 ```
 
-### Scaling Gitea Actions runners
+### Gitea Actions runners
 
-The number of Gitea Actions runner containers on `dev` is set by `dev_runner_count` in [`ansible/group_vars/role_dev.yml`](ansible/group_vars/role_dev.yml) (default `3`). Re-running `ansible-playbook playbooks/deploy.yml -l role_dev` renders [`roles/deploy/templates/runners-docker-compose.yml.j2`](ansible/roles/deploy/templates/runners-docker-compose.yml.j2) straight onto the server as `services/dev/Runners/docker-compose.yml` — one `runner-N` service per count, each with its own container name and `/data` volume so their registrations don't collide. That file is generated on the remote host: change `dev_runner_count` and redeploy rather than hand-editing it.
+`dev` always runs three Gitea Actions runner containers, configured automatically on deploy. Re-running `ansible-playbook playbooks/deploy.yml -l role_dev` renders [`roles/deploy/templates/runners-docker-compose.yml.j2`](ansible/roles/deploy/templates/runners-docker-compose.yml.j2) straight onto the server as `services/dev/Runners/docker-compose.yml` — three `runner-N` services, each with its own container name and `/data` volume so their registrations don't collide. That file is generated on the remote host, so edit the template rather than hand-editing the rendered file (the count lives in a `{% raw %}{% set runner_count = 3 %}{% endraw %}` line at the top).
 
-Rendering it doesn't start anything by itself — re-run `ansible-playbook playbooks/spinup.yml -l role_dev` afterwards to apply a count change.
+Rendering it doesn't start anything by itself — re-run `ansible-playbook playbooks/spinup.yml -l role_dev` afterwards to apply a template change.
 
 Registration tokens are handled automatically, not baked into the generated file: `services/dev/spinup.sh` waits for Gitea to come up, runs `gitea actions generate-runner-token` inside the Gitea container, and writes the result to `Runners/.env`, which Compose loads automatically. There's no manual admin-UI step for this anymore.