Module stack 

Stacks: a compose file deployed to the isb serve daemon, which keeps it running the way docker swarm keeps a stack running, on one host.

The daemon’s desired state is a file per stack under its state directory, and every instance it creates carries user.isb.stack, user.isb.service, user.isb.slot and user.isb.rev. Both survive a daemon restart, so a new daemon picks up exactly where the last one stopped. Apps never depend on the daemon being alive: they are supervised inside their guests (see crate::supervise) and start with the host.

• A service has deploy.replicas slots. Each slot holds one instance, named <stack>-<service>-<slot>-<id>.
• A service’s revision is a hash of everything that shapes an instance. An instance whose revision is not the current one is replaced, in batches, per deploy.update_config.
• Published host ports are served by the daemon’s load balancer (crate::balance), which only sends traffic to healthy replicas, so a start-first rollout has no gap.

Re-exports

pub use controller::Controller;

pub use secrets::SecretBinding;

Modules

controller

The reconciler behind isb serve: one worker thread per service keeps its replicas created, current, running, healthy and in the load balancer.

deployments

What the daemon keeps beside a compose stack’s definition: its environment (.env text that ${VAR} resolves against), its managed domains (domain records per service, merged in at deploy), and a record of each deploy (Deployment), kept per stack under stack-meta/<stack>/ in the stack’s org directory.

failure

Why a replica did not come up.

migrate

Upgrading stored stacks whose definitions held secret values.

secrets

A stack’s secrets: references into its org’s store, by name and version.

source

A compose stack’s source and what the daemon adds to it at deploy: the stack’s environment (variables ${VAR} resolves against, kept apart from the file) and its managed domains (domain records kept apart from the file, per service). The file is stored as written; these are merged into the copy that runs.

Structs

StackDef

A deployed stack, as the daemon stores it.

Store

Where stack definitions live: $XDG_STATE_HOME/isb (else ~/.local/state/isb), one 0600 file per stack under stacks/.

Constants

INSTANCE_NAME_MAX

incus’ limit on an instance name.

LABEL_REV

LABEL_SERVICE

LABEL_SLOT

LABEL_STACK

Instance config keys (without user.) that tie an instance to its stack.

Functions

instance_name

<stack>-<service>-<slot>-<id>, within incus’ 63-character limit. A name that would be longer keeps the start of the service name plus a hash of all of it (<stack>-<svc-prefix>-<hash6>-<slot>-<id>), so two long services in one stack still differ. Nothing parses these names back: replicas are found by their user.isb.* labels.

instance_name_fits

Whether <stack>-<service>-<slot>-<id> fits as is, without the shortening instance_name falls back to.

local_deploy_args

Resolve the paths the local CLI sends with a deploy: the project’s own directory, so relative binds and file: secrets work as with isb up.

new_id

A short random id for a new instance.

now_secs

pick_stack_name

The first valid stack name of candidates whose instance names of service fit unshortened, else the first instance_name can shorten. Unshortened first, because that is how an existing stack (a running preview’s) was picked, so it keeps its name.

qualified

A stack’s name qualified by its org: web in the default org, alpha/web in org alpha. The controller keys everything by it.

split_qualified

The org and name of a qualified stack name.

validate_stack_name

Valid stack name: what an instance name prefix allows.