plug
Run a local process as if it were inside your cluster: prefix any command
with plug and it resolves the cluster DNS and reaches the cluster services like
any workload of the stack - no code change, no proxy configuration in your app. One
tiny agent container on the cluster side, one static CLI on yours. Docker, Swarm, Kubernetes
and OpenShift.
Meerkat
Meerkat is an app-gateway that drives plug. Its Enterprise edition integrates the two, and what it adds is an identity: sessions stop being anonymous.
Who is plugged in, by name
On its own, plug lets in whoever reaches the agent, or, by approval, the keys its members
accepted. Through Meerkat, a developer holding the
dev ability deposits their own public key, which is tied to
their name and known to the agent. They then authenticate on the agent's port, download the
CLI and open sessions as themselves - every session attributed to a person the gateway
knows, with the rights it gives them.
That changes what the cluster can tell you. A plugged service is already a shared state: whoever enters the cluster uses the services as they currently are, and someone's laptop may well be answering for one of them. Meerkat does not create that situation - it makes it visible and attributed: which service is plugged, and by whom. Everyone signing in to the application is told before it opens, and a strip says it again on every page, live. A bug report can then say which code answered, rather than guess.
Who may plug at all
Consumption of that state is indiscriminate: there is no role for the reader, because everyone reads the same cluster. The control is on who may produce it, and the gateway decides it the same way on every installation, a production one included:
- Per installation, two switches, two owners. The application's administrator turns on developer mode; the infrastructure administrator opens the developer tunnel, which ships closed. The tunnel runs only when both are on, and while it is closed a developer is not even offered a key to deposit.
-
Per person. The
devability is what lets someone deposit a key and plug at all. Removing the key, the ability or either switch closes the door at the next connection: nothing was issued that would outlive it.
One name, one session stays the rule, as it is without Meerkat: a name already taken is refused rather than shared. What Meerkat changes is that the refusal can say who holds it.
The hosted CLI
A gateway that embeds the agent serves its own flavour of the CLI, published alongside the standalone one and signed the same way:
softwarity/plug:<version> # standalone: the agent you deploy yourself
softwarity/plug:<version>-hosted # for a gateway that embeds the agentThe hosted flavour carries key enrolment and leaves updates to the gateway, which owns the version it serves. Everything else - the CLI, the data path, the security model - is the same plug, so nothing you learn here has to be relearned there. How a gateway embeds the agent is on the Integration page.
Installing it ends with the one step a gateway requires: the machine's own key. The install command the gateway shows names the profile after its application, and the installer says what to run, then where the key goes, in the gateway's own words:
plug: this cluster lets in only the keys it knows. Give this machine its own, once:
plug keygen -p my-app
plug pubkey -p my-app
and register the key it prints in your dev profileThis page is a summary and will grow. See the Meerkat documentation for the gateway itself, and the Roadmap for what is still ahead.