Speeding Up Ansible Playbooks: When to Switch from Linear to Free Strategy

The Bottleneck of the Slowest Node

You have a playbook that runs perfectly on ten servers, but when you scale to a hundred, the execution time balloons. You notice that most of your servers finish their tasks in seconds, but the entire playbook hangs for minutes because one single node is experiencing network latency or a slow disk I/O. This is the "slowest common denominator" problem.

By default, Ansible uses the linear strategy. This means every host in the current batch must complete Task A before any host is allowed to start Task B. While this provides predictability, it creates an artificial bottleneck in environments where node performance is inconsistent.

Linear vs. Free: The Execution Logic

Choosing between linear and free is a decision about whether your tasks are independent or interdependent.

The Linear Strategy (Default)

Linear execution acts like a synchronized march. If you are deploying a database and an application server, you likely need the database to be fully initialized before the application attempts to connect. Linear strategy ensures that the "Database Setup" task is finished across all target DB nodes before the "App Config" task begins on the app nodes.

The Free Strategy

The free strategy allows each host to run through the entire list of tasks as fast as it possibly can. If Host A is faster than Host B, Host A will finish the entire playbook and disconnect while Host B is still on the second task. This removes the global synchronization point and can drastically reduce total runtime in heterogeneous environments.

Practical Implementation

The strategy is defined at the playbook level. To switch to the free strategy, add the strategy keyword to your YAML file.

# playbook.yml
- name: Fast Deployment Example
  hosts: webservers
  strategy: free
  tasks:
    - name: Update cache
      ansible.builtin.apt: 
        update_cache: yes

    - name: Install Nginx
      ansible.builtin.apt:
        name: nginx
        state: present

    - name: Ensure Nginx is started
      ansible.builtin.service:
        name: nginx
        state: started

How to run this: Execute the playbook from your control node using ansible-playbook playbook.yml. You do not need special permissions beyond the standard SSH access required for the target hosts.

Comparing the Outcomes

Feature	Linear Strategy	Free Strategy
Execution Flow	Task-by-task (Global)	Host-by-host (Independent)
Speed	Limited by slowest node	Limited by individual node speed
Dependencies	Supports cross-host ordering	Risks race conditions
Console Output	Ordered and readable	Jumbled/Out-of-order

The Trade-offs and Risks

The free strategy is not a "magic button" for performance; it introduces specific risks that can break your infrastructure if ignored.

• Race Conditions: If Task 2 on Host A depends on Task 1 being completed on Host B, free strategy will likely fail. Host A may reach Task 2 before Host B has even started.
• Log Chaos: Because hosts finish tasks at different times, the standard output (stdout) becomes a mixture of different tasks from different hosts. This makes manual debugging during a live run significantly harder.
• Orchestration Failure: Rolling updates (where you take one server out of a load balancer, update it, and put it back) generally require the linear strategy or specific serial keywords to avoid taking down the entire cluster at once.

Verification and Testing

To verify the behavior, create a test playbook with a pause or sleep module. Assign a long sleep to one host and a short sleep to others.

1. Run with strategy: linear: You will see all hosts wait for the slowest node to finish the sleep task before any move to the next step.
2. Run with strategy: free: You will see the fast hosts complete all subsequent tasks and exit while the slow host is still sleeping.

If your playbook relies on wait_for or other synchronization modules to check for a service being available on a remote peer, stick to linear. If you are simply pushing independent configuration files or installing packages across a large fleet, free is the better engineering choice.