Ansibleのasyncとpollで長時間タスクを制御する方法｜タイムアウト対策と並行実行の設計

この記事のポイント

・asyncでタスクをバックグラウンド実行し、SSHタイムアウトを回避できる
・poll: 0（fire-and-forget）＋async_statusで複数ホストの並行実行が可能
・retries×delayがasync値以上になるよう設計することが重要
・Windowsモジュールはasyncに対応していないため注意が必要

# async: タスクの最大実行時間（秒）を指定してバックグラウンド実行する
- name: パッケージを全件更新する
  ansible.builtin.dnf:
    name: "*"
    state: latest
  async: 1800    # 最大1800秒（30分）。超過するとKillされる
  poll: 30       # 30秒ごとにAnsibleが完了を確認する

# poll: 0 でfire-and-forget（完了を待たずに次へ進む）
- name: パッケージ更新をバックグラウンドで開始する
  ansible.builtin.dnf:
    name: "*"
    state: latest
  async: 1800
  poll: 0
  register: dnf_job    # ジョブIDをregisterで保持する（後で確認に使う）

# ジョブの完了を定期確認する
- name: パッケージ更新の完了を待つ
  ansible.builtin.async_status:
    jid: "{{ dnf_job.ansible_job_id }}"    # ジョブIDを指定
  register: job_result
  until: job_result.finished               # finishedがtrueになるまで繰り返す
  retries: 60                              # 最大60回試行
  delay: 30                               # 30秒ごとに確認する

# 設計上の原則: retries * delay >= async の関係を必ず守る
# この例: 60 * 30 = 1800秒 = async: 1800 → OK

# 独立した複数ジョブをfireしてバックグラウンドで並行実行する
- name: DB1バックアップを開始
  ansible.builtin.command: /usr/local/bin/backup-db1.sh
  async: 3600
  poll: 0
  register: backup1_job

- name: DB2バックアップを開始
  ansible.builtin.command: /usr/local/bin/backup-db2.sh
  async: 3600
  poll: 0
  register: backup2_job

# この時点でDB1とDB2は並行実行中

- name: DB1バックアップの完了を待つ
  ansible.builtin.async_status:
    jid: "{{ backup1_job.ansible_job_id }}"
  register: result1
  until: result1.finished
  retries: 120
  delay: 30

- name: DB2バックアップの完了を待つ
  ansible.builtin.async_status:
    jid: "{{ backup2_job.ansible_job_id }}"
  register: result2
  until: result2.finished
  retries: 120
  delay: 30

TASK [パッケージ更新をバックグラウンドで開始する] *****
changed: [web01.example.internal]
changed: [web02.example.internal]

TASK [パッケージ更新の完了を待つ] ********************
FAILED - RETRYING: [web01.example.internal]: パッケージ更新の完了を待つ (59 retries left)
FAILED - RETRYING: [web02.example.internal]: パッケージ更新の完了を待つ (59 retries left)
FAILED - RETRYING: [web01.example.internal]: パッケージ更新の完了を待つ (58 retries left)
FAILED - RETRYING: [web02.example.internal]: パッケージ更新の完了を待つ (58 retries left)
changed: [web01.example.internal]
changed: [web02.example.internal]

PLAY RECAP *********************************************
web01.example.internal    : ok=2    changed=2    unreachable=0    failed=0
web02.example.internal    : ok=2    changed=2    unreachable=0    failed=0

# インベントリの全Webサーバーで並行してパッケージ更新を実行する
---
- name: 全Webサーバーのパッケージ更新
  hosts: web_servers      # web01, web02, web03 の3台
  tasks:
    - name: パッケージ更新をバックグラウンドで開始
      ansible.builtin.dnf:
        name: "*"
        state: latest
      async: 1800
      poll: 0
      register: update_job

    - name: パッケージ更新の完了を待つ
      ansible.builtin.async_status:
        jid: "{{ update_job.ansible_job_id }}"
      register: job_result
      until: job_result.finished
      retries: 60
      delay: 30

---
- name: 全Webサーバーのパッケージ更新（freeストラテジ）
  hosts: web_servers
  strategy: free    # ホストごとに独立して次のタスクへ進む
  tasks:
    - name: パッケージ更新をバックグラウンドで開始
      ansible.builtin.dnf:
        name: "*"
        state: latest
      async: 1800
      poll: 30       # pollあり: このホストの完了を待ってから次へ

# ジョブIDが本当に取れているか確認する
- name: ジョブIDのデバッグ出力
  ansible.builtin.debug:
    msg: "Job ID: {{ update_job.ansible_job_id }}"

# NG例: retries * delay = 10 * 30 = 300秒 だが async: 1800 秒
# → 1800秒のジョブが完了する前にuntilループが300秒で終わる
- name: 完了確認（NG設定）
  ansible.builtin.async_status:
    jid: "{{ update_job.ansible_job_id }}"
  register: job_result
  until: job_result.finished
  retries: 10     # 少なすぎる
  delay: 30

# OK例: retries * delay = 60 * 30 = 1800秒 = async: 1800 秒
# → asyncと同じ秒数まで待てる
- name: 完了確認（OK設定）
  ansible.builtin.async_status:
    jid: "{{ update_job.ansible_job_id }}"
  register: job_result
  until: job_result.finished
  retries: 60     # retries * delay >= async を常に守る
  delay: 30