Scores own deploy. harmony_app is identity, images, context, and HarmonyApp→Scores. Authoring DX lives in dx. Compose/chart/Application model and the Helm render test are gone.
65 lines
3.0 KiB
Markdown
65 lines
3.0 KiB
Markdown
# harmony_app
|
|
|
|
Application delivery. A [`HarmonyApp`](src/app.rs) composes **Scores**; `ship` /
|
|
`deploy` / `status` / `logs` are glue that interpret them. This crate does **not**
|
|
orchestrate infrastructure — that is [`harmony`](../harmony).
|
|
|
|
## Architecture
|
|
|
|
| Crate | Job |
|
|
|---|---|
|
|
| **`harmony_cli`** | UI only. Parse argv, require `--context`, call verbs, render. Safe types and DX (digest-shaped flags, `--json`). No Scores, no image policy, no cluster mutation. |
|
|
| **`harmony_app`** | Application delivery: identity, image build/publish, context catalog, `HarmonyApp` → Scores, ship/deploy as interpret glue. Authoring DX in [`dx`](src/dx.rs) (one component, one file, one type). |
|
|
| **`harmony`** | Source of truth for infrastructure orchestration. Scores (desired state), Topologies (where), Interpret (how). Deploying Kubernetes resources, running containers, building the deployment model and applying it on a topology (k8s or otherwise). |
|
|
| **`harmony_config`** | Load, save, discover settings and secrets. Schema is Rust; state is a store. Default store is OpenBao (CNCF). |
|
|
|
|
Identity is one SSO (`https://sso.nationtech.io`). That identity is what may
|
|
read the tenant's config and environment in OpenBao, the OKD cluster, Harbor,
|
|
and later more.
|
|
|
|
**SSO is still WIP for Harbor and OKD.** Access secrets for those live in
|
|
OpenBao, which *is* SSO. Current flow:
|
|
|
|
1. Load one secret: `HARMONY_ZITADEL_KEY_JSON` (or `HARMONY_ZITADEL_KEY_PATH`).
|
|
2. Authenticate to OpenBao (JWT-bearer against Zitadel).
|
|
3. Load Harbor and kubeconfig from OpenBao.
|
|
4. Authenticate to Harbor and Kubernetes with those secrets.
|
|
|
|
Interactive humans use device-code OIDC to the same OpenBao instead of a
|
|
machine key. Same store, different first hop.
|
|
|
|
`--context` is required (or `HARMONY_CONTEXT`). There is no default.
|
|
|
|
`K8sAnywhereTopology` on `app_main` / `AppContext::topology()` is the
|
|
**control plane** (kube apply — including Fleet CRs). It is not a claim that
|
|
the workload runs on Kubernetes.
|
|
|
|
## Crate map
|
|
|
|
**UI:** `harmony_cli`, `harmony_tui`, `harmony_auth_cli`, `harmony_auth_ui`
|
|
|
|
**Application delivery:** `harmony_app`
|
|
|
|
**Orchestration:** `harmony`, `harmony-k8s`, `harmony-reconciler-contracts`,
|
|
`harmony_execution`, `k3d`, `fleet/*`
|
|
|
|
**Config & secrets:** `harmony_config`, `harmony_config_derive`, `harmony_secret`,
|
|
`harmony_secret_derive`
|
|
|
|
**Identity:** `harmony_zitadel_auth`, `harmony_zitadel_jwt`, `harmony_auth`
|
|
|
|
**Shared types:** `harmony_types`, `harmony_macros`
|
|
|
|
Infra-specific crates (OPNsense, NATS, agents, Brocade, …) live under `harmony`
|
|
modules or their own crates; they are Scores/topologies, not app delivery.
|
|
|
|
## Remaining leaks (honest)
|
|
|
|
- `status` / `logs` list Kubernetes Deployments/Pods via the control-plane
|
|
client. Operational verbs are allowed to read the cluster (ADR-026); they are
|
|
not yet Score-status.
|
|
- `harmony_cli::run` is a second frontend: a generic Score runner over Maestro.
|
|
Still UI. Not application delivery.
|
|
- `dx::Secret` is a stub. Secrets today are OpenBao-backed config structs, not
|
|
a `Secret<T>` field type.
|