Expand description
What every Isoloom backend renders with, so the targets render the same decisions the same
way. It sits between the plan (isoloom-plan, the facts) and the backends (Compose,
Kubernetes, Vagrant, Terraform, Ansible), which implement its
Backend port.
- The port:
backend(theBackendtrait a target’s renderer implements) and itsError. - The builders, one per language a target writes:
hcl_builder(Terraform),ruby(a Vagrantfile’s literals),powershell(a Windows machine’s) andinventory(Ansible’s); shell isisoloom_spec::shell, below every crate. - The configuration renderers (
configure): a machine’s recipe as the shell and PowerShell libraries’ calls, the Dockerfile its container builds from, and Isoloom’s runner, the process of a container that runs services. - A VM’s set-up:
steps(eachStepas Linux shell or PowerShell), the scripts kept across restarts (boot),secretsdelivered at run time, the network’sconstraints, thecontrollerthat runs the playbooks, and theprojectcopied in. - The network pieces:
router, VLANtrunks,ipv6and a VM’smore_addresses. - The containers’ shared parts:
container; where a check reaches its host:checks. - The run manifest’s pieces every target’s
run.jsonis built from:run_manifest.
Everything here is a pure function of the plan: no I/O, no clock, no environment.
use isoloom_plan::{Environment, Lab, Step};
use isoloom_spec::model::Target;
let lab = Lab::parse(
"version: 1\nname: demo\nnetworks: { lan: { cidr: 10.9.0.0/24 } }\nmachines:\n web: { networks: { lan: 10 }, os: debian@12 }\n",
)
.expect("the spec parses");
let env = Environment::build(&lab.for_target(Target::Vagrant), Target::Vagrant, None);
let ready = isoloom_render::steps::linux(&env, "web", &Step::Ready).expect("every VM gets ready");
assert!(ready.ends_with("echo ready > /var/lib/isoloom/ready\n"));Modules§
- backend
- What every backend is: a target, the capabilities it has, and a rendering of a planned
Environmentinto files. Defined here, below every backend crate, so each can implement it;isoloom-targetskeeps the registry. - boot
- Set-up that must survive a restart. A step’s script (routes, trunks, link impairment, the
egress rules) changes kernel state a reboot forgets; a VM backend whose machines restart
(a
rebootstep,vagrant reload, a stopped cloud VM) wraps it withat_bootso it is applied now and again at every boot. A machine’s own command andbeforesteps run the same way, as aservice. - checks
- What the backends’ check runners share: where a probe reaches its host.
- configure
- The configuration renderers whose output an infrastructure file embeds or builds from (design
plan/phase4/design.md§2, §3, §6.1): each renders a machine’s resolved recipe (Recipe, on the plan) and nothing else. - constraints
- What the network an environment runs in imposes (see
Constraints), as each target needs it: - container
- What every target that runs the machines as containers shares, whichever backend writes the
files (Compose, Kubernetes) or builds the host they run on (a cloud VM, a local VM): the
images Isoloom brings and the readiness probe here; the one-shot jobs and how a Compose
project starts (
jobs); the project files read into Compose’s environment (project_files); the size of the VM the containers run on (host); the containers’ side of a hybrid environment (hybrid). Pure functions over the spec and the plan. - controller
- The controller: the VM that runs the environment’s playbooks (
provision:) on every target that runs playbooks (Vagrant, Proxmox, the clouds,isoloom provision), with one script, so they all retry the same way. - hcl_
builder - The HCL builder: a Terraform module is built as
hcl-rsstructures (Block,Attribute,Expression) and written once. - inventory
- The one Ansible inventory, rendered from a planned
Environmentfor every target that runs playbooks: the controller’s/etc/isoloom/inventory.inion Vagrant, Proxmox and the clouds, and.isoloom/external/inventory.inion theexternaltarget. - ipv6
- IPv6 on a VM, written once for every VM target: each IPv6 address on the interface that holds the machine’s IPv4 address on that network (the providers configure IPv4 only), the IPv6 routes through the router, the router’s own IPv6 side, and its IPv6 forwarding rules.
- more_
addresses - A VM’s further addresses on a network (
lan: [10, 11]), written once for every VM target: each on the interface that holds the machine’s primary address there, since the hypervisor or the cloud configures only that one. A cloud that filters by address has been told of them by its own module (a secondary private address, an alias range). - powershell
- PowerShell, as a Windows machine’s set-up is written: string literals that hold any text, and the script that unpacks the project.
- project
- The project copied into the machines, without what
.isoloomignoreleaves out: its rules (ignore, the run manifest’s: the runner’sproject.archivefollows them too), and the same rules in the Terraform outputs, read when Terraform runs, exactly as the Vagrantfiles read them (vagrant_project.rb), so every target leaves out the same files. - router
- The router both kinds of target add when a spec has
reachrules: a machine on every network at its last address, forwarding between networks and filtering with nftables. Machines route the networks they aren’t on through it. - ruby
- Ruby, as a Vagrantfile is written: string literals that hold any text.
- run_
manifest - What every backend’s run manifest is built from: its header, steps (a native command or a
driver action, with their policies), tools, the lab’s networks, a machine’s addresses and
ports, the outputs of its published ports, and the checks a runner reports with the time
its step may take. Pure functions over the plan, shared so each target says them once.
Compose inside a VM is
guest: what both backends ofdocker-vmshare. - secrets
- Secrets on a VM and on a Docker host. The generated set-up never holds a value: it waits
for the runner (Isothrum’s
isothrum up) to deliver them over the machine’s own connection (SSH), then puts each file in place. Delivery writes a root-only copy of each value underKEPT_DIR(it outlives a reboot, which empties/run/secrets) and the markDELIVEREDthe set-up waits for. - steps
- Each set-up step of a VM (
Step) written once: as a root shell script for Linux, and as PowerShell where Windows has the step. A VM backend only picks how the scripts reach the machine (a Vagrant provisioner, cloud-init,remote-exec, WinRM), so every target sets a machine up the same way. - trunks
- 802.1Q trunks: a machine on several VLANs of one LAN gets one tagged link instead of one interface per VLAN, as a router-on-a-stick or a server on a trunk port has.
Structs§
- Generated
File - One generated file: its path relative to the project folder, and its contents.
Enums§
- Error
- Why a backend didn’t render an environment.
Constants§
- OUTPUT_
DIR - Where generated files go, relative to the project folder.
Functions§
- header
- The first lines of every generated file: it is generated and how to change it (
commentis the file’s comment marker,#or//).