Overview

Date: 2026-05-11

Time: 15:13

Overview

FTL2 supports parallel execution of modules across multiple remote hosts simultaneously. Hosts are organized into groups within a YAML inventory, and operations can target all hosts, specific groups, individual hosts, or pattern-matched subsets using the --limit flag. By default, FTL2 executes concurrently across all targeted hosts, so total execution time approximates the slowest host rather than the sum of all hosts.

Key Concepts

• Parallel execution by default — FTL2 connects to all targeted hosts simultaneously, uploads the gate, executes the module concurrently, and collects results as they complete.
• Host groups — Inventory organizes hosts into named groups (e.g., webservers, databases) under the all.children hierarchy.
• Built-in groups — all (every host) and ungrouped (hosts not in any explicit group) always exist.
• Group variables — Defined under groups.vars, inherited by all hosts in the group.
• Variable precedence (last wins): group variables → host variables → module arguments (-a flag).
• Gate zipapp is shared — Built once and uploaded to all hosts, not rebuilt per host.
• Failure isolation — If some hosts fail, FTL2 continues executing on the remaining hosts.

Commands and Syntax

Basic multi-host execution:

ftl2 -m <module> -i inventory.yml

Targeting with --limit:

--limit webservers          # specific group
--limit web01               # specific host
--limit "web*"              # glob pattern
--limit "!db*"              # exclude pattern
--limit "web01,web02"       # comma-separated list
--limit "!databases"        # exclude a group

Inventory YAML structure:

all:
  children:
    webservers:
      vars:
        http_port: 80
      hosts:
        web01:
          ansible_host: 127.0.0.1
          ansible_port: 2222
    databases:
      hosts:
        db01:
          ansible_host: 127.0.0.1
          ansible_port: 2224

Verbose logging for timing/debugging:

ftl2 -m ping -i inventory.yml -vvv

Relationships

• Inventory management — Multi-host execution depends entirely on inventory structure (groups, host vars, connection parameters).
• Gate modules — The gate zipapp is built once and shared across all hosts, making pre-building gates important for performance at scale.
• Module usage — All standard modules (ping, shell, copy, setup) work identically in single-host and multi-host contexts.
• Vault integration — Production multi-host setups should use secrets management rather than plaintext passwords.
• Policy engine — Policies can apply per-host or per-group rules, directly complementing the group-based targeting shown here.
• Rolling updates / idempotency — Multi-host patterns like rolling updates rely on --limit to control execution order, and idempotent modules to ensure safe re-runs.

Exam-Relevant Points

• FTL2 executes in parallel by default — no flag needed to enable concurrency.
• Total execution time ≈ slowest host, not sum of all hosts.
• Variable precedence order: group vars < host vars < module arguments (last wins).
• all and ungrouped are built-in groups that always exist.
• --limit supports groups, individual hosts, glob patterns, exclusion patterns (!), and comma-separated lists.
• The gate zipapp is built once and shared across all targeted hosts.
• FTL2 continues on remaining hosts when some hosts fail.
• Inventory uses ansiblehost, ansibleport, ansibleuser, ansibleconnection, ansiblepythoninterpreter as host connection parameters.
• Best practice: test on one host with --limit before running across all hosts.
• Best practice: prefer idempotent modules that are safe to run multiple times.