Продвигаясь по пунктам нашего плана развёртывания Icinga 2 на Debian 12, в прошлый раз мы провели развёртывание бакэнда Icinga DB и фронтэнда Icinga Web 2, а также выполнили инициализацию Master-сервера Icinga. Поэтому теперь мы готовы развернуть модуль Icinga Director и провести миграцию конфигурационных данных из старого экземпляра Icinga Director в новый.
Установка Icinga Director
Рассмотренный ранее пример установки Icinga Director 1.2.0 на Debian 8.6
применительно к нашему развёртыванию на Debian 12 будет мало подходящим, поэтому вооружимся опорным документом по установке "Installing Icinga Director on Debian" и пройдём этот процесс с несколько иными настройками.
Для работы актуальной версии Icinga Director 1.11.1 согласно документации потребуется СУБД MySQL 5.7 или новее, MariaDB 10.1 или новее, либо PostgreSQL 9.6 или новее.
В первой части нашего описания мы уже установили СУБД MariaDB. Создадим новую пустую базу данных под хранение конфигурации модуля Icinga Director.
Подключимся к командному интерфейсу MariaDB:
# mariadb -u root -p
Выполним SQL-запросы на создание новой пустой БД с именем "icingadirector", а также на создание в MariaDB отдельного пользователя "icingadirector-usr", которому предоставим полные права на работу с новой БД:
CREATE DATABASE icingadirector CHARACTER SET 'utf8';
CREATE USER 'icingadirector-usr'@localhost IDENTIFIED BY 'MyRW0rd!5';
GRANT ALL ON icingadirector.* TO 'icingadirector-usr'@localhost;
exit
Из официального репозитория Icinga установим на пакет модуля Icinga Director:
# apt-get install icinga-director
В систему будет добавлена служба icinga-director.service.
После этого перейдём в веб-консоль Icinga Web 2 и в структуре навигации выберем "Configuration" > "Application" > вкладка "Resources". Здесь с помощью кнопки "Create a New Resource" создадим запись о новом ресурсе с типом "SQL Database", который будет ссылаться на базу данных, которую мы только что создали в MariaDB:
После ввода данных о созданной БД нажимаем кнопку проверки подключения "Validate Configuration". В случае успешного подключения в верхней-части веб-страницы появится соответствующая информация:
После этого сохраняем новый ресурс БД кнопкой "Save Changes".
Перейдём в главном меню в раздел "Icinga Director" и на вкладке "Setup" выберем только что созданный "DB Resource".
После этого должна появится кнопка "Create schema", которую мы нажимаем для импорта схемы в ранее созданную нами пустую БД с именем "icingadirector".
После создания схемы в базе данных веб-страница обновится и на странице появится новый раздел "Kickstart Wizard", где нам будет предложено ввести данные для подключения модуля Icinga Director к Icinga API нашего сервера.
В качестве значения поля "Endpoint Name" нужно использовать имя Common Name (CN) из SSL-сертификата, который был сгенерирован в процессе включения Icinga API (путь к этому сертификату виден в выводе команды "icinga2 api setup"):
# openssl x509 -noout -subject -in /var/lib/icinga2/certs/KOM-MON01.holding.com.crt
subject=CN = KOM-MON01.holding.com
В качестве значения полей "Icinga Host" и "Port" указываем всё то же имя нашего сервера Icinga и порт Icinga API, который мы ранее открывали в брандмауэре.
В поля "API User" и "Password" вписываем учётные данные API-пользователя "root", полученные нами ранее из файла /etc/icinga2/conf.d/api-users.conf.
После заполнения указанных полей нажимаем "Run Import".
Произойдёт импорт конфигурации Icinga из всех конфигурационных файлов в базу данных Icinga Director. Чтобы применить все эти изменения, перейдём в главном меню в раздел "Icinga Director" > "Activity log" и на первой вкладке выполним развёртывание изменений конфигурации через гиперссылку "Deploy … pending changes".
Перейдём в главном меню в раздел "Icinga Director" на вкладку "Health" и проверим текущее состояние модуля Icinga Director.
Развёртывание Icinga Director успешно выполнено и теперь можно переходить к наполнению конфигурации.
Миграция данных Icinga Director с помощью Configuration Baskets
Теоретические вопросы и приёмы практического применения Icinga Director можно получить из материалов, которые мы рассматривали ранее:
"Базовая настройка конфигурации Icinga с помощью Icinga Director", "Переопределение аргументов выполнения Команд в Icinga Director", "Создание собственной Команды с набором аргументов в Icinga Director". В текущей ситуации у нас нет задачи настраивать с нуля всю конфигурацию в Icinga Director, а нужно как-то перенести накопленные на старом сервере данные о таких типах объектов Icinga Director как:
- Поля Данных (Data Fields) и Списки Данных (Data Lists);
- Команды (Commands);
- Шаблоны Служб (Service Templates) и Группы Служб (Service Groups);
- Правила применения Служб (Service Apply Rules);
- Шаблоны Хостов (Host Templates), Хосты (Hosts) и Группы Хостов (Host Groups);
- Шаблоны Пользователей (User Templates), Пользователи (Users) и Группы Пользователей (User Groups);
- Шаблоны оповещений (Notification Templates) и Оповещения (Notifications)
- Периоды Времени (Time Periods)
Все эти типы данных, за исключением Hosts и Service Apply Rules, со старого сервера на новый нам поможет скопировать такой механизм Icinga Director как Конфигурационные Корзины (Configuration Baskets).
О том, как скопировать данные о Хостах мы поговорим отдельно чуть позже.
Что же касается таких типов данных, как Правила применения Служб (Service Apply Rules), то следует отметить, что Корзина не поддерживает этот тип данных. Есть ветка обсуждения "Basket: add hosts/services/service apply to basket #1811", где сам Thomas Gelf намекает на то, что Service Apply Rules это моветон и лучше переходить на использование Service Sets. Поэтому, как мы отметили в первой части, на новом сервере Icinga мы откажемся от использования Service Apply Rules в пользу более современного механизма Наборов Служб (Service Sets). Разумеется, в дальнейшем это выльется для нас в дополнительные трудозатраты и потребует создания новых объектов типа Service Sets для обеспечения связки между Хостами и Службами.
Далее пошагово рассмотрим последовательность действий по копированию данных с помощью Корзины со старого (исходного) сервера на новый (целевой).
Шаг 1. Создание Конфигурационные Корзины на исходном сервере
На исходном сервере Icinga в интерфейсе Icinga Director создаём новый объект Configuration Basket:
Задаём для Корзины произвольное имя и в свойствах выбираем те типы объектов, которые мы хотим скопировать на целевой сервер Icinga. В нашем случае был выбран тип сохранения "All ot them" для тех типов объектов, которые используются в нашем окружении: Command Definitions, Host Group, Host Templates, Service Groups, Service Templates, User Groups, User Templates, Users, Notification Templates, Notifications, Time Periods, Data Lists.
Обратите внимание на то, что при создании Корзины нет возможности включения в явном виде такого типа данных, как Поля Данных (Data Fields), однако все Поля Данных, задействованные в каких-либо других типах переносимых данных, будут включены в состав Корзины в автоматическим режиме, то есть реально используемые в конфигурации данные типа Поля Данных переносятся как зависимость для всех включенных в Корзину объектов.
После сохранения созданной Корзины появится дополнительная вкладка "Shapshots". Перейдём на эту вкладку и нажмём кнопку создания снапшота. После этого в списке ниже появится информация о созданной копии конфигурации всех обозначенных в свойствах Корзины типов объектов.
Здесь мы можем видеть какое количество объектов разных типов попало в снапшот. Обратите внимание на то, что среди объектов имеется Datafield. То есть, как мы и отметили выше, в снапшот автоматически попадают все объекты типа Data Field, на которые имеются ссылки в других объектах, которые отмечены для сохранения.
Перейдём по гиперссылке на снапшот и откроется форма просмотра его содержимого, где с помощью ссылки "Download" скачиваем JSON файл, содержащий все данные снапшота.
Имя файла будет иметь примерно следующий вид: Director-Basket_Basket_for_migration_acda3ce.json
Шаг 2. Корректировка JSON файла с данными снапшота Корзины
В JSON файле, который мы выгрузили с исходного сервера, могут присутствовать отсылки на конфигурационную Icinga Zone, которая может отсутствовать на целевом сервере Icinga.
Поэтому нам потребуется с помощью любого текстового редактора произвести поиск и замену всех ссылок на зону исходного сервера на имя зоны целевого сервера. Если этого не сделать, то при дальнейшей попытке восстановления из JSON файла мы можем получить ошибки следюущего типа:
Unable to load object (zone: KOM-MON00.holding.com) referenced from service "Disk", failed to load icinga_zone "KOM-MON00.holding.com" (IcingaObject.php:565)
То есть, в нашем случае со старым сервером KOM-MON00 и новым сервером KOM-MON01 нужно найти в файле все строки вида:
"zone": "KOM-MON00.holding.com"
… и заменить эти сроки на строки вида:
"zone": "KOM-MON01.holding.com"
Шаг 3. Восстановление данных из JSON файла на целевом сервере
Переходим в веб-консоль Icinga Web 2 целевого сервера Icinga и в интерфейсе Icinga Director в разделе "Configuration Baskets" используем ссылку "Upload".
Укажем ранее выгруженный и откорректированный JSON файл, присвоим создаваемому объекту типа Configuration Basket произвольное имя и нажмём кнопку "Upload".
В результате загрузки файла будет создан новый объект типа Configuration Basket. Перейдём в его свойствах на вкладку "Snapshots" и откроем свойства снапшота.
Здесь воспользуемся ссылкой "Restore". Появится дополнительно поле для выбора целевой базы данных Icinga Director. Выберем текущую БД и нажмем кнопку "Restore".
При успешном восстановлении объектов из снапшота внизу экрана появится соответствующее сообщение
Теперь нам остаётся применить на целевом сервере новую конфигурацию со всеми импортированными из JSON объектами.
В главном меню навигации Icinga Director в разделе "Activity log" появится уведомление о большом количестве изменений (по одному отдельному изменению на каждый импортированный объект конфигурации). Выполним применение новой конфигурации используя ссылку "Deploy…".
Развёртывание новой конфигурации Icinga Director с учётом импортированных объектов не должно вызывать никаких ошибок.
На этом процедуру копирования объектов с исходного сервера на целевой с помощью Корзины можно считать законченной. Остаётся выборочно проверить скопированные объекты и можно удалять ранее созданную нами Configuration Basket.
Миграция данных о Хостах (Hosts)
Как мы отметили ранее, с помощью Конфигурационной Корзины нельзя перенести между исходным и целевым сервером объекты типа Хост (Host). Однако, для выполнения этой задачи есть другой вариант действий. Рассмотрим пошагово эту процедуру.
Шаг 1. Выгрузка Хостов в JSON файл на исходном сервере
На исходном сервере Icinga в интерфейсе Icinga Director на вкладке "Hosts" открываем выпадающее меню на кнопке следующей после листинга страниц и выбираем пункт выгрузки информации о Хостах в JSON файл "Download as JSON".
Имя файла будет иметь примерно следующий вид: director-host_20240507140001.json
Шаг 2. Корректировка JSON файла
С помощью любого текстового редактора отредактируем полученный JSON файл.
Выполним поиск и удаление всех строк следующего вида (этих строк будет столько, сколько записей о хостах):
"fields": [],
Если этого не сделать, то при дальнейшей попытке восстановления из JSON файла, мы можем получить ошибки типа:
ERROR: InvalidArgumentException in /usr/share/icingaweb2/modules/director/library/Director/Data/Db/DbObject.php:363 with message: Trying to set invalid key "fields"
Возможно, в нашем случае это связано с тем, что на целевом и исходном сервере версии модуля Icinga Director не совпадали и имели место быть различия в хранимых атрибутах объектов типа Hosts.
Шаг 3. Импорт Хостов из JSON файла на целевом сервере
Используем скрипт для импорта данных из JSON файла на целевой сервер Icinga.
Создаём простой скрипт, который поможет нам загрузить из JSON файла данные о Хостах посредствам вызова утилиты icingacli:
# nano import-director-hosts.sh
Содержимое скрипта:
#!/bin/bash
#
JSONFile="$1"
JSONData=$(cat $JSONFile | jq -c '.objects[]');
readarray -t JSONHosts < <(echo "$JSONData")
for i in "${JSONHosts[@]}"; do
JSONHost=$(echo $i | jq -r .object_name)
echo "Processing $JSONHost"
icingacli director host create $JSONHost --json "$i"
#icingacli director host set $JSONHost --disabled 1
done
В качестве единственного входящего параметра скрипт принимает путь к JSON файлу. Если нужно, чтобы при добавлении Хостов на новый сервер Icinga запись о Хосте выключалась, раскомментируйте предпоследнюю строку.
Для работы скрипта потребуется утилита jq, поэтому выполним её установку:
# apt-get install jq
Делаем скрипт исполняемым и запускаем его на целевом сервере, передав ему в качестве параметра путь к файлу JSON:
# chmod +x import-director-hosts.sh
# ./import-director-hosts.sh /home/user/director-host_20240507140001.json
Внимательно изучаем вывод скрипта и убеждаемся в том, что все Хосты добавлены в Icinga Director без каких-либо ошибок. Кроме того, мы можем просмотреть импортированные из файла Хосты в веб-консоли Icinga Web 2 в разделе Icinga Director на вкладке "Hosts".
Теперь нам остаётся применить на целевом сервере новую конфигурацию со всеми импортированными из JSON Хостами.
В главном меню навигации Icinga Director в разделе "Activity log" появится уведомление о большом количестве изменений (по одному отдельному изменению на каждый импортированный Хост). Выполним применение новой конфигурации используя ссылку "Deploy…".
Развёртывание новой конфигурации Icinga Director с учётом импортированных Хостов не должно вызывать никаких ошибок.
На этом процедуру копирования Хостов с исходного сервера на целевой можно считать законченной. Учитывая то, что файл JSON может содержать чувствительную информацию о разных Хостах (токены доступа, логины, пароли и т.п.), не забываем удалить все временные копии файла JSON.
Настройка оповещений в Icinga Director
Процедуру настройки оповещений по электронной почте в Icinga Director мы ранее подробно рассматривали в статье "Настройка e-mail оповещений в Icinga Director". Можно сказать, что в целом процедура применима и на уровне текущей новой инсталляции Icinga Director на базе ОС Debian 12.
В Debian 12 не установлено по умолчанию никакого ПО для отправки почты. Можно установить простой почтовый клиент msmtp, с помощью которого на сервере мониторинга появится возможность отсылать письма на Smart Host, то есть, например, на полноценный почтовый сервер в корпоративной сети. Но проблема в том, что утилита msmtp сама по себе не имеет почтовой очереди, то есть требует постоянной доступности сервера Smart Host. И если по какой-то причине msmtp не достучится до Smart Host, то письмо попросту не будет отправлено. Учитывая то, что мы настраиваем отсылку почты под систему мониторинга, где возможен постоянный интенсивный процесс отсылки писем разным получателям, нужно позаботится о наличии локальной почтовой очереди (на случай кратковременной недоступности Smart Host), чтобы письма не терялись. Вообще в msmtp имеется некоторый скриптовый механизм (msmtp-enqueue.sh) для поддержки очереди отправки через файл ~/.msmtpqueue, но это всё выглядит как-то "костыльно".
В нашей ситуации для отправки почты правильным выбором будет более серьёзное ПО, имеющее полноценный механизм работы с очередью, поэтому мы установим на сервере пакет exim4:
# apt-get install exim4
Описание базовой настройки exim4 на отсылку писем через Smart Host можно найти в статье
Вики: "Как настроить отсылку уведомлений на внешний почтовый сервер с помощью exim4 в Debian 8 (Jessie)", информацию из которой можно применить и в Debian 12.
Что касается оповещений путём отсылки SMS сообщений в Icinga Director, то вся теоретическая и практическая часть настройки ранее нами была подробно рассмотрена в статье "Настройка SMS оповещений в Icinga Director 1.3". И в принципе, всё описанное в этом материале, справедливо и для новой инсталляции на актуальной версии Icinga Director 1.11 в Debian 12. Кроме того, на новой инсталляции Icinga Director успешно проверен и применён способ отсылки уведомлений, описанный в более поздней заметке "Отсылка SMS оповещений в Icinga с помощью MultiTech MultiModem iSMS SF800-G".
Учитывая то, что все типы объектов, связанных с оповещениями и требующих настройки в Icinga Director (User Groups, User Templates, Users, Notification Templates, Notifications, Time Periods) мы успешно перенесли на новый сервер Icinga с помощью описанного выше механизма Конфигурационной Корзины. Поэтому, всё что нам остаётся сделать на новом сервере – это скопировать на него скрипты, отвечающие за отсылку оповещений. Варианты таких скриптов можно найти здесь: Icinga_notification-to-email , Icinga_notification-to-sms , Icinga_notification-to-iSMS.
RSS - Записи
Добавить комментарий