てくなべ (tekunabe)

ansible / network automation / 学習メモ

[Ansible/AWX] ジョブテンプレート・ワークフロージョブテンプレートのコピーではスケジュール、通知、パーミション設定はコピーされない

はじめに

Ansible Tower / AWX のジョブテンプレート、ワークフロージョブテンプレートにはコピー機能があります。

似たようなテンプレートを作成するときにとても便利です。

少し注意が必要なのは、スケジュール、通知、パーミションの設定はコピーされないという点です。

公式ドキュメントには以下のように記載されています。

16. Job Templates — Ansible Tower User Guide v3.6.4

If you choose to copy Job Template, it does not copy any associated schedule, notifications, or permissions.

19. Workflow Job Templates — Ansible Tower User Guide v3.6.4

If you choose to copy a workflow template, it does not copy any associated schedule, notifications, or permissions.

ということで、ワークフロージョブテンプレートで試してみます。

  • 動作確認環境
    • AWX 11.0.0

元になるワークフロージョブテンプレート

こんなワークフロージョブテンプレートで試します。

f:id:akira6592:20200427212823p:plain
元になるワークフロージョブテンプレート

1つのスケジュールがある状態です。

f:id:akira6592:20200427212855p:plain
スケジュール設定がある

失敗時に通知する設定がある状態です。

f:id:akira6592:20200427212913p:plain
通知設定がある

operator に実行権限がある状態です。

f:id:akira6592:20200427212938p:plain
権限設定が(デフォルト以外にも)ある

コピーの実行

テンプレート一覧画面で、コピーしたーテンプレートのコピーボタンを押すとコピーされてテンプレートができます。

f:id:akira6592:20200427213011p:plain
コピーボタンでコピーする

テンプレート名@コピー日時を含む名前になります。もちろん変更もできます。

コピーしたワークフロージョブテンプレート

どうなったか確認します。

スケジュールはコピーされません。

f:id:akira6592:20200427213044p:plain
スケジュール設定がない

通知の設定もコピーされません。

f:id:akira6592:20200427213105p:plain
通知設定がない

権限の設定も通知の設定もコピーされません。adminauditor の権限ははデフォルトであらゆるオブジェクトににつくので、ここにもついてます。

f:id:akira6592:20200427213125p:plain
権限設定が(デフォルト以外は)ない

おまけ

コピーすると、ワークフロー内のApproval Node の名前は copy が付きます。copy を削って元の名前に戻すこともできます。

f:id:akira6592:20200427214815p:plain
コピーすると cppy が自動でつく

おわりに

スケジュール、通知、パーミションもコピーされてほしいような、されてほしくないような、なんとも言えない感覚ですが、とりあえず覚えておきたいポイントです。

[Ansible] Junos に対して netconf ではなくSSH (network_cli) でコンフィグ投入する(cli_configモジュール)

はじめに

Ansible の Junos モジュール郡は、コネクションプラグイン(接続方式)として、netconfnetwork_cli (いわゆるSSH)に対応しています。

ただし、各モジュールごとに、利用できるコネクションプラグインが決まっています。

Junos OS Platform Options — Ansible Documentation

たとえば、設定変更コマンド(setdelete)などを投入できる、junos_config モジュールは、netconf のみに対応していて、network_cli には対応していません。

しかし、Junos 専用モジュールではなく、ベンダー抽象化した cli_configというモジュールであれば、Junos に対して network_cli (SSH) で、設定変更コマンドを投入できます。

この記事では、簡単なサンプルで説明します。

サンプルPlaybook

---
- hosts: vmx
  gather_facts: false
  
  vars:
    ansible_connection: network_cli
  
  tasks:
    - name: config test
      cli_config:
        config: set system ntp server 10.0.1.123

junos_config モジュールの lines オプション(複数形)のと違って、cli_config モジュールの config オプションは、リストではなく文字列の指定をする点にご注意ください。

そのため、複数行指定する場合は、以下のような改行入りの文字列として指定します。

    - name: config test
      config: |
        set system ntp server 10.0.1.123
        set system ntp server 10.0.2.123
        set system ntp server 10.0.3.123

file ルックアッププラグインconfig オプションを利用すれば、junos_configsrc オプションのように、コンフィグをファイルから読み込む事もできます。

実行

