Rolling Updates, Speed and Controllers

Do not update everything at once

For production, update in small batches so a bad change affects only a few hosts. serial: 2 (or a percentage) runs the play on two hosts at a time, and max_fail_percentage stops the rollout if too many fail. Combine with health checks between batches (ansible.builtin.uri to hit a status URL) and, for load-balanced services, take hosts out of rotation before updating them. For speed, raise forks, enable SSH pipelining and ControlPersist, and skip fact gathering when unneeded. For teams, AWX (open source) or Red Hat Ansible Automation Platform provide a web UI, scheduling, credentials, RBAC and audit logs.

A rolling update play

Illustrative. If more than 25% of a batch fails, the rollout stops before reaching the remaining hosts.

- name: Rolling update of web tier
  hosts: web
  serial: 2
  max_fail_percentage: 25
  become: true
  tasks:
    - name: Deploy new release
      ansible.builtin.include_role:
        name: app_deploy
    - name: Wait for health check
      ansible.builtin.uri:
        url: "http://{{ inventory_hostname }}:{{ http_port }}/health"
        status_code: 200
      register: health
      until: health.status == 200
      retries: 10
      delay: 3

Start with one canary host

Run the change on one host (--limit web1) first, check it, then widen. A canary catches problems while the blast radius is a single machine.

Quick check: What does `serial: 2` do?

• Limits the play to two seconds
• Runs only two tasks
• Runs the play on two hosts at a time
• Creates two inventories