jschoubben
f03647d605
A scenario and integration test assign route-proxy (provider) and hello-web (consumer) on one node, then assert a request to the consumer's name -- sent to the proxy -- is forwarded to the workload and returns its answer, and that unassigning the consumer withdraws the route so the same request stops working (the proxy replaces its table rather than merging). Modeled on mesh-grant-end-to-end and schedule-tick: module add, assign, one push, settled, with no module issue (route-proxy needs no scoped account). build-route-proxy-image.sh compiles the Go proxy from mesh-control/examples/route-proxy into mesh-route-proxy:development for the scenario to stock. This bed proves route-forwarding over plain HTTP; public-ACME TLS is proven separately by certificates.test.ts against a real ACME server. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
50 lines
2.4 KiB
YAML
50 lines
2.4 KiB
YAML
# One machine that becomes a mesh and is then assigned the route-proxy provider and a hello-web
|
|
# consumer — the bed that proves route-forwarding end to end (novox/hq ADR 0007,
|
|
# 08-connectivity §3 Exposure).
|
|
#
|
|
# **A route is a grant.** hello-web `requires: route` and contributes the name it wants and the port
|
|
# it listens on; route-proxy `provides: route`, is given every consumer as a file the mesh writes
|
|
# (`receives.route`), and forwards by the request's `Host` header to where the mesh says that
|
|
# consumer is. The sharp point this bed proves, straight from 08-connectivity §3's "Checked in the
|
|
# lab": a request to the consumer's name, sent to the proxy, reaches the workload and returns the
|
|
# workload's own answer — then unassigning the consumer withdraws the route and the same request
|
|
# stops working (the proxy replaces its table rather than merging).
|
|
#
|
|
# This bed proves the ROUTE-FORWARDING half over plain HTTP. The public-ACME/TLS half — ordering a
|
|
# publicly-trusted certificate and answering an HTTP-01 challenge at the name — is proven separately
|
|
# by certificates.test.ts against a real ACME server (Pebble), driving the same proxy binary.
|
|
#
|
|
# MESH_LAB_HOST_BINARY=.../mesh-host MESH_LAB_BUNDLE=.../examples/substrate-first-node.lock
|
|
# scripts/build-route-proxy-image.sh builds mesh-route-proxy:development into the local daemon
|
|
# (from mesh-control/examples/route-proxy, via mesh-catalog/modules/route-proxy/Dockerfile).
|
|
# alpine:latest must be in the local daemon — hello-web's backend is a bare alpine that serves a
|
|
# fixed page over a busybox nc loop. Both images are stocked and served by digest.
|
|
scenario: route-forwarding
|
|
|
|
segments:
|
|
hosting:
|
|
kind: public
|
|
cidr: [192.0.2.0/24]
|
|
|
|
machines:
|
|
anchor:
|
|
at: { segment: hosting, address: [192.0.2.10] }
|
|
inbound: allow
|
|
memory: 3GiB
|
|
cpus: 2
|
|
|
|
images:
|
|
# The first-node substrate: store, broker, control.
|
|
- postgres:17-alpine
|
|
- cloudamqp/lavinmq:latest
|
|
- mesh-control:development
|
|
# The route-proxy's image, built from the canonical Go proxy in mesh-control by
|
|
# scripts/build-route-proxy-image.sh, and hello-web's backend, a bare alpine nc loop.
|
|
- mesh-route-proxy:development
|
|
- alpine:latest
|
|
|
|
place:
|
|
# Only the host — neither module carries a mesh-runtime. Both service images are served by the
|
|
# scenario's registry and pulled by the host, not placed inside the machine.
|
|
all: [host]
|