$ ansible-playbook -i ../inventory.ini config.yml 

PLAY [vmx] *********************************************************************************

TASK [config test] *************************************************************************
changed: [vmx]

PLAY RECAP *********************************************************************************
vmx                        : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0 
ignored=0   

一応、機器側の設定確認をします。

testuser@vMX-addr-0> show configuration system ntp | display set    
set system ntp server 10.0.1.123

無事に設定変更できました。

デフォルトで commit されます。commit オプションで無効にもできます。

他、junos_configcli_config は、どちらかが完全に勝っているというわけではありません。詳細は各モジュールのドキュメントを参照してください。

おわりに

このように、ベンダー専用モジュールでできなくても、cli_* モジュールならできる、ということを何度か経験しています。

あきらめる前に、一度 cli_commandcli_config モジュールの説明ページを確認してみることをおすすめします。

[Ansible/AWX] アドホック実行画面の追加変数欄では ansible_ で始まる変数名を指定できない

はじめに

Ansible Tower / AWX には、Playbook をジョブテンプレートとして実行する機能の他にも、アドホックansible コマンドを実行する機能もありま

-e オプションに相当する、追加変数の設定欄がありますが、指定できる変数が制限されています。

具体的には、ansible_ で始まる変数名が指定できません。(ジョブテンプレート画面など、他の画面では指定可能です)

  • 検証環境
    • AWX 11.0

検証

ここではアドホックコマンド実行画面で、以下の追加変数を指定して、起動します。

---
ansible: "I'm ok"
ansible_x: hello
ansible_port: 2222
ansible_network_os: junos

指定できない変数名がある

ansible_xansible_portansible_network_os が禁止という旨のエラーメッセージが表示されました。

参考: 知ったきっかけと調べた方法

もともとは、この画面で ansible_port 変数を利用して、ポートを変更した変数確認をしとうとしました。その際にエラーに遭遇しました。そこで、他になにが禁止されてるのだろうと思って調べることにしました。

ブラウザの言語設定を英語にすると、エラーメッセージは以下のようになります。

ansible_x, ansible_port, ansible_network_os are prohibited from use in ad hoc commands.

この are prohibited from use in ad hoc commands を頼りに、コードを検索すると、このあたりがヒットしました。

github.com

追っていくとここに行き着き、

github.com

def is_ansible_variable(key):
    return key.startswith('ansible_')

とあったので、ansible_ で始まる変数名が禁止されている、と判断しました。

[Ansible/AWX] アドホック実行画面で選択できるモジュールを追加する

はじめに

Ansible Tower / AWX には、Playbook をジョブテンプレートとして実行する機能の他にも、アドホックansible コマンドを実行する機能もあります。

デフォルトでは利用できるモジュールが限られていて、たとえばネットワーク機器に対して有効なモジュールは選択できません。 こんなときのために、利用できるモジュールを設定で追加、削除ができます。(昨日知りました)

f:id:akira6592:20200422094726p:plain:w400
選択できるモジュールを追加する

この記事では、追加する設定方法と実行例をまとめます。

  • 動作確認環境
    • AWX 11.0

設定

設定 > ジョブ 画面の アドホックジョブで許可されるANSIBLEモジュール に追加したいモジュールを入力します。

ここでは、マルチベンダーに対応するネットワークモジュールであれる cli_command モジュール を追加します。

f:id:akira6592:20200422102526p:plain
モジュールの追加

アドホックコマンドの実行

まず、インベントリのホスト一覧画の画面から、対象のホストを選択して コマンドの実行 ボタンをクリックします。

f:id:akira6592:20200422094337p:plain
ホストの選択

コマンドの実行画面が表示されるので、先程追加した cli_command モジュールを選択し、引数にオプションを入力します。

ここでは、show version コマンドを実行するために、commmand="show version" を指定します。asnible コマンド-a オプション相当です。

続いて 起動 をクリックします。

f:id:akira6592:20200422094403p:plain
モジュールとオプションの指定

f:id:akira6592:20200422094434p:plain
実行結果
無事に、選択したホストに対して cli_command モジュールを実行できました。

おわりに

アドホックコマンドの実行で選択できるモジュールを追加する方法をご紹介しました。

Ansible Tower / AWX は、直接 Plaubook を追加、編集する機能がないので、ちょっとした疎通確認、動作確認する際にはアドホック実行は便利だと思います。

