jschoubben
bdc9c436b4
Found by raising a mesh end to end for the first time. Enrolment's own help says the token "is the only thing it needs", and it also needed --name, with no default. Without it the failure is: cannot reach the broker at 192.0.2.10:5671 as : username or password not allowed An empty username, and nothing about the cause. The node cannot work its own name out. The broker account it authenticates as is named after it and exists before this machine has been told anything, so the name has to arrive with the rest. It is not a secret and the issuer already knows it. --name stays, as an override for a token issued before the name travelled in one, and says so when it is needed rather than failing at the broker. Also corrects the bundle example, which claimed to stop before the control plane runs and has raised one for some time. A comment about what something does not do is a comment nobody updates.
53 lines
2.3 KiB
Markdown
53 lines
2.3 KiB
Markdown
# Examples
|
|
|
|
## `substrate-first-node.lock`
|
|
|
|
What a machine must be before a mesh exists — the bootstrap in
|
|
[novox/hq `07-the-substrate.md`](https://git.novox.be/novox/hq), whole:
|
|
|
|
```
|
|
0 a container runtime
|
|
1 the store runs
|
|
2 a database per context `inventory` and `identity`
|
|
3 those contexts' schemas mesh-control migrate
|
|
4 the broker runs with a certificate it generated itself
|
|
5 the control plane runs mesh-control serve
|
|
```
|
|
|
|
**A machine that applies this is a mesh** — one node, with nothing joined to it yet, which is
|
|
exactly what the first node is (novox/hq ADR 0004). From here it hands out tokens and everything
|
|
else joins the ordinary way.
|
|
|
|
This file said it stopped at step 4 for longer than that was true, which is its own small lesson:
|
|
a comment about what something does not do is a comment nobody updates.
|
|
|
|
Build a host carrying it:
|
|
|
|
```
|
|
make host SYSTEM=arch BUNDLE=examples/substrate-first-node.lock
|
|
```
|
|
|
|
**The registry address and digests have to be replaced before this is useful.** They are written
|
|
as `192.0.2.250:5000/…@sha256:…` because a digest belongs to whatever registry serves it — here,
|
|
one a lab scenario raises, which reports its digests when it comes up. That is not a placeholder
|
|
to be tidied away: a bundle is built *for a target*, and which registry that target pulls from is
|
|
part of the target.
|
|
|
|
### What was verified, and how
|
|
|
|
On a lab machine confirmed sealed — `curl https://example.com` times out, the lab registry answers
|
|
200 — the whole bundle applied from bare: eight resources, `inventory` created and `mesh` nowhere,
|
|
the `node` table present with its indexes, the migration recorded, and LavinMQ answering
|
|
`lavinmqctl status` with AMQP listening on 5672.
|
|
|
|
Three consecutive reconciles after that: **already matches — 8 resource(s) checked**, each time.
|
|
|
|
Then the machine was **rebooted**, and everything came back: docker from `boot: enabled`, both
|
|
containers because the host creates every container `--restart unless-stopped`
|
|
(`internal/apply/apply.go`), the schema intact in its named volume, and reconcile still finding
|
|
nothing to do.
|
|
|
|
The reboot is worth doing rather than assuming. Nothing in the declaration asks for a container to
|
|
return, so that it does is a property of the host, and the only way to know it holds is to take
|
|
the machine away and give it back.
|