It’s all but undocumented, but I recently had to figure this out as well. You end up having to read the Ignition code directly, and the distro-specific (Fedora) dracut ignition module code. There’s basically no documentation from any project about anything but a few narrow use-cases.
The Ignition file processing is all handled by the Ignition project’s tool, which runs as part of your initramfs. The Ignition project provides a basic dracut module covering the basics of setup for, and calls to, the actual Ignition executable, but expects the individual distros to customize it for their needs. Fedora and OpenSuse are the only two I’ve seen using it so far and have different customizations.
A lot of the specific logic is hardcoded into the Ignition binary itself, and the provided dracut module is primarily for making the series of calls to the Ignition binary. You’ll have to end up reading the Ignition Golang code itself to figure out what files it’s loading when, how it’s merging, etc.
The Ignition code currently has 2 different types of Ignition configs it loads, a “base system” config, and a “user” config. These are merged together before being applied, with “user” settings taking precedence over “base system” settings (i.e. loaded later). The “base system” config itself is also split into multiple files that get merged together.
Where the “user” config comes from is dependent on your “platform”, which must either be specified to the Ignition binary as part of the dracut module, or will get auto-detected by the binary itself. The possible platform types are a hardcoded list you have to pick from, though they’re almost all different cloud providers, VM tools, or the bare metal value “metal”.
The “base system” config also makes use of the platform value, but only if it’s passed on the command-line. If not, it doesn’t do any platform related logic (currently). The Fedora distro version of the dracut ignition module only sets the platform on the command-line if you set the kernel argument ignition.platform_id=. The OpenSuse distro version of the dracut ignition module auto-detects if you’re running in a VM by using systemd-detect-virt and specifying “metal” otherwise, but only if the kernel argument isn’t present. You can optionally add this auto-detect logic to the Fedora version if you modify the /usr/lib/dracut/modules.d/30ignition/ignition-generator file to add in the equivalent logic from the OpenSuse code. In either case you can only get cloud-provider-specific “base system” config fragments if you set the cloud provider in the ignition.platform_id= kernel argument (OpenSuse just makes it possible to use the VM-engine and “metal” platform fragments without setting the kernel argument).
The current Ignition binary will load the “base system” ignition config fragments from /usr/lib/ignition/base.d/*.ign within the initramfs. If the platform type is set on the command line, it will also load ignition fragments from /usr/lib/ignition/base.platform.d/{platform_type}/*.ign. These are all witihin the initramfs, so you usually need to add dracut modules to write these files to the generated initramfs.
You have to read the code for the specific platform (called “provider” classes, with not all provider classes being available to pick or detect as a platform type) to determine where the “user” config comes from, but for VMs it is read from a VM config variable. For “metal” it can come from a /usr/lib/ignition/user.ign file in the initramfs, but the distro-specific dracut modules generate this file in some cases, or where the file comes from can be changed with kernel arguments or other distro-specific dracut-module-specified conditions.
Be aware, the default dracut ignition module, and both the Fedora and OpenSuse distro versions of it will delete your ignition files from the initramfs after they’ve been consumed. This is a feature to ensure changes are only made once, the first time its booted. Direct modification of the dracut ignition module is needed if you don’t want this to happen.