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).

За система за сборка беше избран buildroot. Първоначално липсваше пакет 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. В структурата на моя overlay първоначално беше заложена кросплатформеност — отделяне на специфични за всяка платка конфиги (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
Изберете defconfig, натиснете A за прекратяване. По подразбиране [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 под Windows).
• qemu.qcow2 — образ на носител за стартиране в qemu.
• external.qcow2 — образ на външно носител за база данни
• monitor-0.9-beta.tar.gz — архив за актуализация чрез уеб интерфейс

Генериране на ръководства

Не си струва да пишете едно и също ръководство няколко пъти. По-логично е да го напишете веднъж в markdown и след това да го конвертирате в PDF за сваляне и HTML за уеб интерфейса. Това е възможно благодарение на пакета pandoc.

Също така, всички тези файлове трябва да бъдат генерирани преди образът на системата да бъде съставен, следователно скриптовете за пост-компилация вече са безполезни. Затова, генерирането се извършва под формата на пакет 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.

При стартиране на системата и подготовка за работа в конзолата се появява съобщение:

Системата стартира, моля изчакайте

След приключване на подготвителните работи, то ще се смени с извеждането на IP адреса:

текущ ip 192.168.1.32
Готово за работа

Настройка на zabbix за мониторинг на температурата

За мониторинг на температурата е достатъчно да направите 2 стъпки:

• да свържете устройството RODOS към usb порта
• да създадете data item в zabbix

Отваряме уеб интерфейса на zabbix:

• Отваряме раздела Конфигурация → Хостове
• Натискаме на Items в реда на нашия zabbix сървър
• Натискаме на Създаване на артикул

Въвеждаме следните данни:

• име — по ваше усмотрение (например, serverRoomTemp)
• Тип — zabbix агент
• Ключ — rodos
• Тип — числови
• Единици — C
• Срок на съхранение на историята — срок хранещ историята. Оставил 10 дни
• Срок на съхранение на динамика на промените — оставил 30 дни
• Ново приложение — server Room Temp

И натискаме бутона ДОДАВАНЕ.

Управление на настройките чрез уеб интерфейса

Уеб интерфейсът е написан на 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 и два диска: за системата и външен за 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