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. У структуры майго оверлея першапачаткова закладвалася кросплатформанасць - вылучэнне спецыфічных для кожнай платы канфігаў (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 ні -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