Apelora

Manage it

Fabric Console is the administrator's screen. The menu on the left is the whole map; what you see depends on your role.

MenuWhat it is for
OverviewConnection, version and sign-in mode at a glance
HealthIs Apelora working, and if not, which part and why
ServersMembers, machines and join tokens, cluster settings, certificates, upgrades, preflight
ApplicationsYour applications, with Start, Restart, Shut down and Stop
InstancesEvery container and virtual machine, with logs and terminals
OperationsWhat the worker is doing and has done
Networks, StorageApplication networks; volumes, snapshots and backups
AlertsWhat needs attention, and where it is sent
AuditWho did what
Identity & AccessPeople, groups, roles, sign-in, tokens, approvals
AdministrationAPI tokens, and backups of Apelora's own database

Health

Start here when something looks wrong. It reads again every few seconds and shows each server and each part of Apelora (database, worker, Incus) with its status and the reason.

Fabric Console, Health: a degraded fabric with one server offline and a part of the platform not answering, each with the reason in words.
A degraded fabric: each problem says what and why. Sample data.

Reading it: the Health page.

Servers

Fabric Console, Servers, Members: the cluster database with three of three voters answering and the majority safe, then four members with status, role, failure domain, Incus version and capacity, each with an Evacuate button.
Members, with the cluster database's quorum above them. Sample data.
  • Members: quorum, each server's state and capacity. Evacuate… moves a server's instances away before maintenance; restore brings them back. Maintenance.
  • Machines and join tokens: add a server: register, approve, enrol, admit. Add a server. With MAAS configured, the machines it manages are listed too.
  • Cluster settings, Certificates, Upgrades, Preflight: reviewed changes, certificate rotation, a rolling-upgrade guide, and checks that tell you what is not yet right.
Fabric Console, Servers, Machines and join tokens: a form to add a machine, and a list of the machines MAAS manages with status, power state and hardware, with a Register button.
Machines and join tokens, with machines from MAAS. Sample data.

Applications: start, shut down, stop, migrate

Applications are operated from Studio's Applications list and, for the basics, from the Console's Applications page. Each application offers the verbs the server allows right now, and says why when one is greyed out.

VerbWhat it does
StartStarts every instance, providers first
RestartStops and starts again, in dependency order; offered when something is wrong
Shut downAsks each instance to shut down and gives it time, what depends on a module first. Data is kept
StopPowers every instance off at once, without waiting. Anything held only in memory is lost; use it when Shut down does not work
Migrate…Moves every instance to one server you choose, after a dry run

Shut down, Stop and Restart ask first; when clients of a single-instance or stateful module would lose service, the same dialog says so and asks again.

Studio's Applications list in its list layout: each application with its status, project and health, and the Deploy, Start, Restart, Shut down, Stop and Migrate buttons the server allows.
The Applications list. Import and New application are at the top; Export is in each row's menu. Sample data.

Migrate first shows, per instance, whether it keeps running while it moves, what is copied, and what blocks it; what has to stop needs a tick. All instances end up on the one server, so a module's replicas then share it. Try a migration on a test application before you rely on it for virtual machines.

The Migrate dialog: a server chosen from a list, a table with each instance, where it runs now and what happens to it, a note that replicas will share the server, and a tick for instances that stop while they move.
What would happen to each instance, before anything is asked. Sample data.

Import creates an application from a design file; Export JSON in a row's menu saves its design. The Console's page is the administrator's view:

Fabric Console, Applications: a dialog asking Shut down shop? and explaining that instances are asked to shut down in dependency order and data and volumes are kept.
Shut down asks first. Sample data.

Operations

Every change is a job. Operations lists them newest first, with filters for state, kind and application. A failed job can be retried and a waiting or running one cancelled, each only if you may; each attempt is recorded. Open a row for its attempts and the Incus operations behind it.

Fabric Console, Operations: filters for state, kind of change and application, and a list of jobs with their target, status and attempts; a failed create shows its error and a Retry button, a running stop shows Cancel.
A failed job shows why, and offers Retry. Sample data.

Logs, retries and the audit trail together: troubleshooting.

Instances, networks, storage, alerts

  • Instances: each instance's detail, its log files and console log, and a terminal into a running module (approval may be needed in production). Terminal sessions.
  • Networks, Storage: what Apelora created; volumes that outlive their instance, with snapshots and backups. Volumes.
  • Alerts: fifteen built-in rules with signed webhooks. Alerts.

Audit

Every change is recorded with who, what and the outcome, including refusals. Filter by person, action, target, outcome and time; the filters stay in the address, so a link shares a view. Export as CSV or JSON lines.

Fabric Console, Audit: filters and a list of events with who, the action, the outcome and, for a refusal, the reason.
A refusal is recorded with its reason. Sample data.

Roles and sign-in

Roles apply at organisation, project and application scope, and a token can never grant more than its creator holds. Access, roles and security, identity and authorization.

Next: when something goes wrong.