Solutions provisioner
A control panel that runs the industry solutions rather than being one of them. It starts and stops each solution, connects to a Litmus Edge once instead of once per solution, and provisions or removes each one from its own card.
Use it when you want to show more than one solution, or to switch between them without editing compose files. Every solution also runs perfectly well on its own, so this is a convenience rather than a requirement.
Operator view | port 4009 |
|---|---|
Devices and tags | controls fifteen solutions |
Image | solgen-provisioner |
Scenarios
- One Edge connection for the whole set. Enter the address and token once. The panel verifies them and every solution it starts inherits them.
- Provisioning and removal as a control, not a command. Each card carries Deploy and Clean up, both with a preview that shows what would change before anything is written to the Edge.
- Deployment onto the Edge itself. The panel can ask the connected Edge to pull and run a solution through the Edge's own Applications API, using the registry credentials the device already holds.
Requirements
Everything in Industry vertical solutions, plus one thing specific to the panel: it needs access to the host Docker socket, because it starts each solution as a sibling container so their ports land on the host.
That is a real grant of authority to a container. It is how a control panel of this kind has to work, and it is worth knowing before you run it.
Deploy
Download solgen-provisioner-0.6.1-amd64.tar.gz from the solution's page on portal.litmus.io. The archive is the container image, not a source bundle, and needs no registry access.
docker load -i solgen-provisioner-0.6.1-amd64.tar.gzdocker load prints the image it added, which is the one the files below name:
Loaded image: us-docker.pkg.dev/litmus-customer-facing/litmus-solutions/solgen-provisioner:0.6.1Save this as docker-compose.yml:
services:
provisioner:
image: us-docker.pkg.dev/litmus-customer-facing/litmus-solutions/solgen-provisioner:0.6.1
container_name: solgen-provisioner
restart: unless-stopped
ports:
- target: 4009
published: 4009
protocol: tcp
environment:
PROBE_HOST: host.docker.internal
RUNNER: docker
LOG_LEVEL: info
EDGE_URL: "${EDGE_URL:-}"
EDGE_API_TOKEN: "${EDGE_API_TOKEN:-}"
EDGE_VERIFY_TLS: "${EDGE_VERIFY_TLS:-0}"
SOLGEN_REGISTRY:
SOLGEN_IMAGE_TAG:
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- provisioner-state:/data
extra_hosts:
- "host.docker.internal:host-gateway"
volumes:
provisioner-state: {}docker compose up -dThen open http://localhost:4009.
Nothing needs filling in to start it. The panel asks for the Litmus Edge address and a token, verifies them, and stores them itself. The two EDGE_ values above only let you skip that step.
To run it without Compose, the two volumes below are not optional. The panel starts each solution as a sibling container on the host's own daemon, so it needs the socket, and it keeps the Edge connection and the logs in /data, so it needs the volume.
docker run -d \
--name solgen-provisioner \
--restart unless-stopped \
-p 4009:4009 \
-v /var/run/docker.sock:/var/run/docker.sock \
-v provisioner-state:/data \
us-docker.pkg.dev/litmus-customer-facing/litmus-solutions/solgen-provisioner:0.6.1Flag | Required | Without it |
|---|---|---|
-v /var/run/docker.sock:... | yes | the panel cannot start, stop or pull anything, and every card reads missing |
-v provisioner-state:/data | yes | the Edge connection and every log are lost on each restart |
--add-host and PROBE_HOST | no | only affects solutions the panel did not start itself |
The panel reaches a solution it started at that container's own address on the docker network, so it needs no route back through the host. PROBE_HOST is the address it uses for anything it did not start, such as a solution already running on the host when the panel came up, and it defaults sensibly.
EDGE_URL and EDGE_API_TOKEN are optional: pass them to skip the connect step, or leave them out and connect from the page, which stores them in /data/.env. SIM_HOST does not apply to the panel; each solution derives its own.
SOLGEN_REGISTRY and SOLGEN_IMAGE_TAG are optional and only needed to point at a different registry or tag. Leave them out rather than setting them empty: an empty SOLGEN_REGISTRY means "use local image names" and makes every card resolve to an image no host can pull.
Configuration
Variable | Default | What it does |
|---|---|---|
EDGE_URL | unset | Litmus Edge to connect to. Optional; the panel can ask instead |
EDGE_API_TOKEN | unset | token for that Edge |
EDGE_VERIFY_TLS | 0 | 1 checks the Edge's certificate |
PROBE_HOST | host.docker.internal | where the panel looks for the solutions it started. From inside a container, 127.0.0.1 is the container itself, so this must name the host |
RUNNER | auto | docker or source. Which way to start solutions |
SOLGEN_REGISTRY | the published repository | where to pull solution images from |
SOLGEN_IMAGE_TAG | 0.6.1 | which tag to run |
SOLGEN_REGISTRY and SOLGEN_IMAGE_TAG are written without a value on purpose. Compose leaves a variable absent when it has no value, which lets the default apply. Giving them an empty string instead would mean something different and the panel would look for images that do not exist.
Operator view
The page is three parts.
Litmus Edge, at the top: what you are connected to, whether it is answering, and how recently that was checked.
Litmus Unify, under it, optional: Unify's address, a username and a password, saved only after they log in and passed to every solution the panel starts. Pair the Edge gives the connected Litmus Edge one Litmus UNS connector, industry-verticals, and Unpair the Edge removes it and the Unify account it joined as. With both in place, a solution's next Deploy publishes its twins into Unify and its Clean up removes them again. If the Edge reaches Unify by a different address than this machine does, set Address the Edge dials to that address.
Solutions, a card each: a switch to start and stop it, what it puts on the Edge, the scenarios it demonstrates, a link to its operator view, and Deploy and Clean up controls with previews.
Team solutions, below: the published Litmus solutions catalogue joined against the container registries this machine can read, so what is published and what you could actually run here are one view rather than two. Solutions this machine has no credential for are greyed out rather than shown as errors.
Limitations
A solution that is more than one container cannot be started as a single container, and the panel says so on the card rather than offering a button that cannot work. Rotating equipment reliability is the one this affects: it needs a message broker alongside it, so it is deployed with its own compose file.
If a card does not go green
What the card says | What it means | What to do |
|---|---|---|
missing, naming an image | the image is not on this host | press Pull, or Run on Edge to let the Edge fetch it, or docker load the archive |
a pull fails with Unauthenticated request | the host has no credential for the registry | docker load the solution's archive, or Run on Edge, which uses the Edge's own credential |
starting, and it stays there | the solution is up but not answering /health | open its Log on the card; the container's own output is there |
started before an Edge was connected | it is running without credentials and cannot be told after the fact | stop it and start it again, and it inherits the connection |
the solution's page shows its waiting panel | Litmus Edge does not carry that solution's devices yet | press Deploy on the card, or Apply to Edge on the solution's own page |
Connect the Litmus Edge before switching a solution on. Each one is handed the connection when its container starts, so one started first comes up with nothing to talk to.
Apply and remove
docker compose downSolutions the panel started keep running, deliberately, so restarting the panel does not interrupt a demonstration. Stop them from their cards first if you want them to go too.