Ben Vincent 17ded87439
ci/woodpecker/pr/build Pipeline was successful
ci/woodpecker/pr/test Pipeline was successful
ci/woodpecker/pr/pre-commit Pipeline was successful
pdbmux: ship as k8s container, drop per-VM systemd/RPM delivery
The estate direction is all-in-kubernetes, so pdbmux (a long-running daemon)
should run as an in-cluster service rather than an RPM-installed systemd unit
on each VM. The RPM is for workstation/VM CLI tools only; a daemon does not
belong there.

- Remove packaging/pdbmux.service and drop pdbmux (binary, systemd unit,
  completions) from the RPM/nfpm spec and build-rpm.sh.
- Keep pdbmux in the Makefile build and the test suite.
- Add Dockerfile.pdbmux building a static CGO_ENABLED=0 binary on distroless
  (mirrors encapi's image style).
- Add .woodpecker/docker.yaml to build+push git.unkin.net/unkin/pdbmux:<tag>
  on v* tags via the docker-buildx plugin (droneci/DRONECI_PASSWORD creds,
  same as encapi), with k8s resources set.
- Update README/AGENTS.md: deployment is k8s, config via PDBMUX_* env.
2026-07-24 23:09:46 +10:00

node-lookup tools

PuppetDB CLIs plus one proxy daemon.

The CLIs ship together in a single RPM for workstations/VMs:

  • node-lookup — query and filter PuppetDB node facts.
  • pburl — print each host's Puppetboard node-page URL.
  • pblastreport — print each host's last Puppet report time + Puppetboard URL.

The proxy daemon is deployed to Kubernetes as a container image (not in the RPM):

  • pdbmux — merging HTTP proxy over two PuppetDBs (see below).

See AGENTS.md for the CLI tools' flags, config, and internals. This README covers pdbmux.


pdbmux — merging PuppetDB proxy

What

pdbmux is a small HTTP daemon that fronts two PuppetDB backends and serves a single, merged PuppetDB v4 query surface on one address. Point node-lookup, pblastreport, or anything else at pdbmux instead of a raw PuppetDB and it sees one consistent view spanning both.

Why

During the VM→k8s Puppet migration there are two PuppetDBs:

  • old — the legacy Consul-registered http://puppetdbapi.service.consul:8080
  • new — the k8s https://puppetdb.k8s.syd1.au.unkin.net (TLS terminated at the gateway; backends are plain PuppetDB on 8080)

Nodes move from old to new as they migrate, so at any moment a given node's current data lives in exactly one of them. pdbmux merges both so consumers don't have to know (or query twice) which PuppetDB a node currently lives in.

Endpoints

pdbmux proxies GET requests only. The query param (PuppetDB AST JSON, not PQL) is forwarded verbatim.

Path Behaviour
GET /pdb/query/v4/nodes Fan out to both backends, dedupe by certname, keep the record with the newer report_timestamp.
GET /pdb/query/v4/facts Fan out to both, and per certname keep all facts from the backend that owns that node (see merge semantics).
GET /pdb/query/v4/* (any other) Transparently proxied to the primary backend, unmerged, streamed verbatim.
GET /healthz Per-backend reachability. 200 {"status":"ok"} if all reachable, 200 degraded if some fail, 503 down if all fail.

Fan-out is concurrent. If one backend errors or times out, pdbmux serves the survivor's results and logs a warning; a merged endpoint only returns 502 when every backend fails. Response records are passed through as raw JSON so unknown fields survive untouched.

Merge semantics

  • /nodes — dedupe by certname; the record with the strictly-newer report_timestamp wins. On a tie (or when a node exists in only one backend), the preferred backend's record is kept.
  • /facts — node-level granularity. For a certname present in both backends, pdbmux keeps all of that node's facts from one backend and drops the other's, chosen by the merge strategy:
    • freshness (default) — attribute each certname to whichever backend holds its newer report_timestamp. pdbmux derives this from a per-certname freshness map built by querying /nodes from both backends, cached for freshness_ttl (default 30s). Ties/fallbacks use prefer.
    • static — always keep the prefer backend's facts for shared nodes. No extra /nodes query.
    • A node present in only one backend always appears (falls back to whichever backend actually returned facts for it).

Config

Precedence (lowest → highest): defaults < config file < env vars (PDBMUX_*) < flags.

Config file: $XDG_CONFIG_HOME/pdbmux/config.yaml. In Kubernetes, configuration is supplied entirely via PDBMUX_* env vars (no config file), which is the supported deployment path — see Deployment.

# ~/.config/pdbmux/config.yaml  (local dev; in k8s use PDBMUX_* env instead)
listen: ":8080"
backends:
  - name: old
    url: http://puppetdbapi.service.consul:8080
  - name: new
    url: https://puppetdb.k8s.syd1.au.unkin.net
primary: new          # backend used for non-merged /pdb/query/v4/* pass-through
merge: freshness      # freshness | static
prefer: new           # winner on ties / static merge / fallback
timeout: 10s          # per-upstream request timeout
freshness_ttl: 30s    # freshness-map cache TTL (freshness merge only)

backends[*].url is a base URL (scheme://host[:port]), without the /pdb/query/v4/... path — pdbmux appends the path per request.

Env var Overrides
PDBMUX_LISTEN listen
PDBMUX_PRIMARY primary
PDBMUX_MERGE merge
PDBMUX_PREFER prefer
PDBMUX_TIMEOUT timeout (Go duration, e.g. 10s)
PDBMUX_FRESHNESS_TTL freshness_ttl
PDBMUX_BACKENDS whole backend list, as name=url,name=url

Flags: --listen, --primary, --merge.

Running

pdbmux                 # start the proxy (serve is the default action)
pdbmux serve           # explicit
pdbmux config init     # write a default config file
pdbmux config show     # print active config after all overrides
pdbmux version

Point a consumer at it:

node-lookup --url http://localhost:8080/pdb/query/v4/facts -R
NODE_LOOKUP_URL=http://localhost:8080/pdb/query/v4/facts pblastreport somehost

Deployment

pdbmux runs in Kubernetes as a container, in line with the all-in-k8s estate direction — it is not shipped as a per-VM RPM/systemd service. The image is built and pushed on every v* tag (.woodpecker/docker.yaml) to:

git.unkin.net/unkin/pdbmux:<tag>

It is a minimal static (CGO_ENABLED=0) binary on a distroless base (Dockerfile.pdbmux), configured entirely via PDBMUX_* env vars, with a single HTTP listener and /healthz for liveness/readiness probes.

The Deployment/Service/Gateway manifests live in the estate's argocd-apps repo under apps/base/pdbmux/ (namespace pdbmux, 2 replicas), and it is exposed to VM/workstation node-lookup consumers over HTTPS at:

https://pdbmux.k8s.syd1.au.unkin.net

Locally you can still run the binary directly for development:

PDBMUX_BACKENDS='old=http://puppetdbapi.service.consul:8080,new=http://puppetdb.puppet.svc.cluster.local:8080' \
  pdbmux serve
curl -s localhost:8080/healthz
S
Description
A CLI tool written in Go that queries the PuppetDB API to look up and filter node facts.
Readme 297 KiB
v0.5.7 Latest
2026-08-15 14:50:35 +10:00
Languages
Go 93.6%
Makefile 3.9%
Shell 2.5%