Buildroot: Створення кросплатформової прошивки з zabbix-server

Історія завдання

Невеликі за розміром фірми з одного боку потребують якісного моніторингу своєї інфраструктури (особливо у світлі повсюдної віртуалізації), з іншого боку, для них фінансово важко закуповувати нове обладнання. Також часто зустрічаються проблеми з серверною/апаратною: найчастіше стоїть 1-3 tower-сервера поруч із користувальницькими робочими місцями або в невеликій ніші/комірці.

Простіше використовувати вже готове складання (дистрибутив), який достатньо залити на microSD-карту і вставити в розповсюджений одноплатний комп'ютер (beaglebone, сімейства raspberry pi та orange pi, asus tinker board). Крім того, таке обладнання коштує недорого і може бути встановлене будь-де.

Постановка завдання

Багато в чому проект розвивався як якась лабораторна робота з можливістю застосування результатів.

Як система моніторингу був обраний zabbix, тк це потужна, безкоштовна і добре документована система.

Ставити окрему машину під моніторинг теж не дуже гарне рішення - або дорого закуповувати нове обладнання, або шукати старе + у невеликих фірмах часті проблеми з серверною/апаратною.

Використання системи складання buildroot дозволяє створювати спеціалізовані рішення, які можуть експлуатуватися персоналом з мінімальними знаннями сімейства Linux. Ця система дружелюбна до новачків, але при цьому дає широкі можливості кастомізації в руках досвідченого розробника. Вона відмінно підходить для вирішення завдання не дорогого, але повнофункціонального моніторингу ІТ-інфраструктури, мінімально вимогливого до підготовки персоналу, що експлуатує її.

Кроки рішення

Вирішено було спочатку створити прошивку під x86_64 для запуску в qemu, оскільки це зручне та швидке рішення для налагодження. Після цього портувати на одноплатний комп'ютер arm (мені сподобалася asus tinker board).

В якості системи збирання було обрано будівлюдроту. Спочатку в ньому відсутній пакет zabbix, тому довелося його портувати. Були проблеми з російською локаллю, які вирішилися накладенням відповідних патчів (примітка: у новіших версіях buildroot ці патчі вже не потрібні).

Портування пакета zabbix буде описано в окремій статті.

Так як все має працювати як прошивка (незмінний образ системи + файли конфігурацій/бази даних, що відновлюються), то потрібно було написати свої systemd таргети, сервіси і таймери (target, service, timer).

Було прийнято рішення про розбиття носія на 2 розділи — розділ із файлами системи та розділ із змінними конфігами та файлами бази даних zabbix.

Трохи складніше виявилося вирішення завдань, пов'язаних із базою даних. Розміщувати її на носії мало хотілося. У той же час розмір бази може досягти розміру, що перевищує розміри можливого ramdisk'а. Тому було вибрано компромісне рішення: база даних розміщується на другому розділі sd-картки (сучасні SLC-картки мають до 30 000 циклів запису), але є налаштування, що дозволяє використовувати зовнішній носій (наприклад, usb-hdd).

Моніторинг температури було реалізовано через пристрій Rodos-5. Звичайно, можна використовувати Dallas 1820 безпосередньо, але швидше і простіше було встромити USB.

Як завантажувач для x86_64 було обрано grub2. Потрібно було написати мінімальний конфіг для запуску.

Після налагодження на qemu було виконано портування на asus tinker board. У структурі мого оверлея спочатку закладалася кросплатформаність - виділення специфічних для кожної плати конфігів (defconfig плати, завантажувач, генерація образу з розділом системи) і максимальна одноманітність у доналаштуванні файлової системи / створення образу з даними. Через таку підготовку портування пройшло швидко.

Настійно рекомендується прочитати вступні статті:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

як зібрати

Проект зберігається на github
Після клонування репозиторію виходить така структура файлів:

[alexey@comp monitor]$ ls -1
buildroot-2019.05.tar.gz
overlay
README.md
run_me.sh

buildroot-2019.05.tar.gz - архів чистого buildroot
overlay - мій каталог з external-tree. Саме в ньому зберігається все потрібне, щоб зібрати прошивку за допомогою buildroot
README.md — опис проекту та керівництво англійською.
run_me.sh - скрипт, що готує систему збирання. Розгортає buildroot з архіву, прикріплює до нього overlay (через механізм external-tree) та дозволяє вибрати цільову плату для складання

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Select defconfig, press A for abort. Default [0]

Після цього достатньо перейти в каталог buildroot-2019.05 та виконати команду make.
Після завершення складання всі результати складання будуть у каталозі output/images:

[alexey@comp buildroot-2019.05]$ ls -1 output/images/
boot.img
boot.vfat
bzImage
data
data.img
external.img
external.qcow2
grub-eltorito.img
grub.img
intel-ucode
monitor-0.9-beta.tar.gz
qemu.qcow2
rootfs.cpio
sdcard.img
sys
update

Потрібні файли:

• sdcard.img - образ носія для запису на sd-карту (через dd або rufus під wibdows).
• qemu.qcow2 - образ носія для запуску в qemu.
• external.qcow2 - образ external-носія для бази даних
• monitor-0.9-beta.tar.gz - архів для оновлення через web-інтерфейс

Генерація посібників

Писати кілька разів одну й ту саму інструкцію не варто. І логічніше написати один раз в markdown, після чого конвертувати в PDF для скачування і html для веб-інтерфейсу. Це можливо завдяки пакету pandoc.

Разом з тим, генерувати всі ці файли потрібно до того, як збереться образ системи, ті скрипти post-build вже марні. Тому генерація виконана у вигляді пакету manuals. Подивитися можна у overlay/package/manuals.

Файл manuals.mk (який виконує всю роботу)

################################################################################
#
# manuals
#
################################################################################

