A sealed scenario cannot install wireguard-tools any more than it can install a container runtime, so a lab without them cannot test connectivity at all -- which is most of what the mesh does between machines. Installed and not started: what a node runs is the mesh's decision, and a lab that brought the interface up itself would be testing its own setup. growing-mesh exists to be grown. The point is not the third machine, it is that adding one changes every other node's peer list -- so each has to be told again, or the newcomer is on a network nobody else can see.
34 lines
943 B
YAML
34 lines
943 B
YAML
# Three machines, joined one at a time.
|
|
#
|
|
# The point is not the third machine. It is that adding one changes **every other node's** peer
|
|
# list: each existing node has to be told again, or the newcomer is on a network nobody else can
|
|
# see. A mesh that only configures the arriving node looks like it worked and is half a network.
|
|
#
|
|
# So this scenario exists to be raised, then grown — enrol two, push, check; enrol the third,
|
|
# push, and check that the first two changed.
|
|
scenario: growing-mesh
|
|
|
|
segments:
|
|
hosting:
|
|
kind: public
|
|
cidr: [192.0.2.0/24]
|
|
|
|
machines:
|
|
anchor:
|
|
at: { segment: hosting, address: [192.0.2.10] }
|
|
inbound: allow
|
|
laptop:
|
|
at: { segment: hosting, address: [192.0.2.20] }
|
|
inbound: allow
|
|
workstation:
|
|
at: { segment: hosting, address: [192.0.2.30] }
|
|
inbound: allow
|
|
|
|
images:
|
|
- postgres:17-alpine
|
|
- cloudamqp/lavinmq:latest
|
|
- mesh-control:development
|
|
|
|
place:
|
|
all: [host, runtime]
|