Stacks
A stack is a master image plus the settings a system built from it wants: how much memory, what kind of network, whether it manages itself through a link of its own. Installing one clones the master, makes the network, and starts what it built.
The catalogue comes from the registry, and holds both what this engine already has and what it could fetch. A linked engine sees more than the public stacks.
Stack
Which stack to install. The ones under On this engine are ready to build from; the ones under From the registry have to be downloaded first, and their size is shown beside them. Each stack's tags follow its name, in the list and on its card. The search at the top of the open list narrows it to the stacks whose name or tags hold what you type - linux, kubernetes; the arrow keys move through what is left, and Return chooses one. Tags are set at the registry.
A stack downloads as several images — the stack itself, whatever it is built on, and a data disk where it has one — so it is normal for one to arrive well before the others. Install waits until all of them are here. If the image a stack is built on is deleted later, the stack is taken off the list and the engine fetches that image again; the stack comes back once it is here.
Name
What the system and its VMs are called. Left empty, the stack's own name is used - for the VM, its network and its images alike; where a stack builds more than one VM they are numbered from it.
Instances
How many VMs to build from this stack. More than one makes a system of that many, each a clone of the same master with a name in sequence. Stacks that are meant to scale out say so in their description; for the rest, one is the answer.
Network
The network the VMs are attached to. A new one can be made for them here, or an existing one reused.
- A new network, with a public address (IP mapping) — the usual choice: the VM keeps a private address, and the engine maps a public one onto it.
- A new private network — reachable from other VMs on this engine, and nowhere else.
- A new network with a public address only — the VM holds the public address itself.
- A new network behind the engine's NAT — outbound traffic only, through the engine.
Allowed ports
Which ports a mapped or public address lets in, as a comma-separated list — 80,
443 for a web server, say. Empty allows none, which leaves the VM reachable from
its own network and from the console but not from outside.
Memory per VM
How much memory each VM gets, in MB. The list offers the usual sizes; any number can be typed instead. A stack that has an opinion about this has already filled it in.
vCPUs per VM
How many virtual processors each VM gets. They are shared with everything else on the node, so more is not always faster.
Settings this stack comes with
What the stack has already decided for itself — its memory, its network, where its disks go — folded away because it is rarely worth changing. Anything in there can still be changed before installing; it is the stack's recommendation, not a rule.
Backup
How often the VMs' images are backed up, and how long those backups are kept. Backups are taken on the engine's own schedule, not at the moment it is set.
Monitoring
What the engine starts checking on each VM as it is built. Ping notices when a VM stops answering; disk space when one is filling up; patch level when security fixes are waiting. Alerts go to the stack's alert address, or failing that the account's.
A stack can ask for checks of its own - https:8443/health, say - which are then
shown here as the stack's own choice. Whatever is set up at the start can be
changed afterwards, and more added, under Monitoring in the
stack's pane.
Storage
Which storage pool the VMs' boot images go on. On the node it runs on keeps the image on the compute node's own disk — fast, but the VM cannot move to another node without copying it.
Data storage
Where a stack's second, data disk goes, when it has one. The same choice as Storage, for the disk that holds what the application keeps.
Contacts
Who to reach about this stack: the person it belongs to, the people running it day to day, and where its monitoring and backup alerts go. Alerts to takes several addresses, separated by commas.
A stack starts out with the contacts in Your settings, and keeps following them until one is changed here. Its VMs follow the stack in the same way. Clearing a field puts your account's value back.
Services
What the stack is for, and what to do when it stops doing it: whether its VMs start again when the engine boots, which services it provides, and the procedures for recovering a failed one. Setting Autostart here sets it for every VM in the stack. Notes are at the bottom of the Info tab.
Usage
What the stack has in use now - its VMs' vCPUs, memory, storage and external addresses added up, and their cost per month where the engine shows costs. Your account's usage as a whole, against its quotas and month by month, is on Home.
Software
The operating systems on the stack's VMs, and the software installed on them.
Rescan finds what is installed on each VM. A running VM built from a stack with update integration is asked directly, and also says which packages have updates - an arrow and the new version in the list, marked security for security fixes - and whether it needs a restart for updates already installed. Any other VM has its disk opened read-only on the node it is on, which finds what is installed but not what is out of date; the VMs keep running either way. Clear forgets what was found.
Install updates and Install security updates appear when a scan has found some. Each running VM installs them itself, in the background - rescan a while later to see what is left. Packages a VM holds back are left alone. Everything your VMs run, together, is on Home.
Update schedule
How often the stack's VMs install updates by themselves - weekly, daily or hourly, and either everything or only security fixes. Only shown for a running stack whose VMs can be asked; Differs between its VMs means they have been set apart, and picking a schedule sets them all.
A VM built from an older stack may not answer about updates at all, until its stack's integration files are brought up to date.
New stack
A stack of your own making rather than one installed: a name, and any of your VMs that stand on their own to put in it. It can start out empty and be filled later.
A stack is a way of keeping VMs together: they are listed under it, started and shut down together, scanned and patched together, and take their contacts from it. Putting a VM in one changes nothing about how it runs.
Acting on the whole stack
A stack's pane acts on all its VMs at once: Start, Resume, Shutdown,
Pause, Power off and Backup are each one action for the stack, which the
engine applies to every VM it fits - Start in a stack where some VMs are
running starts the ones that are off and leaves the rest. A button shows when at
least one VM can take it. Backup backs up the images of every VM in the stack;
where some are running, it offers to pause them while it does and to resume them
afterwards (why) - keal stacks backup shop --pause.
From the command line it is the same: keal stacks start shop, keal stacks
suspend shop, keal stacks backup shop.
With one of the stack's VMs selected rather than the stack, the pane acts on that VM alone, and has its Console while it is running. Manage and Terminal open the management interface and terminal the stack's image gives, where it gives them; each of the three has an icon beside it for a window of its own.
Moving VMs between stacks
In a stack's pane, the VMs it holds each have a × that takes the VM out - it is kept, on its own - and Add a VM… lists your VMs that are on their own, for putting one in. A VM's own pane has the same choice the other way round, under Stack. A VM is in one stack at most.
Ungroup
Breaks a stack up and keeps its VMs, each on its own; the stack itself is gone. Delete, by contrast, deletes the VMs and their images with it. An empty stack has only Delete, which then takes nothing else with it.
Metrics
How the stack's VMs have been doing, from the last twenty minutes to the last month. CPU and memory have a line for each VM - CPU as vCPUs in use, so the lines can be added up - and disk and network are the VMs' together. With more than eight VMs, the first seven keep a line each and the rest share one.
Everything is measured by the nodes the VMs run on, from outside them; see a VM's metrics for what that means for the numbers.
Monitors
The checks made on the stack's VMs, listed together; a check is added to whichever VM is picked. What they are, when one counts as down and who is told is the same as for a single VM: see a VM's monitors.
Uptime
For a month, how much of the time each of the stack's monitors was being checked it was up - see a VM's uptime.
Managed through
Which of the stack's VMs it is managed through. That VM's management interface and terminal become the stack's own - the icon beside the stack's name, and the Management and Terminal links in its pane. A stack installed from the catalogue starts out managed through the first VM it built; one you put together yourself is managed through none until you pick one. A VM that leaves the stack takes this with it.
Every VM keeps links of its own as well, whichever stack it is in: opening a stack and clicking one of its VMs shows that VM here, with its own management interface, terminal and upgrade link.
Management
A stack's management interface - or a VM's - opened in a frame here, or in a tab of its own with the icon beside it. Where it is, is the image's to say: see an image's links. Update service is the address the engine asks about packages and patches; it is inside the VM's network, and not somewhere to go.