Provisioning

There are two ways to configure the machines of a VM target, and a spec can use both.

Machine by machine

A machine's vm.provision lists steps that run in that machine, in order: .sh scripts and Ansible playbooks on Linux (Ansible runs inside the VM), .ps1 scripts on Windows. See Machines.

The whole environment, with Ansible

Most Ansible setups configure several machines at once: a domain controller, then the servers that join it. The top-level provision: runs such playbooks once every machine is up:

provision:
  - ansible: ansible/site.yml
    inventory: [ansible/groups.ini]
    requirements: ansible/requirements.yml
    groups:
      webservers: [web]
      caches: [cache]
    vars:
      greeting: hello from ansible

Field	Type	Notes
`ansible`	string	A playbook in the project. It runs from its own folder, so its `ansible.cfg`, roles and relative paths work as usual.
`inventory`	list	More inventory files from the project (groups, host and group variables), next to the one Isoloom writes.
`requirements`	string	Ansible Galaxy requirements to install first. By default, `requirements.yml` next to the playbook.
`groups`	map	A group name → machines, added to the inventory.
`vars`	map	Extra variables.

What Isoloom does

It writes the inventory: every VM machine with its address, in the linux group (SSH) or the windows group (WinRM), with the images' own accounts, plus your groups.
It adds a controller: a small Debian VM on every network, at the second-to-last address of each (reserved, like the router's last one). It starts after every machine, installs Ansible (with WinRM support) and the requirements, and runs the playbooks in order.
Nothing runs on your machine.

Environment-level provisioning runs on VM targets today; on containers it's planned.

A complete example

ansible-pair configures two machines with one playbook. At a larger scale, GOAD-Light (Game of Active Directory, by Orange Cyberdefense) is being described this way, with its own playbooks against three Windows servers (in progress).