MANUALS_VERSION:= 1.0.0
MANUALS_SITE:= ${BR2_EXTERNAL_monitorOverlay_PATH}/package/manuals
MANUALS_SITE_METHOD:=local

define MANUALS_BUILD_CMDS
    pandoc -s -o ${TARGET_DIR}/var/www/manual_en.pdf ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
    pandoc -f markdown -t html -o ${TARGET_DIR}/var/www/manual_en.html ${BR2_EXTERNAL_monitorOverlay_PATH}/../README.md
endef

$(eval $(generic-package))

systemd

Світ Linux активно переходить на systemd, довелося це і мені.
З приємних новацій - наявність таймерів. Загалом про них (і не тільки про них) пишеться окрема стаття, але коротко розповім.

Є дії, які слід виконувати періодично. Мені потрібно було запускати logrotate для очищення журналів lighttpd та php-fpm. Найзвичайніше було б написати команди в cron, але я вирішив використовувати монотонний таймер systemd. Таким чином, logrotate запускається через суворий часовий інтервал.

Звичайно, є можливість створення таймерів, які спрацьовують у певні дати, але мені це не потрібно.
Приклад таймера:

• Файл таймера

  
  [Unit]
  Description=RODOS temp daemon timer

[Timer] OnBootSec=1min
OnUnitActiveSec=1min

[Install] WantedBy=timers.target

- Файл сервиса, вызываемого таймером:
```bash
[Unit]
Description=RODOS temp daemon

[Service]
ExecStart=/usr/bin/rodos.sh

Підтримувані плати

Asus tinker board - основна плата, на якій все має працювати. Вибрана як недорога та дуже потужна.

Beaglebone black - перша плата, на якій перевірялася робота (під час підбору більш потужної плати).

Qemu x86_64 – використовується для розробки налагодження.

Як працює

При старті відбувається двоетапне відновлення налаштувань:

• запуск скрипта settings_restore (через сервіс). Він відновлює основні налаштування системи – часовий пояс, локаль, налаштування мережі тощо.
• запуск скрипта prepare (через сервіс) - тут готується zabbix, база даних, виводиться IP в консоль.

При першому запуску відбувається визначення розміру другого розділу карти sd. Якщо ще є не розмічене місце — носій перерозбивається, розділ під дані займає все вільне місце. Це зроблено з метою зменшення розміру настановного образу (sdcard.img). Крім того, в цей момент створюється робочий каталог postgresql. Саме тому перший запуск із новим носієм буде довшим за наступні.

При підключенні зовнішнього диска в момент старту шукає вільний диск і форматує його в ext4 з міткою external.

Увага! При підключенні зовнішнього диска (а також відключенні або його заміні), необхідно зробити бекап і відновлення налаштувань!

Для моніторингу температури використовується пристрій RODOS 5. Виробник дає вихідні утиліти для роботи з пристроєм. При включенні системи стартує таймер rodos, який запускає цю утиліту раз на хвилину. Поточна температура записується у файл /tmp/rodos_current_temp, після чого zabbix може моніторити цей файл як датчик.

Носій зберігання конфігурації монтується в каталог /data.

При запуску системи та підготовці її до роботи в консолі з'являється повідомлення:

System starting, please wait

Після завершення підготовчих робіт воно зміниться на виведення IP-адреси:

current ip 192.168.1.32
Ready to work

Налаштування zabbix для моніторингу температури

Для моніторингу температури достатньо зробити 2 кроки:

• підключити пристрій RODOS до USB порту
• створити data item у zabbix

Відкриваємо веб-інтерфейс zabbix:

• Відкриваємо розділ Configuration → Hosts
• Натискаємо на Items у рядку нашого zabbix сервера
• Натискаємо на Create item

Вводимо такі дані:

• name — на вашу думку (наприклад, serverRoomTemp )
• Type - zabbix agent
• Key - rodos
• Type-numeric
• Units - C
• History storage period — термін зберігання історії. залишив 10 днів
• Trend storage period – термін зберігання динаміки змін. Залишив 30 днів
• New application - server Room Temp

І натискаємо кнопку ADD.

Керування налаштуваннями через веб-інтерфейс

Веб-інтерфейс написано на php. Є основні функції:

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

Вхід до веб-інтерфейсу закритий паролем. Стартова сторінка - керівництво.

Адреса інтерфейсу zabbix: ${ip/dns}/zabbix
Адреса інтерфейсу управління: ${ip/dns}/manage

Запуск у qemu

qemu-system-x86_64 -smp 4 -m 4026M -enable-kvm -machine q35,accel=kvm-device intel-iommu-cpu host-net nic-net bridge,br=bridge0-device virtio-scsi-pci,id= scsi0 -drive file=output/images/qemu.qcow2,format=qcow2,aio=threads-device virtio-scsi-pci,id=scsi0 -drive file=output/images/external.qcow2,format=qcow2,aio=threads

Ця команда запустить систему з 4 ядрами, 2048 RAM, активованим KVM, мережевою картою на мосту bridge0 та двома дисками: для системи та external для postgresql.

Образи можна конвертувати та запускати у Virtualbox:

qemu-img convert -f qcow2  qemu.qcow2 -O vdi qcow2.vdi
qemu-img convert -f qcow2  external.qcow2 -O vdi external.vdi

Після чого імпортувати їх у virtualbox і підключити по sata.

Висновок

У процесі мені стало цікаво зробити готовий до роботи продукт - з не дуже гарним інтерфейсом (не люблю їх писати), але працюючий і простий у налаштуванні.

Остання спроба встановити zabbix-appliance у KVM показала правильність цього кроку (після завершення інсталяції система не стартує). Можливо я щось роблю не так 😉

Матеріали

https://buildroot.org/

Джерело: habr.com