Ansible больше чем shell/script

[TidalPoo]

Название статьи выбрано не случайно. В производственной среде системные администраторы чаще используют ansible как инструмент выполнение bash или .py на целевой машине.

Такое использование приводит администраторов к написанию скриптов, и чем больше они пишут, тем больше погружаются в зависимости от внешних библиотек и так далее.

Так же и я, впервые столкнувшись с ansible понял, что им можно запускать скрипты, и понеслась. Один скрипт, другой, либа, ещё либа, и ещё либа. В принципе всё шло благополучно, пока не встал вопрос миграции с со стендов разработчика на боевые сервера.

В процессе такой миграции выяснялось, что заказчик использует закрытые сети, без доступа к внешнему миру. Казалось бы, да что тут такого, сейчас всё сделаем. Сделали, запустили, и началось…

dependencies **** not found, method not found…

А дальше всё становилось только хуже. Администраторы безопасности люди с Челябинска, жесткие на правила, и запретили любое импортирование файлов из вне. Чтож, на пару библиотек мы смогли договорится спустя почти неделю бюрократического хаоса. Только поздно вспомнили, что одна либа тянет за собой ещё, и порой их кол-во растёт с геометрической прогрессией.

К чему вся эта преамбула. Да к тому, что методы ansible могут выполнять огромное кол-во различных операций без написания скриптов.

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

В одном из последних проектов, мне необходимо было:

• деплоить на боевые сервера утилиты стресс тестов
• запускать эти самые утилиты стресс тестов
• замерять метрики с api систем мониторинга до и после запуска утилит
• генерировать средне-арифметические данные на промежутках
• формировать html отчет с неизвестным кол-вом метрик/графиков и переменных
• ну и где-то этот отчет размещать, либо отправлять по email

С учетом такого ТЗ в голову первым делом пришли мысли понаписать скриптов. Но к моему удивлению, всё было сделано без использование последних, только на доступных методах ansible. Даже коллекции не пришлось использовать. Хотя для k8s наверно всё-таки придётся скачать.

Одна из наиболее сложных задач была получить с zabbix средне-арифметическое значение метрики за определенный промежуток времени. Первая проблема заключалась в том, что zabbix не отдает такие значения. trend.get — отдает только часовые avg значения, а history.get только значения за промежуток. Как же тогда подсчитать? Всё оказалось проще чем хотелось бы:

• запрашиваем history.get
• в ansible выполняет манипуляции с данными json

- name: "Запрашиваем значения метрики {{ zabbix_graph_item_id }}"
  uri:
    url: http://xxx.xxx.xxx.xxx:xxx//api_jsonrpc.php
    method: POST
    body_format: json
    return_content: yes
    headers:
      Content-Type: application/json-rpc
    body: |
      {"jsonrpc": "2.0","method": "history.get","params": {"output": "extend","history": 0,"itemids": "{{ zabbix_graph_item_id }}","time_from": {{ (work_flow_start_time_epoch | int) - 1800 }},"time_till": {{ work_flow_start_time_epoch | int }}},"auth": "xxxxxxxxx","id": 1}
  register: web_out

- name: "Вычисляем среднее значение метрики"
  set_fact:
    metric_avg: "{{ (web_out.content | from_json | json_query('result[*].value') | map('float') | list | sum) / (web_out.content | from_json | json_query('result[*].value') | list | length) }}"

В процессе миграции, нам почти не понадобилось ничего дополнительно и развертывание на боевых серверах заняло значительно меньше времени, чем при перетаскивание зависимых библиотек.

Удачного DevOps вам друзья.