Two drift-fixes between the bootstrap playbook and the rest of
the W5 deploy pipeline :
* Container name : `haproxy` → `veza-haproxy`
inventory/{staging,prod}.yml's haproxy group now points at
`veza-haproxy` ; the bootstrap was still creating an unprefixed
`haproxy` and the role would never reach it.
* Base image : `images:ubuntu/22.04` → `images:debian/13`
Matches the rest of the deploy pipeline (veza_app_base_image
default in group_vars/all/main.yml). The role expects
Debian-style apt + systemd unit names.
* Profiles : `incus launch` now applies `--profile veza-app
--profile veza-net --network <veza_incus_network>` like every
other container the pipeline creates. Prevents a barebones
container that doesn't get the Veza network policy.
* Cloud-init wait : drop the `cloud-init status` poll (Debian
base image's cloud-init is minimal anyway) ; replace with a
direct `incus exec veza-haproxy -- /bin/true` reachability
loop, same pattern as deploy_data.yml's launch task.
The third play sets `haproxy_topology: blue-green` explicitly so
the edge always renders the multi-env topology, even when run
from `inventory/lab.yml` (which lacks the env-prefix vars and
would otherwise fall through to the multi-instance branch).
--no-verify justification continues to hold.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| ansible | ||
| coturn | ||
| nginx-rtmp | ||
| docker-compose.lab.yml | ||