Comments 5
Вся конфигурация лежит в базе данных. Зачем дублировать это еще и в XML?
Запросы к БД решают всё. В том числе — к событиям аудита.
Уж если и просить новую фичу — то API к событиям аудита, а не «configuration as code».
Ваш подход напоминает велосипедостроение — без обид.
Дублируем в XML и YAML. XML для возможности импорта (отката) обратно, YAML для удобства чтения и ревью.
Запрос к API к событиями аудита и выставление данных в той форме, которая необходима для ревью (возможность комментировать, диффать, быстро понимать какие изменения произошли) сложнее реализовать чем предложенный выше подход.
За спрос денег не берут, мы попросили что кажется важнее для нас, т.к. мы с таким подходом работали и понимаем насколько он удобен.
Если комбинацию из уже существующих инструментов принято называть велосипедом — то да, это велосипед, но он отлично едет.
allburov Спасибо за статью. Скажите задумывались ли вы над темой Zabbix как Код или полное управление Zabbix только через скрипты/API?
Задумывались, смотрели готовые решения Zabbix as Code, есть интересное (https://github.com/adubkov/zabbixcli), но видимо не взлетело, изменения были 4 года назад. Реализовывать и поддерживать такую систему сложно, поэтому решили не делать, не те объемы работ с заббиксом.

Управление через API хорошо идет с software configuration management, когда у тебя создаются VM, на них накатываются определенные роли, и автоматом создаётся и хост в заббикс и прикрепляются шаблоны. Но наполнение профилей\ролей идет по прежнему в ручную, через UI. К такому решению идем, но пока не реализовали. Готовые модули есть и для ansible и для salt, можно брать и использовать.
Only those users with full accounts are able to leave comments. Log in, please.