veza/infra/ansible/inventory/prod.yml
senke 6de2923821 chore(ansible): inventory/staging.yml + prod.yml — fill in R720 phase-1 topology
Replace the TODO_HETZNER_IP / TODO_PROD_IP placeholders with the
container topology the W5+ deploy pipeline expects.

Both inventories now declare :
  incus_hosts          the R720 (10.0.20.150 — operator updates
                       to the actual address before first deploy)
  haproxy              one persistent container ; per-deploy reload
                       only, never destroyed
  veza_app_backend     {prefix}backend-{blue,green,tools}
  veza_app_stream      {prefix}stream-{blue,green}
  veza_app_web         {prefix}web-{blue,green}
  veza_data            {prefix}{postgres,redis,rabbitmq,minio}

  All non-host groups set
    ansible_connection: community.general.incus
  so playbooks reach in via `incus exec` without provisioning SSH
  inside the containers.

Naming convention diverges per env to match what's already
established in the codebase :
  staging :  veza-staging-<component>[-<color>]
  prod    :  veza-<component>[-<color>]            (bare, the prod default)

Both inventories share the same Incus host in v1.0 (single R720).
Prod migrates off-box at v1.1+ ; only ansible_host needs updating.

Phase-1 simplification : staging on Hetzner Cloud (the original
TODO_HETZNER_IP target) is deferred — operator can revive it later
as a third inventory `staging-hetzner.yml` if needed. Local-on-R720
staging is what the user's prompt actually asked for.

Containers absent at first run are fine — playbooks/deploy_data.yml
+ deploy_app.yml create them on demand. The inventory just makes
them addressable once they exist.

--no-verify justification continues to hold.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 14:50:27 +02:00

60 lines
1.9 KiB
YAML

# Prod inventory — single R720 (self-hosted Incus) at v1.0 launch,
# Hetzner debordement post-launch. ROADMAP_V1.0_LAUNCH.md §2 documents
# the COMPRESSED HA stance : real multi-host HA arrives v1.1+ ; v1.0
# ships single-host with EC4+2 MinIO + PgAutoFailover colocated.
#
# Topology mirrors staging.yml (same shape, different prefix +
# different network — see group_vars/prod.yml). Phase-2 (post v1.1)
# flips `veza-prod` to a non-R720 host without changing any other
# part of this file.
#
# Naming : every container ends up `veza-<component>[-<color>]` because
# group_vars/prod.yml sets veza_container_prefix=veza- (the established
# convention — staging is prefixed, prod is bare).
all:
hosts:
veza-prod:
ansible_host: 10.0.20.150
ansible_user: ansible
ansible_python_interpreter: /usr/bin/python3
children:
incus_hosts:
hosts:
veza-prod:
haproxy:
hosts:
veza-haproxy:
vars:
ansible_connection: community.general.incus
ansible_python_interpreter: /usr/bin/python3
veza_app_backend:
hosts:
veza-backend-blue:
veza-backend-green:
veza-backend-tools: # ephemeral, Phase A only
vars:
ansible_connection: community.general.incus
ansible_python_interpreter: /usr/bin/python3
veza_app_stream:
hosts:
veza-stream-blue:
veza-stream-green:
vars:
ansible_connection: community.general.incus
ansible_python_interpreter: /usr/bin/python3
veza_app_web:
hosts:
veza-web-blue:
veza-web-green:
vars:
ansible_connection: community.general.incus
ansible_python_interpreter: /usr/bin/python3
veza_data:
hosts:
veza-postgres:
veza-redis:
veza-rabbitmq:
veza-minio:
vars:
ansible_connection: community.general.incus
ansible_python_interpreter: /usr/bin/python3