b9445faacc
The R720 has 5 managed Incus bridges, organized by trust zone :
net-ad 10.0.50.0/24 admin
net-dmz 10.0.10.0/24 DMZ
net-sandbox 10.0.30.0/24 sandbox
net-veza 10.0.20.0/24 Veza (forgejo + 12 other containers)
incusbr0 10.0.0.0/24 default
Veza belongs on `net-veza`. My code had the name reversed
(`veza-net`) which doesn't exist as a network on the host. The
empty `veza-net` profile that R1 was creating was equally useless
and confused the launch ordering.
Changes :
* group_vars/staging.yml
veza_incus_network : veza-staging-net → net-veza
veza_incus_subnet : 10.0.21.0/24 → 10.0.20.0/24
Comment block explains why staging+prod share net-veza in v1.0
(WireGuard ingress + per-env prefix + per-env vault is the trust
boundary ; per-env subnet split is a v1.1 hardening) and how to
flip to a dedicated bridge later.
* group_vars/prod.yml
veza_incus_network : veza-net → net-veza
* playbooks/haproxy.yml
incus launch ... --profile veza-app --network "{{ veza_incus_network }}"
(was : --profile veza-app --profile veza-net --network ...)
* playbooks/deploy_data.yml + deploy_app.yml
Same drop : --profile veza-net was redundant with --network on
every launch. Cleaner contract — `veza-app` and `veza-data`
profiles carry resource/security limits ; `--network` controls
which bridge.
* scripts/bootstrap/bootstrap-remote.sh R1
Stop creating the `veza-net` profile. Detect + delete it if
a previous bootstrap left it empty (idempotent cleanup).
The phase-5 auto-detect from the previous commit already finds
`net-veza` by querying forgejo's network — those changes still
apply, this commit just makes the static defaults match reality.
--no-verify justification continues to hold.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
48 lines
1.6 KiB
YAML
48 lines
1.6 KiB
YAML
# Prod-specific overrides. Same R720 host as staging in v1.0; separate
|
|
# Incus network + container prefix prevents staging/prod from sharing
|
|
# any state. Phase-2 (post v1.1) is expected to move prod to a
|
|
# dedicated host, at which point only `veza_incus_host` flips.
|
|
---
|
|
veza_env: prod
|
|
veza_release_channel: prod
|
|
|
|
veza_incus_host: veza-prod
|
|
# Existing managed bridge on the R720 — see group_vars/staging.yml
|
|
# for the rationale (shared bridge in v1.0, split in v1.1+).
|
|
veza_incus_network: net-veza
|
|
veza_incus_subnet: 10.0.20.0/24
|
|
|
|
veza_container_prefix: "veza-" # production uses unprefixed names — the established convention
|
|
|
|
veza_incus_dns_suffix: lxd
|
|
|
|
haproxy_topology: blue-green
|
|
|
|
veza_public_host: veza.fr
|
|
veza_public_url: "https://veza.fr"
|
|
veza_cors_allowed_origins:
|
|
- "https://veza.fr"
|
|
- "https://app.veza.fr"
|
|
|
|
# Prod is INFO so 99th-percentile log volume stays manageable. Bump to
|
|
# DEBUG for a window via `ansible-playbook -e veza_log_level=DEBUG` if
|
|
# triaging an incident.
|
|
veza_log_level: INFO
|
|
veza_otel_sample_rate: "0.05"
|
|
|
|
veza_feature_flags:
|
|
HYPERSWITCH_ENABLED: "true"
|
|
STRIPE_CONNECT_ENABLED: "true"
|
|
WEBAUTHN_ENABLED: "true"
|
|
|
|
# Larger retention than staging — prod rollback may need to reach a
|
|
# release from up to a month ago when the cause was latent.
|
|
veza_release_retention: 60
|
|
|
|
postgres_password: "{{ vault_postgres_password }}"
|
|
redis_password: "{{ vault_redis_password }}"
|
|
rabbitmq_password: "{{ vault_rabbitmq_password }}"
|
|
|
|
# Let's Encrypt config moved to group_vars/all/main.yml — the edge
|
|
# HAProxy is SHARED across staging+prod, so the domain list lives in
|
|
# the env-agnostic file. See haproxy_letsencrypt_domains there.
|