Как я могу показать прогресс для долговременной задачи Ansible?

Question

У меня есть некоторые задачи Ansible, которые выполняют к сожалению длительные операции - например, выполнение операции синхронизации с папкой S3. Это не всегда ясно, если они прогрессируют или просто застревают (или сбой ssh), так что было бы неплохо отобразить какой-то прогресс. Если stdout/stderr команды был непосредственно отображен, я бы это увидел, но Ansible фиксирует вывод.

Выход трубопровода назад is a difficult problem for Ansible to solve in its current form. Но есть ли какие-либо Ansible трюки, которые я могу использовать, чтобы показать какие-то признаки того, что все еще движется?

Текущий билет https://github.com/ansible/ansible/issues/4870

Answer 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 

Это может по крайней мере дать вам «пинг», чтобы знать, что задача не висит.

Единственный другой официально одобренный метод - это Ansible Tower, у которого есть индикаторы выполнения задач, но не является бесплатным.

Hacky-иш решения:

Помимо вышесказанного, вы в значительной степени придется свернуть свой собственный. Ваш конкретный пример синхронизации ведра S3 можно довольно легко контролировать с помощью скрипта, периодически вызывающего CLI AWS и подсчета количества элементов в ведре, но это вряд ли хорошее, общее решение.

Единственное, что я мог представить, будучи несколько эффективным, будет наблюдать за входящей сессией ssh ​​с одного из ваших узлов.

Для этого вы можете настроить доступного пользователя на этом компьютере для подключения через экран и активно наблюдать за ним. Альтернативно, возможно, используя параметр log_output в записи sudoers для этого пользователя, что позволяет вам зачеркнуть файл. Подробные сведения о log_output можно найти на sudoers man page

Answer 2

Я столкнулся с этой проблемой сегодня на OSX, где я запускал команду оболочки докеров, которая занимала много времени, и не было никакого выхода во время ее создания. Было очень неприятно не понимать, была ли команда висела или просто прогрессировала медленно.

Я решил передать вывод (и ошибку) команды оболочки на порт, который затем можно было бы прослушать через 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, которая позволит изменить порт в случае использования порта. Анзибль Затем задача выглядит следующим образом:

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

Обратите внимание, что команда myLongRunningApp в настоящее время выполняется на локальном хосте (то есть, что это хозяин установлен в инвентаре), поэтому я слушать локальный с nc.