Системное администрирование

Итак, в прошлом посте читатель узнал, что у меня завелось 55 микротиков. За прошедшее время, по заветам комментаторов, был развернут ELK Stack. Это такая штука для сбора логов со всего, что может эти логи слать. ELK = Elasticsearch + Logstash + Kibana.

Настраивала вот по этим двум статьям, в принципе там всё понятно. Раз и два.

Но помним, что микротиков сильно больше пары штук – это раз. Второе, если прописывать все их в фильтры сборщика логов, то появляется ещё одно место, куда надо что-то писать руками при вводе микротика в эксплуатацию, что не есть хорошо. Да и лень мне было прописывать их все. Короче, во мне стал зарождаться DevOps.

Задача - чтобы в заббиксе мы микротик завели – а логи с него автоматом бы полились и уже с меткой mikrotik.

Я слегка погружусь в теорию, чтобы было понятнее, что мы делаем. Итак, развернут ELK – изначально логи попадают в logstash, где с ними можно что-то сделать. Например, мы отбираем по некоторым критериям логи микротиков и вешаем на них метку «Mikrotik». Этим критерием у меня является IP – то есть «если ip из вот этого перечисления, то это микротик». Если бы у нас был ELK только для микротиков – мы бы просто вешали метку на весь трафик или обошлись без неё, но мы потом хотим добавлять еще логи всякого, например, виндовых серверов. После обработки логи попадают в elasticsearch, где мы их просматриваем с помощью Kibana (это типа веб-морда).

Для начала нам надо получить список микротиков из zabbix. Я использую для этого скриптик на питоне, который получает ip по группе и сразу генерирует кусок конфига, который будет в logstash filter.

Сперва надо установить модули zabix для питона:

apt install python3-pip

pip3 install pyzabbix

Теперь нам надо получить id группы в zabbix – его можно посмотреть в адресной строке браузера на странице группы – там в конце будет что-то типа groupid=65

Cам скрипт ниже. Мне не захотелось заморачиваться и один первый хост у меня всегда дублируется, вы можете заморочиться.

Получается строка вида «if [host] in ["10.1.1.254", “10.2.2.254”]{»

Теперь её надо вставить в правильное место конфига logstash. Чтобы этого добиться, я ставлю метку #MIKMIKMIK туда, куда будет вставлена получившаяся строка.

Вставлять будем с помощью Ansible, один раз вставится, потом будет проверяться на соответствие. Собственно из-за этого и выбран Ansible – он сам будет проверять наш конфиг на соответствие и вносить изменения только, если они есть.

Вот так выглядит /etc/logstash/conf.d/filter.conf до первой работы анзибля

Теперь собираем котлету вместе. Делаем playbook в ansible, который запустит нам скрипт, потом получившийся конфиг вставит в конфиг logstash, и если зафиксированы изменения – перезапустит службу. Со службой я долго не могла понять – почему перезапуска не происходит и ansible отваливается по timeout – ему просто не хватало прав.

write_logstash.yml:

Ну и запихиваем скрипт в крон делаться каждый час.

15  *  *  *  * ansible-playbook /usr/scripts/write_logstash.yml

Опытный читатель спросит – и что же, нам теперь на 55 микротиках настраивать логирование? И мы возвращаемся к предыдущему моему посту (и понимаем, зачем нам это было надо). Вот пример настройки лог-сервера, при этом в команде к каждому микротику указывается его IP в качестве источника данных. Без этого у меня автоматом выбирался служебный ip с интерфейса ip-ip туннеля и это было неудобно.

Ну и уровень логирования настраивается так же, только команду заменить.

В итоге мы получили что хотели – достаточно добавить микротик в заббикс и настроить на нем пересылку логов, а в ELK оно попадёт автоматом с нужной меткой.

Получился маленький кирпичик автоматизации, но путь в DevOps иногда начинается с одного шага..

Код текстом.

Внезапно появилось у меня 50 микротиков по филиалам. Задача – настроить бэкап в систему контроля версий и получить возможность выполнить какую-то настройку на всех микротиках, где этой настройки нет. Вторая задача стояла – научиться что-то делать в ansible. Тут ansible не содержит особых преимуществ перед обычным bash скриптом, кроме, может, скорости работы за счет параллельности выполнения.

Все мануалы, что я нашла, содержали инструкцию по бэкапу в ansible одного микротика и такие типа «экстраполируйте сами». Ну зашибись, вся проблема в том, что имя бэкапа задаётся вручную, а если микротиков много, то как-то сделанные бэкапы надо различать.

В микротике есть поле identity и логично было бы именем из identity и называть бэкап. Но вначале я не нашла как его сохранить в переменную и пошла задавать переменные вручную. Кому интересно про identity – переходите к способу 2.

Я опущу, как ставить ansible, задавать пароли и шифровать их, это как раз легко гуглится.

Способ с заданием имени бэкапа в переменной вручную.

ansible_user должен иметь доступ на микротик full, а сервер, с которого запускаете yml должен иметь доступ по ssh на микротик. При этом либо надо разок законнектиться по ssh до этого и сохранить ключи, либо отключить проверку ssh ключей в ansible.

Пикабу съедает пробелы. Ссылка на код текстом будет в конце

Но всё же меня глодала мысль, что можно использовать identity, а тут удачно работа оплатила курсы по всяким там девопс штукам и мне рассказали про register. Так что нет ничего невозможного, смотрите далее.

Способ с бэкапами микротика по identity

Тут проблема в том, что stdout_lines возвращает штуку типа [[u’name: Kostroma]] и как я ни крутила – как к массиву я к ней обратиться не могу. Так что немного через задницу (буду рада, если подскажете красивое решение) из этой строки выковыривается строка с непосредственно identity.

Теперь убираем в hosts file_name

Про то, как делать текстовый бэкап – в примере 1, скрестить ужа с ежом можете сами.

Мой скрипт по запихиванию в систему контроля версий и отсылки на почту. Вот тут я писала подробнее как настроить SVN

#!/bin/bash

now=$(date +"%d_%m_%Y")

rm /usr/scripts/log.txt

ansible-playbook --vault-password-file /etc/ansible/vault_pass_file /usr/scripts/mik-backup.yml >> /usr/scripts/log.txt

cd /usr/svn_backup_repo/DFL_BACKUPS

svn add mikrotik/* --force -q >> /usr/scripts/log.txt

svn commit -m "added backups $now" >> /usr/scripts/log.txt

/usr/bin/mail it@mydomain.ru < /usr/scripts/log.txt -s "Отчет о бэкапах Mikrotik"

Иммутабельность – это неизменность. То есть если уже, например, в файле есть такие изменения, то второй раз они не делаются. Это то, в чем фишка Ansible и то, что не реализовано для микротиков (так как например в firewall важен порядок применения – это одна из причин, почему в его конфиге не поддерживается иммутабельность).

Теперь сюжет из жизни: мне понадобилось вкатить на все микротики одинаковый фильтр сетей OSPF – оставить только серые сети и фильтрануть по маске 10.0.0.0/8. При этом на каких-то микротиках я это уже делала, но не помню на каких. Прощелкать 50 штук – ну такая себе забава.

Итого сливается бэкап в текстовом виде, идет поиск по нужной строке и если она не найдена, то выполняем команду. А если найдена – ничего не делаем. Такая вот псевдо-иммутабельность получается. Да, один скрипт – одна команда, что не очень удобно, под список команд надо дорабатывать.

Сылка на весь код текстом вот

Ну и я не претендую на гуру, только-только начала щупать Ansible, надеюсь кому-нибудь пригодится.