Module 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.

• shell: the POSIX library and a recipe’s calls, for a Linux VM’s set-up and every generated Dockerfile (cloud-init carries the VM’s script).
• cloud_init: the same shell script, delivered in a cloud-config write_files entry (gzip then base64) and run from runcmd, for the targets that hand a VM its user data.
• powershell: the PowerShell library and a recipe’s calls, for a Windows VM’s set-up.
• dockerfile: the image a container builds from its recipe, its process Isoloom’s runner when it runs services.
• files: the files they add to a target’s: the Dockerfiles, the libraries, the runners and the templates filled in for a container’s build.

Every step is rendered in recipe order, behind its guard, so a second apply changes nothing.

Modules

cloud_init

The cloud-init carrier for a machine’s recipe (design plan/phase4/design.md §2.1, §2.3, §5b): the shell library and a recipe’s calls, as one sh script, delivered in a write_files entry (gzip then base64, encoding: gz+b64) and run from runcmd at the step’s place in the machine’s set-up.

dockerfile

The Dockerfile Isoloom generates from a container’s recipe (design §2.2–§2.3): FROM its OS’s official image (pinned by digest), the project folder (/opt/isoloom, the same path a VM has) as its working folder, then each step in order. Scripts and copies are the Dockerfile’s own COPY and RUN, a template a COPY of the file Isoloom filled in, and every other step one RUN of the shell library’s call. A service doesn’t run at build: Isoloom’s runner (super::runner) is the image’s entrypoint, and starts it. The project folder is the build context.

powershell

The PowerShell rendering of a Windows recipe (design §2.1–§2.2): the library (configure.ps1, one function per step kind) and one call per step. A Windows VM’s set-up runs the calls after the library. Every argument is a single-quoted literal.

runner

Isoloom’s runner (design §3): the process of a container whose recipe runs services, generated per machine in POSIX sh and installed as the image’s entrypoint. The engine’s init (Compose’s init: true, a pod sharing its process namespace) is PID 1 and reaps what the runner leaves.

shell

The shell rendering of a recipe (design §2.1–§2.2): the POSIX library (configure.sh, one function per step kind, for apt, dnf and apk, systemd and OpenRC), and one library call per step. A Linux VM’s set-up runs the calls after the library; a generated Dockerfile RUNs each call after sourcing it; cloud-init carries the VM’s script. Every argument is quoted.

Structs

Configured

One machine’s recipe as its renderers read it: the environment the machine is planned in (its addresses on the target, which its templates name) and its name.

Constants

DIR

Where the configuration renderers’ own files go, from the project folder.

Functions

files

The files the configuration renderers add to env’s: each container’s Dockerfile, with its runner and its filled templates, and the libraries, once, when a recipe uses them (a VM’s set-up embeds its library; the file is the same text, which the validators check).

linux_unit

A Linux service unit’s file for family: the same text the shell renderer writes and the Ansible backend copies, so a defined service runs the same under either carrier. An OpenRC script on Alpine, else a systemd unit.

rendered_path

Where template from of machine machine, filled in, is generated for its image’s build.

systemd_word

One word of a systemd command line, quoted: systemd unescapes C-style in double quotes and expands % specifiers and $ variables, each doubled to stay literal.

uses_library

Whether a recipe has a step its library runs (not only scripts, reboots and playbooks).