web-dev-qa-db-ja.com

実行時間の長いAnsibleタスクの進捗状況を表示するにはどうすればよいですか？

残念ながら長い操作を実行するAnsibleタスクがいくつかあります-S3フォルダーとの同期操作の実行など。それらが進行中であるか、単にスタックしている（またはssh接続が切断されている）かは必ずしも明確ではないため、何らかの進行状況の出力が表示されると便利です。コマンドのstdout/stderrが直接表示された場合、それは表示されますが、Ansibleは出力をキャプチャします。

出力を戻す Ansibleが現在の形式で解決するのは難しい問題です 。しかし、物事がまだ動いているという何らかの兆候を提供するために使用できるAnsibleトリックはありますか？

現在のチケットは https://github.com/ansible/ansible/issues/487

ansibleansible-2.x
33
Xiong Chiamiov

Ansibleはそれ以来、以下を実装しています：

---
# Requires ansible 1.8+
- name: 'YUM - async task'
  yum:
    name: docker-io
    state: installed
  async: 1000
  poll: 0
  register: yum_sleeper

- name: 'YUM - check on async task'
  async_status:
    jid: "{{ yum_sleeper.ansible_job_id }}"
  register: job_result
  until: job_result.finished
  retries: 30

詳細については、トピックの 公式ドキュメント を参照してください（Ansibleのバージョンを選択していることを確認してください）。

4
pydoge

今日、OSXでこの問題に遭遇しました。そこでは、ビルドに長い時間がかかり、ビルド中に出力がなかったdocker Shellコマンドを実行していました。コマンドがハングしたのか、単に進行が遅いのかを理解できないのは非常にイライラしていました。

シェルコマンドの出力（およびエラー）をポートにパイプすることにしました。これは、別のターミナルでnetcatを介してリッスンできます。

myplaybook.yml

- name: run some long-running task and pipe to a port
  Shell: myLongRunningApp > /dev/tcp/localhost/4000 2>&1

そして、別のターミナルウィンドウで：

$ nc -lk 4000
Output from my
long
running
app will appear here

エラー出力を同じポートにパイプすることに注意してください。別のポートに簡単にパイプできます。

また、nc_portという変数を設定して、ポートが使用中の場合にポートを変更できるようにしました。 ansibleタスクは次のようになります。

  Shell: myLongRunningApp > /dev/tcp/localhost/{{nc_port}} 2>&1

コマンドmyLongRunningAppがlocalhost（つまり、インベントリに設定されたホスト）で実行されていることに注意してください。これがncでlocalhostをリッスンする理由です。

19
John

できることはいくつかありますが、あなたが正しく指摘したように、現在の形式のAnsibleは本当に良い解決策を提供していません。

公式のようなソリューション：

1つのアイデアは、タスクを非同期としてマークし、ポーリングすることです。明らかに、これは、プレイブックの他の場所で障害を引き起こすことなく、そのような方法で実行できる場合にのみ適しています。非同期ドキュメントは here であり、ここから例を挙げます：

- hosts: all
  remote_user: root
  tasks:
  - name: simulate long running op (15 sec), wait for up to 45 sec, poll every 5 sec
    command: /bin/sleep 15
    async: 45
    poll: 5

これにより、少なくともタスクがハングしていないことを知るための「ping」が得られます。

公式に承認されている他の唯一の方法は、タスクの進行状況バーがあるが無料ではないAnsible Towerです。

ハックっぽい解決策：

上記を超えて、あなたはほとんどあなた自身を転がさなければならないでしょう。 S3バケットを同期する特定の例は、AWS CLIを定期的に呼び出し、バケット内のアイテムの数をカウントするスクリプトでかなり簡単に監視できますが、これは適切な汎用ソリューションではありません。

ある程度効果的だと思うのは、ノードの1つからのsshセッションを監視することだけです。

そのためには、画面上で接続して積極的に監視するように、そのマシンのansibleユーザーを設定できます。または、そのユーザーのsudoersエントリでlog_outputオプションを使用して、ファイルを末尾に配置することもできます。 log_outputの詳細は sudoers manページ にあります。

10
Tom Manterfield

Linuxを使用している場合は、systemd-run一時的なユニットを作成し、次のようにjournalctlで出力を検査します。

Sudo systemd-run --unit foo \                                      
     bash -c 'for i in {0..10}; do 
                   echo "$((i * 10))%"; sleep 1;
              done;
              echo "Complete"'

そして別のセッションで

Sudo journalctl -xf --unit foo

次のような出力になります。

Apr 07 02:10:34 localhost.localdomain systemd[1]: Started /bin/bash -c for i in {0..10}; do echo "$((i * 10))%"; sleep 1; done; echo "Complete".
-- Subject: Unit foo.service has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit foo.service has finished starting up.
-- 
-- The start-up result is done.
Apr 07 02:10:34 localhost.localdomain bash[10083]: 0%
Apr 07 02:10:35 localhost.localdomain bash[10083]: 10%
Apr 07 02:10:36 localhost.localdomain bash[10083]: 20%
Apr 07 02:10:37 localhost.localdomain bash[10083]: 30%
Apr 07 02:10:38 localhost.localdomain bash[10083]: 40%
Apr 07 02:10:39 localhost.localdomain bash[10083]: 50%
Apr 07 02:10:40 localhost.localdomain bash[10083]: 60%
Apr 07 02:10:41 localhost.localdomain bash[10083]: 70%
Apr 07 02:10:42 localhost.localdomain bash[10083]: 80%
Apr 07 02:10:43 localhost.localdomain bash[10083]: 90%
Apr 07 02:10:44 localhost.localdomain bash[10083]: 100%
Apr 07 02:10:45 localhost.localdomain bash[10083]: Complete
3
geckos