Як я можу записати вихідну задачу у файл?


10

Одна з моїх відповідальних завдань імпортує базу даних Oracle за допомогою impdp.

Це генерує багато виводу на консоль, тому я встановив no_log: True.

Однак, коли це не вдається, я хочу побачити журнал!

Як я можу зробити цей конкретний журнал завдань у файлі, а не в консолі?


Ви використовуєте командний модуль?
Xiong Chiamiov

Однією ідеєю [більше хак] було б записати журнали у якийсь зовнішній файл, а потім мати після нього завдання, яке використовує failed_whenумову, та видалити файл журналу, якщо попередній. завдання було успішним :)
Dawny33

Чому ви все одно можете бачити вихід консолі під час успішних запусків? Я не бачив конфігурації для, і не вважав, що можна показати stdout під час успішного виконання завдання, він повинен просто з’явитися [ok: ім'я хоста]. Однак, коли виявлена ​​помилка, вихід виводиться на консоль управління ansible (і визначені будь-які журнальні журнали), чи не заперечуєте ви поділитися конфігурацією, яка дає вам велику строку під час регулярного успішного запуску?
hvindin

@hvindin Введіть -vvvпісля ansible-playbookкоманди для отримання багатослівних журналів.
Dawny33

1
Реєстрація змінної здається найкращим логічним кроком, дивіться мій коментар до вашої відповіді щодо моїх думок про те, що робити з виходами з команд, що спрацьовують за допомогою ансиву.
hvindin

Відповіді:


4

[Перетворення мого коментаря у відповідь]

Один із способів зробити це - записати журнали в якийсь зовнішній файл, а потім мати після нього завдання, яке використовує умову fail_when, і видалити файл журналу, якщо попереднє завдання було успішним.

Щось подібне повинно вам допомогти.

 - name: Run Py script
      command: <>.py  > <>.log
      become: yes
      register: PyScript
      ignore_errors: True

    - name: PyScript on success
      command: rm <>.log
      when: PyScript|succeeded

Примітка. Це може бути не найкращим способом вирішення вашої проблеми. Але це був хак, який допоміг мені зробити мої реєстрації та моніторинг.


2
Я б пішов ще один і сказав, що ви можете зберегти написання команди на stdout / stderr, а потім просто скинути їх як відповідь на невдачу. Отже, як приклад у наведеному вище прикладі, якщо ви хотіли зупинити виконання у разі відмови, використовуючи завдання провалу, щоб просто вивести stdout та stderr, зареєстровані в PyScript, коли rc! = 0 здасться більш цілісним рішенням. Якщо ви використовуєте вбудовані механізми ansibles, то якщо у вас є приклад налаштування ansible logging на керувальному сервері, то цей сервер управління записуватиме помилку в журнал ansible. Що я думаю , що було б правильним для нього місце
hvindin

3

Я думаю, що все, що вам потрібно зробити, це зареєструвати вихід кожної потрібної вам команди (збережіть її в змінній), а потім просто скинути змінну у файл. Таким чином ви зможете переглянути його згодом.

tasks:
  - name: Dump all vars
    action: template src=templates/dumpall.j2 dest=/tmp/ansible.all

Потім у dumpall.j2:

Module Variables ("vars"):
--------------------------------
{{ vars | to_nice_json }} 

Environment Variables ("environment"):
--------------------------------
{{ environment | to_nice_json }} 

GROUP NAMES Variables ("group_names"):
--------------------------------
{{ group_names | to_nice_json }}

GROUPS Variables ("groups"):
--------------------------------
{{ groups | to_nice_json }}

HOST Variables ("hostvars"):
--------------------------------
{{ hostvars | to_nice_json }} 

Приклад, який я використовую, звідси


3

Я вирішив це, додавши

ignore_errors: true
register: results

до завдання no_log. Це змушує відповідального продовжувати переходити до наступного завдання, навіть коли завдання не вдається. Потім для наступного завдання визначте завдання налагодження, яке завжди виходить з ладу та видає зареєстровану змінну, але виконується лише тоді, коли попереднє завдання не вдалося:

- name: Error output
  debug:
     var: results
  failed_when: true
  when:
     results is failed

Так що навіть з no_log: true, це зробить ангіблетним відображення результату невдалої задачі. Це рішення не записує його у файл, як вимагається, але повною мірою виконує необхідність "побачити журнал, коли не вдалося", і, звичайно, ви можете перенаправити або використати tee, щоб вивести повний відповідальний висновок у файл, який буде з цим рішенням також містять журнал невдалого завдання.


2

Що я роблю, коли я маю команду виконувати та бажаю отримати журнал лише у разі відмови, це наступне (з префіксом командної оболонки, як /bin/sh -c '...'у випадку, якщо ініціатор не використовує systemвиклик або виконує команду безпосередньо без оболонки) :

command 2&>1 > command-log.txt || cat command-log.txt

Це призведе до переадресації помилки та стандартного виводу у файл та відображатиме вміст файлу лише у разі відмови. Якщо команда дуже багатослівна і ви не хочете вести журнал, коли це нормально, ви можете перейти з:

command 2&>1 > command-log.txt && rm command-log.txt || cat command-log.txt

Цитата &&та ||використання на сторінці man sh :

Символ && (||) призводить до того, що наступний список буде виконаний, лише якщо попередній трубопровід повертає нульове (не нульове) значення.

Це, мабуть, не самий ідіоматичний спосіб зробити це за допомогою ansible, але він має перевагу в тому, що він є дуже портативним з будь-якою системою управління конфігурацією, що дає можливість відображати команду stdout.


0

Якщо припустимо, що ansible належним чином видаляє помилки до stderr, ви можете зафіксувати вихід помилок у будь-якій програмі до файлу, використовуючи переспрямування виводу:

some command 2> error.log

Однак я не думаю, що це так.

Натомість, ви, ймовірно, захочете звернутися до цього посібника, щоб вирішити, коли виникнуть помилки http://docs.ansible.com/ansible/playbooks_error_handling.html, а потім виберіть свій висновок для рядків, які вказують на помилку перед виходом у файл

тобто.

ansible-playbook my-playbook | grep 'error' > error.log


-2

Я думаю, що те, що ви шукаєте, може бути занадто простим перенаправленням stdout та вулицею до файлу.

Як правило, деяка команда &> logfile.log

або якийсь варіант ....


Що є лише частковою відповіддю, ОП хоче побачити журнал у випадку помилки.
Тенсібай

Я не знаю, це навіть часткова відповідь на це питання. Це добре для сценарію оболонки, але марно для кодування в ansible .
пташенята

@chicks Я думаю, що це може бути правильним вирішенням методу "оболонки" в підході ansible (про який я не знаю багато)
Tensibai

-2

Трійник буде дуже простим інструментом для ведення журналів, ви можете посилатися на наступну команду.

eric@eric-MacBookPro:~$ ansible -m ping all | tee > /tmp/ansible.log
eric@eric-MacBookPro:~$ cat /tmp/ansible.log 
localhost | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

2
1. Це впливає на весь пробіг, а не лише на одне завдання. 2. Немає сенсу прошивати трійник, якщо ви збираєтесь перенаправляти його stdout у файл; це не те, як ви використовуєте команду. 3. Якщо ви правильно використовували трійник, він все одно виводить увесь спам на консоль, чого OP не хоче.
Xiong Chiamiov
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.