Skip to main content

Crate isoloom_render

Crate isoloom_render 

Source
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 (the Backend trait a target’s renderer implements) and its Error.
  • The builders, one per language a target writes: hcl_builder (Terraform), ruby (a Vagrantfile’s literals), powershell (a Windows machine’s) and inventory (Ansible’s); shell is isoloom_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 (each Step as Linux shell or PowerShell), the scripts kept across restarts (boot), secrets delivered at run time, the network’s constraints, the controller that runs the playbooks, and the project copied in.
  • The network pieces: router, VLAN trunks, ipv6 and a VM’s more_addresses.
  • The containers’ shared parts: container; where a check reaches its host: checks.
  • The run manifest’s pieces every target’s run.json is 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 Environment into files. Defined here, below every backend crate, so each can implement it; isoloom-targets keeps 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 reboot step, vagrant reload, a stopped cloud VM) wraps it with at_boot so it is applied now and again at every boot. A machine’s own command and before steps run the same way, as a service.
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-rs structures (Block, Attribute, Expression) and written once.
inventory
The one Ansible inventory, rendered from a planned Environment for every target that runs playbooks: the controller’s /etc/isoloom/inventory.ini on Vagrant, Proxmox and the clouds, and .isoloom/external/inventory.ini on the external target.
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 .isoloomignore leaves out: its rules (ignore, the run manifest’s: the runner’s project.archive follows 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 reach rules: 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 of docker-vm share.
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 under KEPT_DIR (it outlives a reboot, which empties /run/secrets) and the mark DELIVERED the 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§

GeneratedFile
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 (comment is the file’s comment marker, # or //).

Type Aliases§

Result
A result whose error is this crate’s Error.