ちなみに、選択できるモジュールを追加できることを知らなくて、当初 RFE として issue をあげました。そして、数分でこの機能を親切に教えていただきました。ありがたいです。

RFE: ad hoc command for network devices · Issue #6772 · ansible/awx · GitHub

[Ansible] Playbook に手を加えずにデバッガーを有効にする(ENABLE_TASK_DEBUGGER)

はじめに

Ansible には Playbook Debugger というPlaybookのデバッグ機能があります。

Playbook の途中のタスクで処理を止めて、変数の値を確認したり書き換えたりできるデバッグ機能です。Play や Task に debugger: 止める条件 という指定すると有効になります。

たとえば、以下のように Play に debugger: on_fialed と指定した場合は、Play 中のいずれかのタスクでエラーが発生した場合に、処理を止めてデバッガーが起動します。

- hosts: sv
  gather_facts: fasle
  debugger: on_fialed   # ポイント

  tasks:
    # 略

このように基本的に、Playbook 内での指定が必要です。ですが、上記のように Play に debugger: on_fialed と指定することと同等のことであれば、Playbook を書き換えることなく、ansible.cfg環境変数で指定できます。

この記事では、その方法をご紹介します。


設定名は ENABLE_TASK_DEBUGGER

エラー時にデバッガーを起動するための設定名は ENABLE_TASK_DEBUGGER です。

docs.ansible.com

ansible.cfg で指定する場合

[defaults]
enable_task_debugger=yes

環境変数 で指定する場合

export ANSIBLE_ENABLE_TASK_DEBUGGER=yes

そのコマンド実行時だけ有効にする場合は以下の通り

ANSIBLE_ENABLE_TASK_DEBUGGER=yes ansible-playbook 略


実行例

途中でエラーが発生して、変数の値を確認、変更してそのタスクだけ最実行、という一連の流れを掲載します。

利用する Playbook は以下のとおりです。assert の条件が不一致なのでエラーが発生します。

  • playbook
---
- hosts: localhost
  gather_facts: no
  vars:
    fish1: kingyo
    fish2: oikawa

  tasks:
    - name: assert fish
      assert:
        that:
          - fish1 == fish2
  • 実行
$ ANSIBLE_ENABLE_TASK_DEBUGGER=yes ansible-playbook -i localhost, assert.yml   # このコマンドのみ有効な方法で指定

PLAY [localhost] **************************************************************************************************

TASK [assert fish] ***********************************************************************************************
fatal: [localhost]: FAILED! => {      # assert が失敗した
    "assertion": "fish1 == fish2",
    "changed": false,
    "evaluated_to": false,
    "msg": "Assertion failed"
}
[localhost] TASK: assert fish (debug)>    # デバッガーが起動した
[localhost] TASK: assert fish (debug)> h    # ヘルプの表示

Documented commands (type help <topic>):
========================================
EOF  c  continue  h  help  p  pprint  q  quit  r  redo  u  update_task

[localhost] TASK: assert fish (debug)> p task_vars["fish1"]  # 変数 fish1 の値を確認
'kingyo'
[localhost] TASK: assert fish (debug)> p task_vars["fish2"]  # 変数 fish2 の値を確認
'oikawa'
[localhost] TASK: assert fish (debug)> task_vars["fish2"]="kingyo"  # 変数 fish2 の値を確認
[localhost] TASK: assert fish (debug)> u     # タスク変数を更新
[localhost] TASK: assert fish (debug)> r     # タスクの再実行
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"        # assert が通った
}

PLAY RECAP ********************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 
  • 補足: 公式ドキュメントでは、task_vars で変数を変更したあとは u(update_task)をする手順になっているため、上記の例でもそのようにしています。ただ、今回のケース、検証環境 Ansible 2.9.6 では update_task しなくても rredo したら assert は通りました。確かに update_task が必要なケースもあったのですが、詳細が思い出せずです・・。


おわりに

Playbook を書き換えずにデバッガーを有効にする方法をご紹介しました。

テスト中などの事情で、Playbook に手を入れるの憚れるときに利用できるかなと思います。

参考

docs.ansible.com tekunabe.hatenablog.jp

book.impress.co.jp P368 7-4-4 Playbook Debugger にデバッガーの使い方が書かれています。

