Running the realm
Velrix is made of modules, each running in its own container on one or more of your servers. Manager › Realm shows all of them. When the web client itself can’t be reached, the console on each server does the same job.
Manager › Realm
Open Realm in the Manager. Seeing it needs the platform settings permission; restarting, stopping and starting modules needs the permission to run them. Without it, the window is read-only.
- Modules lists every server (instance) and the modules it runs, with each one’s state, version, uptime and restarts. A module that crashed again and again is shown as Held after crashing.
- Choose a module to see its details and its log lines, live, and to Restart, Stop or Start it. With a logs module running, a module’s lines are kept there like any workload’s.
- Replicas shows each module’s copies: on which servers it runs, how many are running, and whether one copy writes for all of them. There you add, move and remove copies.
Every action is recorded in the audit trail with who did it. A module you stop stays stopped, through restarts of its server, until you start it again; it is never reported as a crash.
What the window won’t do
Some actions would leave you with no way back, so the window refuses them and points you to the console:
- Stopping the edge your own window is connected through.
- Stopping the last running copy of a module needed to start others again (sign-in, permissions, the realm view itself).
- Restarting or stopping a server’s own host module.
Stopping anything else asks you to confirm first.
Adding, moving and removing copies
In Replicas, choose a module:
- Add a copy runs it on one more server. For a module where one copy writes, the new copy stands by.
- Move adds a copy on the new server, waits until it runs and has caught up, then removes the old one. If that takes longer than 15 minutes, both copies stay: a move never leaves none.
- Remove stops a copy. It always asks first, and asks you to type the name for a module the realm needs or for an edge.
Recent changes shows each request: in progress, done, failed or refused. The window refuses the host module, a module’s last copy, the edge you came through, and a second copy of a module whose data sits on one server’s disk (such as the registry).
A new copy needs an identity signed with the realm key. If the key is offline, the request waits and Realm key in the Manager says so; release it there, or at the server’s console. The same changes can be made on a server with velrix replicas add|remove <module> --instance <name>. A change is made on the server of the instance concerned; your other servers learn the new number of copies at their next release.
An older installation needs one mount for its host module first: in deploy.json, add {"hostPath": "/run/velrix/replicas", "path": "/run/velrix/replicas"} to mounts.host, then render the host module. Until then the window says the host can’t place copies.
Several edges
The edge is where browsers connect. Run it on more than one server, and a browser whose edge goes down reconnects through another within seconds, without signing in again.
- Add a copy of
edgeon each server that should take connections. - In deploy.json, put the realm’s name first in
settings.edge.altNames, and give each edge its own public address ininstances.<name>.settings.edge.publicAddresses. - In DNS, add one A or AAAA record per edge for the realm’s name, with a short TTL.
With a certificate from a CA (Certificate in the Manager), every edge serves the same name.
When the web client can’t be reached
The edge keeps a copy of the last web client it served. If the web client module is down, browsers still get the desktop from that copy, so you can sign in and restart it from Manager › Realm. A part of the client nobody opened while it was up shows Reload until the module is back.
The console on each server
When the edge itself is the problem, log in to the server at its own screen or over SSH, as root or as the velrix user, and run:
velrix console
It needs no browser and no edge. It shows:
- the server’s modules, with state, restarts, uptime, version and holds, and lets you restart, stop or start one and read its logs;
- every server and module the realm’s mesh can see;
- the edge’s address and the SHA-256 fingerprint of its certificate;
- releases staged on this server, to apply with
velrix release apply(Updates).
Actions go through the server’s host module, which records them. If the host module is down too, the console works on the containers directly.
The console asks for nothing more than the login: whoever is root or velrix on a server already holds its data and keys. Guard SSH and the server’s screen as you guard the realm.