58 lines
2.9 KiB
Markdown
58 lines
2.9 KiB
Markdown
|
# `veza_app` role
|
||
|
|
|
||
|
|
Generic, parameterized role that deploys ONE Veza application
|
||
|
|
component (`backend`, `stream`, or `web`) into a freshly-recreated
|
||
|
|
Incus container, then probes its health endpoint. Driven from
|
||
|
|
`playbooks/deploy_app.yml` once per component, per blue/green color
|
||
|
|
in a deploy run.
|
||
|
|
|
||
|
|
## Why one role for three components?
|
||
|
|
|
||
|
|
The 80% of work is the same for each:
|
||
|
|
|
||
|
|
1. Recreate the Incus container from a profile (`incus delete --force`
|
||
|
|
then `incus launch`).
|
||
|
|
2. Apt-install OS deps.
|
||
|
|
3. Pull the release tarball from the Forgejo Package Registry, extract.
|
||
|
|
4. Render the env file from Vault-backed variables.
|
||
|
|
5. Install a systemd unit (or, for `web`, an nginx site config).
|
||
|
|
6. Start the service and probe its health endpoint.
|
||
|
|
|
||
|
|
The 20% deltas (binary name, port, OS deps, env-file shape, kind:
|
||
|
|
binary vs static) live in `vars/<component>.yml`.
|
||
|
|
|
||
|
|
## Inputs
|
||
|
|
|
||
|
|
The caller (playbook) is expected to set:
|
||
|
|
|
||
|
|
| variable | required | meaning |
|
||
|
|
| ----------------------- | -------- | ----------------------------------------------------------------------------- |
|
||
|
|
| `veza_component` | yes | One of `backend`, `stream`, `web`. Drives `vars/<component>.yml` lookup. |
|
||
|
|
| `veza_target_color` | yes | `blue` or `green`. The role recreates `<prefix><component>-<color>`. |
|
||
|
|
| `veza_release_sha` | yes | Full git SHA of the release. Names the tarball + the install dir. |
|
||
|
|
| `veza_container_prefix` | inherit | From `group_vars/<env>.yml`. e.g. `veza-staging-` or `veza-`. |
|
||
|
|
| `veza_incus_host` | inherit | Inventory host that runs `incus exec`. |
|
||
|
|
|
||
|
|
Other parameters fall through `defaults/main.yml` (overridable per env
|
||
|
|
in `group_vars/<env>.yml`).
|
||
|
|
|
||
|
|
## What the role does NOT do
|
||
|
|
|
||
|
|
- Switch HAProxy. That's the `veza_haproxy_switch` role, run after
|
||
|
|
health probes pass for ALL three components.
|
||
|
|
- Run database migrations. Those run once per deploy in a separate
|
||
|
|
ephemeral `<prefix>backend-tools` container, before any color is
|
||
|
|
recreated. See `playbooks/deploy_app.yml` Phase A.
|
||
|
|
- Touch data containers (postgres, redis, rabbitmq, minio). Those
|
||
|
|
go through `playbooks/deploy_data.yml`, with their own roles.
|
||
|
|
|
||
|
|
## Component matrix
|
||
|
|
|
||
|
|
| | backend (binary) | stream (binary) | web (static) |
|
||
|
|
| ------------ | ----------------- | ----------------------- | ------------------------ |
|
||
|
|
| binary | `veza-api` | `stream_server` | n/a — nginx serves dist |
|
||
|
|
| port | 8080 | 8082 | 80 |
|
||
|
|
| health path | `/api/v1/health` | `/health` | `/` |
|
||
|
|
| extra deps | postgresql-client | (libssl3 in common set) | nginx |
|
||
|
|
| service unit | yes (systemd) | yes (systemd) | no (nginx as systemd dep)|
|