教えていただきありがとうございます!

[Ansible] Tower/AWXのジョブテンプレートやワークフロージョブテンプレートを専用モジュールで起動する

はじめに

Ansible Tower / AWX の操作に対応する awx.awx コレクションには、ジョブテンプレートやワークフロージョブテンプレートを起動するモジュールがあります。

この記事では、簡単なサンプルをもとに使用例をご紹介します。

  • 検証環境
    • AWX 11.0

※ Ansible モジュールではなく、awx コマンドでジョブを起動する場合は、以下の記事をご参照ください

[Ansible] awx コマンドでジョブの実行を終了までリアルタイムに見届ける(--monitor オプション) - てくなべ (tekunabe)

※ Ansible Tower への実行は ansible.tower コレクションをおすすめします。


■ ジョブテンプレートの起動

ジョブテンプレートの起動には、awx.awx.tower_job_launch モジュールを利用します。

name オプションにジョブテンプレート名を指定します。

他にも、追加変数を指定する extra_vars や タグを指定する tag など、GUI の各オプションに対応するオプションが用意されています。詳細は、モジュールのドキュメント(のソース))を参照してください。

その1: 起動するだけ(ジョブの終了を待たない)

awx.awx.tower_job_launch モジュール単体で利用すると、ジョブテンプレートを起動すするだけして、ジョブの終了を待たずにタスクが終了します。

  • job_launch.yml
---
- hosts: tower
  gather_facts: false
  connection: local

  environment:  # 認証情報
    TOWER_HOST: "http://{{ ansible_host }}"
    TOWER_USERNAME: "{{ conn.tower_username }}"
    TOWER_PASSWORD: "{{ conn.tower_password }}"

  tasks:
    # ジョブテンプレートの起動
    - name: launch job
      awx.awx.tower_job_launch:
        name: jt_show             # ジョブテンプレート名

この Playbook を実行すると、ジョブテンプレートが起動します。ステータスは changed になります。

  • 実行(すぐ終わる)
$ ansible-playbook -i ../inventory.ini job_launch.yml 

PLAY [tower] *****************************************************************************************************

TASK [launch job] ************************************************************************************************
changed: [awx1]

PLAY RECAP *******************************************************************************************************
awx1                       : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

ジョブの終了は待たないので、この Playbook 終了後の AWX の画面では、まだジョブが実行中です。

f:id:akira6592:20200420211916p:plain:w400
まだジョブ実行中

その2: 起動してジョブの終了まで待つ

ジョブの終了まで待つ場合は、別途 awx.awx.tower_job_wait モジュールを併用します。

awx.awx.tower_job_launch のタスクの実行結果を register で拾うと、ジョブID(起動ごとに振られるID)id が取得できます。

この idawx.awx.tower_job_wait モジュールの job_id オプションに指定することで、ジョブの終了まで待つことができます。

  • job_launch_wait.yml
---
- hosts: tower
  gather_facts: false
  connection: local

  environment:  # 認証情報
    TOWER_HOST: "http://{{ ansible_host }}"
    TOWER_USERNAME: "{{ conn.tower_username }}"
    TOWER_PASSWORD: "{{ conn.tower_password }}"

  tasks:
    # ジョブテンプレートの起動
    - name: launch job
      awx.awx.tower_job_launch:
        name: jt_show             # ジョブテンプレート名
      register: res_jt_launch

    # ジョブの終了まで待つ
    - name: wait job
      awx.awx.tower_job_wait:
        job_id: "{{ res_jt_launch.id }}"  # 実行中のジョブIDを指定

この組み合わせにより、ジョブの終了まで待ってから、タスクを終了します。

  • 実行
$ ansible-playbook -i ../inventory.ini job_launch_wait.yml 

PLAY [tower] ******************************************************************************************************

TASK [launch job] *************************************************************************************************
changed: [awx1]

TASK [wait job] ***************************************************************************************************
ok: [awx1]    // ここで終了までそれなりに待つ

PLAY RECAP ********************************************************************************************************
awx1                       : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 

待っている途中で、ジョブがエラーになると、タスクとしてもエラーになります。


■ ワークフロージョブテンプレートの起動

ワークフロージョブテンプレートの起動には、awx.awx.tower_workflow_launch モジュールを利用します。

