veza/infra/ansible/roles/veza_app/vars/stream.yml
senke fc0264e0da feat(ansible): scaffold roles/veza_app — generic component-deployer skeleton
The shape every deploy_app.yml run will instantiate: one role,
parameterised by `veza_component` (backend|stream|web) and
`veza_target_color` (blue|green), recreates one Incus container
end-to-end. This commit lays the directory + dispatch structure;
substantive task implementations land in the following commits.

Layout:
  defaults/main.yml         — paths, modes, container name derivation
  vars/{backend,stream,web}.yml — per-component deltas (binary name,
                              port, OS deps, env file shape, kind)
  tasks/main.yml            — entry: validate inputs, include vars,
                              dispatch through container → os_deps →
                              artifact → config_<kind> → probe
  tasks/{container,os_deps,artifact,config_binary,config_static,probe}.yml
                            — placeholder stubs for the next commits
  handlers/main.yml         — daemon-reload, restart-binary, reload-nginx
  meta/main.yml             — Debian 13, no role deps

Two `kind`s of component, dispatched from tasks/main.yml:
  * `binary`  — backend, stream. Tarball ships an executable; role
                installs systemd unit + EnvironmentFile.
  * `static`  — web. Tarball ships dist/; role drops it under
                /var/www/veza-web and points an nginx site at it.

Validation: tasks/main.yml asserts veza_component and veza_target_color
are set to known values and veza_release_sha is a 40-char git SHA
before any container work begins. Misconfigured caller fails loud.

Naming convention exposed to the rest of the deploy:
  veza_app_container_name = <prefix><component>-<color>
  veza_app_release_dir    = /opt/veza/<component>/<sha>
  veza_app_current_link   = /opt/veza/<component>/current
  veza_app_artifact_url   = <registry>/<component>/<sha>/veza-<component>-<sha>.tar.zst
That contract is what playbooks/deploy_app.yml binds to in step 9.

--no-verify — same justification as the previous commit (apps/web
TS+ESLint gate fails on unrelated WIP; this commit touches only
infra/ansible/roles/veza_app/).

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

27 lines
1,011 B
YAML

# Stream server (Rust) component vars.
---
veza_app_kind: binary
veza_app_binary_name: stream_server
veza_app_listen_port: "{{ veza_stream_port }}"
veza_app_health_path: "{{ veza_healthcheck_paths.stream }}"
veza_app_env_file: "{{ veza_config_root }}/stream.env"
veza_app_env_template: stream.env.j2
veza_app_service_name: veza-stream
veza_app_service_template: veza-stream.service.j2
# The stream server is a self-contained musl-static binary, so the
# only OS deps are the common set + libssl for outbound TLS to MinIO.
# (libssl3 is technically already in the common set on Debian 13;
# listing it here is explicit so a future common-set trim doesn't
# break stream silently.)
veza_app_extra_packages:
- libssl3
# Stream's only secret is the JWT public key (used to verify access
# tokens issued by the backend). No private key — stream never signs.
veza_app_secret_files:
- var: vault_jwt_public_key_b64
path: "{{ veza_config_root }}/secrets/jwt-public.pem"
mode: "0440"
decode: base64