name オプションにワークフロージョブテンプレート名を指定します。

他にも、追加変数を指定する extra_vars や タグを指定する tag など、GUI の各オプションに対応するオプションが用意されています。詳細は、モジュールのドキュメント(のソース)を参照してください。

その1: 起動するだけ(ジョブの終了を待たない)

awx.awx.tower_job_launch モジュールと違って、awx.awx.tower_workflow_launch モジュールでは、ジョブの終了を待つか待たないかを wait オプションでしていできます。

デフォルトは true なので待ちます。

まずは false (待たない)の場合の Playbook は以下のとおりです。

  • wf_lauch.yml
---
- hosts: tower
  gather_facts: false
  connection: local

  environment:  # 認証情報
    TOWER_HOST: "http://{{ ansible_host }}"
    TOWER_USERNAME: "{{ conn.tower_username }}"
    TOWER_PASSWORD: "{{ conn.tower_password }}"

  tasks:
    # ワークフロージョブテンプレートの起動
    - name: launch wf
      awx.awx.tower_workflow_launch:
        name: wf_show
        wait: false     # 待たない指定(デフォルト true)
      register: res_wf_launch
  • 実行(すぐ終わる)
$ ansible-playbook -i ../inventory.ini job_launch.yml 

PLAY [tower] ******************************************************************************************************

TASK [launch wf] **************************************************************************************************
changed: [awx1]

PLAY RECAP ********************************************************************************************************
awx1                       : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 

この Playbook が終了直後は、まだワークフローは実行中です。

f:id:akira6592:20200420211949p:plain:w400
まだジョブ実行中

その2: 起動してジョブの終了まで待つ

待つ場合は wait オプション を true に指定します。デフォルトなので省略もできます。

  • wf_launch_wait.yml
---
- hosts: tower
  gather_facts: false
  connection: local

  environment:  # 認証情報
    TOWER_HOST: "http://{{ ansible_host }}"
    TOWER_USERNAME: "{{ conn.tower_username }}"
    TOWER_PASSWORD: "{{ conn.tower_password }}"

  tasks:
    # ワークフロージョブテンプレートの起動
    - name: launch wf
      awx.awx.tower_workflow_launch:
        name: wf_show
        wait: true     # 待つ指定(デフォルト)
      register: res_wf_launch
  • 実行
$ ansible-playbook -i ../inventory.ini wf_launch_wait.yml 

PLAY [tower] *****************************************************************************************************

TASK [launch wf] *************************************************************************************************
changed: [awx1]   // ここで終了までそれなりに待つ

PLAY RECAP *******************************************************************************************************
awx1                       : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

待っている途中で、どこかのジョブがエラーになると、タスクとしてもエラーになります。

途中で Approval ノードて止まってる場合も待ち続けます。タイムアウトtimeout 値で調整できます。 進めるには、別途承認操作が必要です。


おわりに

awx.awx.tower_job_launch モジュールや、awx.awx.tower_workflow_launch モジュールで、ジョブを起動する Playbook をご紹介しました。

GUI 以外の方法でジョブを起動したいときは便利ですね。

参考

[Ansible] 各タスク内で実行するホストの順番を指定する(order)

はじめに

各タスク内で、どのようなホストの順番で実行されるのか、を指定する order というディティブがあります。

先日たまたま知ったので、せっかくなので、検証します。

[2020/08/02 追記]

order で指定できるのは、実行開始の順であって、結果の表示順ではないようです。先に実行されたホストがあとから実行されたホストに追い越されて、結果的に実行開始順と異なる順にログが表示されることもあります。この記事では、処理時間にブレが出にくい debug モジュールを使っているので、開始順=完了順になる傾向ですが、実際はブレ出ます。

  • 検証環境
    • Ansible 2.9.6

order で指定できる値

order は Play単位で指定します。指定できる値と意味は以下のとおりです。

意味
inventory インベントリファイルで定義された順(デフォルト)
sorted インベントリ名の昇順
reverse_sorted インベントリ名の降順
reverse_inventory インベントリファイルで定義された順番の降順
shuffle シャッフル

検証

代表して、inventorysortedshuffle だけ検証します。

インベントリファイル

以下のインベントリファイルを利用します。数字部分が 1, 3, 5, 2, 4 という順番で定義しています。

[sv]
sv1 ansible_host=localhost 
sv3 ansible_host=localhost 
sv5 ansible_host=localhost 
sv2 ansible_host=localhost 
sv4 ansible_host=localhost 

Playbook

order: inventory

まずは order: inventory を指定します。これはデフォルトの動作です。

---
- hosts: sv
  gather_facts: false
  order: inventory   # ここポイント

  tasks:
    - name: debug1
      debug:
        msg: "I am {{ inventory_hostname }}"
    - name: debug2
      debug:
        msg: "I am {{ inventory_hostname }}"

実行します。order: inventory なのでインベントリファイルで指定したとおり、1, 3, 5, 2, 4 という順番になりました。(前述の追記通り、開始順=完了順とは限りません)

$ ansible-playbook -i inventory.ini order.yml

PLAY [sv] *******************************************************************************************************

TASK [debug1] ***************************************************************************************************
ok: [sv1] => {
    "msg": "I am sv1"
}
ok: [sv3] => {
    "msg": "I am sv3"
}
ok: [sv5] => {
    "msg": "I am sv5"
}
ok: [sv2] => {
    "msg": "I am sv2"
}
ok: [sv4] => {
    "msg": "I am sv4"
}

TASK [debug2] ***************************************************************************************************
ok: [sv1] => {
    "msg": "I am sv1"
}
ok: [sv3] => {
    "msg": "I am sv3"
}
ok: [sv5] => {
    "msg": "I am sv5"
}
ok: [sv2] => {
    "msg": "I am sv2"
}
ok: [sv4] => {
    "msg": "I am sv4"
}

PLAY RECAP ******************************************************************************************************
sv1                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv2                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv3                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv4                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv5                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

PLAY RECAP のところはインベントリ名の昇順です。

order: sorted

続いて order: sorted の場合の実行結果です。インベントリ名の昇順になりました。(前述の追記通り、開始順=完了順とは限りません)

$ ansible-playbook -i inventory.ini order.yml
PLAY [sv] *****************************************************************************************************************

TASK [debug1] *************************************************************************************************************
ok: [sv1] => {
    "msg": "I am sv1"
}
ok: [sv2] => {
    "msg": "I am sv2"
}
ok: [sv3] => {
    "msg": "I am sv3"
}
ok: [sv4] => {
    "msg": "I am sv4"
}
ok: [sv5] => {
    "msg": "I am sv5"
}

TASK [debug2] *************************************************************************************************************
ok: [sv1] => {
    "msg": "I am sv1"
}
ok: [sv2] => {
    "msg": "I am sv2"
}
ok: [sv3] => {
    "msg": "I am sv3"
}
ok: [sv4] => {
    "msg": "I am sv4"
}
ok: [sv5] => {
    "msg": "I am sv5"
}

PLAY RECAP ****************************************************************************************************************
sv1                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv2                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv3                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv4                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv5                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

order: shuffle

order: shuffle の場合です。なんとも言えない順番にシャッフルされました。

シャッフルされた順番は、Play 内では固定のようです。

$ ansible-playbook -i inventory.ini order.yml

PLAY [sv] *****************************************************************************************************************

TASK [debug1] *************************************************************************************************************
ok: [sv3] => {
    "msg": "I am sv3"
}
ok: [sv1] => {
    "msg": "I am sv1"
}
ok: [sv5] => {
    "msg": "I am sv5"
}
ok: [sv4] => {
    "msg": "I am sv4"
}
ok: [sv2] => {
    "msg": "I am sv2"
}

TASK [debug2] *************************************************************************************************************
ok: [sv3] => {
    "msg": "I am sv3"
}
ok: [sv1] => {
    "msg": "I am sv1"
}
ok: [sv5] => {
    "msg": "I am sv5"
}
ok: [sv4] => {
    "msg": "I am sv4"
}
ok: [sv2] => {
    "msg": "I am sv2"
}

PLAY RECAP ****************************************************************************************************************
sv1                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv2                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv3                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv4                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
sv5                        : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

おわりに

各タスク内で、どのようなホストの順番で実行されるのか、を指定する order というディティブの検証をしました。

処理の順番にシビアになることはあまり多くはないかもしれませんが、ログの出力順を変えたいときはあるかもしれません。(追記: order はログの出力順ではなく、実行開始順を制御するもの)