Buildroot: Crearea firmware-ului multiplatformă cu zabbix-server

Istoria sarcinii

Firmele mici, pe de o parte, au nevoie de un monitorizare de calitate a infrastructurii lor (mai ales în contextul virtualizării omniprezente), iar pe de altă parte, este dificil din punct de vedere financiar să achiziționeze echipamente noi. De asemenea, întâmpină frecvent probleme cu serverele / hardware-ul: deseori sunt utilizate 1-3 servere tower amplasate lângă stațiile de lucru ale utilizatorilor sau într-un colț mic / dulap.

Este mai simplu să folosești o distribuție gata pregătită, pe care să o copiezi pe un card microSD și să o introduci într-un computer cu o singură placă popular (beaglebone, familiile raspberry pi și orange pi, asus tinker board). În plus, aceste echipamente sunt accesibile și pot fi instalate în orice loc.

Formularea problemei

În mare parte, proiectul s-a dezvoltat ca o lucrare de laborator, cu posibilitatea aplicării rezultatelor.

Pentru sistemul de monitorizare a fost ales zabbix, deoarece este un sistem puternic, gratuit și bine documentat.

Problema platformei hardware a devenit urgentă. A avea o mașină separată pentru monitorizare nu este o soluție foarte bună - fie este scump să achiziționezi echipamente noi, fie trebuie să cauți echipamente vechi + în firmele mici apar frecvent probleme cu serverele / hardware-ul.

Utilizarea sistemului de compilare buildroot permite crearea de soluții specializate, care pot fi utilizate de personal cu cunoștințe minime ale sistemului de operare Linux. Acest sistem este prietenos cu începătorii, dar oferă în același timp posibilități extinse de personalizare în mâinile unui dezvoltator experimentat. Este ideal pentru a rezolva sarcina de monitorizare IT complet funcțională și accesibilă, cu cerințe minime de pregătire pentru personalul care o operează.

Pașii soluției

S-a decis inițial să se creeze un firmware pentru x86_64 pentru a rula în qemu, deoarece aceasta este o soluție convenabilă și rapidă pentru depanare. După aceea, a fost portat pe un computer cu o singură placă arm (mi-a plăcut asus tinker board).

Pentru sistemul de compilare a fost ales buildroot. Inițial, acesta nu conținea pachetul zabbix, așa că a fost nevoie de portarea acestuia. Au fost probleme cu localizarea în limba rusă, care au fost rezolvate prin aplicarea de patch-uri corespunzătoare (mențiune: în versiunile mai noi ale buildroot, aceste patch-uri nu mai sunt necesare).

Portarea efectivă a pachetului zabbix va fi descrisă într-un articol separat.

Deoarece totul trebuie să funcționeze ca un firmware (imagine de sistem neschimbabilă + fișiere de configurare/restaurare a bazelor de date), a fost necesar să scriem propriile ținte, servicii și temporizatoare systemd (target, service, timer).

S-a decis împărțirea suportului în 2 partiții — o partiție pentru fișierele sistemului și o partiție pentru configurațiile și fișierele modificabile ale bazei de date zabbix.

Rezolvarea problemelor legate de baza de date s-a dovedit a fi puțin mai complicată. Nu am dorit să o plasăm direct pe suport. În același timp, dimensiunea bazei poate ajunge la o mărime care depășește dimensiunea posibilului ramdisk. Prin urmare, s-a ales o soluție de compromis: baza de date este plasată pe a doua partiție a cardului sd (cartelele SLC moderne au până la 30.000 de cicluri de scriere), dar există o setare care permite utilizarea unui suport extern (de exemplu, usb-hdd).

Monitorizarea temperaturii a fost realizată prin intermediul dispozitivului RODOS-5. Desigur, se poate folosi dallas 1820 direct, dar a fost mai rapid și mai simplu să-l conectăm prin USB.

Ca bootloader pentru x86_64, a fost ales grub2. A fost necesar să scriem o configurație minimă pentru pornire.

După depanarea pe qemu, a fost realizată portarea pe asus tinker board. În structura overlay-ului meu, a fost gândită inițial portabilitatea — separarea configurațiilor specifice fiecărei plăci (defconfig-ul plăcii, bootloader, generarea imaginii cu partiția sistemului) și maximum de uniformitate în setarea fișierului sistemului/crearea imaginii cu date. Datorită acestei pregătiri, portarea s-a desfășurat rapid.

Se recomandă cu tărie citirea articolelor introductive:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Cum să construiești

Proiectul este stocat pe github
După clonarea repository-ului, obținem următoarea structură a fișierelor:

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

buildroot-2019.05.tar.gz — arhiva buildroot-ului curat
overlay — directorul meu cu external-tree. Aici este stocat tot ce este necesar pentru a construi firmware-ul folosind buildroot
README.md — descrierea proiectului și manualul în engleză.
run_me.sh — scriptul care pregătește sistemul de construcție. Extrage buildroot-ul din arhivă, atașează overlay-ul (prin mecanismul external-tree) și permite alegerea plăcii țintă pentru construcție.

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Selectați defconfig, apăsați A pentru a anula. Default [0]

După aceasta, este suficient să accesați directorul buildroot-2019.05 și să executați comanda make.
După finalizarea compilării, toate rezultatele compilării vor fi în catalogul 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

Fișiere necesare:

• sdcard.img — imaginea suportului pentru scriere pe cardul SD (prin dd sau rufus sub Windows).
• qemu.qcow2 — imaginea suportului pentru rulare în qemu.
• external.qcow2 — imaginea unui suport extern pentru baza de date
• monitor-0.9-beta.tar.gz — arhiva pentru actualizare prin interfața web

Generarea manualelor

Nu este necesar să rescrii aceleași instrucțiuni de mai multe ori. Cel mai logic este să scrii o singură dată în markdown, după care să convertești în PDF pentru descărcare și HTML pentru interfața web. Acest lucru este posibil datorită pachetului pandoc.

În plus, toate aceste fișiere trebuie generate înainte ca imaginea sistemului să fie compilată, iar scripturile post-build devin inutile. Prin urmare, generarea a fost efectuată sub forma unui pachet manuals. Poate fi vizualizat în overlay/package/manuals.

Fișierul manuals.mk (care execută toată munca)

################################################################################
#
# 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

Lumea Linux trece activ la systemd, a trebuit să fac și eu acest lucru.
Printre noutăți plăcute se numără existența timerelor. De fapt, despre acestea (și despre altele) se scrie un articol separat, dar voi explica pe scurt.

Există acțiuni care trebuie efectuate periodic. A trebuit să pornesc logrotate pentru curățarea jurnalelor lighttpd și php-fpm. Cel mai familiar mod ar fi fost să scriu comenzile în cron, dar am decis să folosesc un timer monotonic systemd. Astfel, logrotate se pornește la un interval de timp strict.

Desigur, există posibilitatea creării timerelor care se declanșează în date specificate, dar acest lucru nu mi-a fost necesar.
Exemplu de timer:

• Fișierul timerului

  
  [Unit]
  Description=RODOS temp daemon timer

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- Fișierul serviciului invocat de timer:
```bash
[Unit]
Description=RODOS temp daemon

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

Plăci acceptate

Asus tinker board — placa principală pe care totul ar trebui să funcționeze. A fost aleasă ca fiind ieftină și foarte puternică.

Beaglebone black — prima placă pe care a fost testată funcționarea (în perioada alegerii unei plăci mai puternice).

Qemu x86_64 — utilizată pentru dezvoltare și depanare.

Cum funcționează

La pornire are loc o restaurare în două etape a setărilor:

• lansarea scriptului settings_restore (printr-un serviciu). Acesta restaurează setările principale ale sistemului — fusul orar, localitatea, setările rețelei etc.
• rularea scriptului prepare (prin serviciu) — aici se pregătește zabbix, baza de date, iar IP-ul este afișat în consolă.

La prima rulare, se determină dimensiunea celei de-a doua partiții a cardului SD. În cazul în care mai există spațiu nealocat, suportul este reorganizat, iar partiția pentru date ocupă tot spațiul liber. Aceasta se face pentru a reduce dimensiunea imaginii de instalare (sdcard.img). De asemenea, în acest moment se creează un director de lucru pentru postgresql. Din acest motiv, prima rulare cu un suport nou va dura mai mult decât cele ulterioare.

Când se conectează un disc extern, la pornire se caută un disc liber și se formatează în ext4 cu eticheta external.

Atenție! La conectarea (dar și deconectarea sau înlocuirea) unui disc extern, este necesar să se facă un backup și să se restabilească setările!

Pentru monitorizarea temperaturii se folosește dispozitivul RODOS 5. Producătorul oferă sursele utilitarului său pentru a lucra cu dispozitivul. La pornirea sistemului, se pornește cronometrul rodos, care rulează acest utilitar o dată pe minut. temperatura curentă este înregistrată în fișierul /tmp/rodos_current_temp, după care zabbix poate monitoriza acest fișier ca un senzor.

Supportul pentru stocarea configurației este montat în directorul /data.

La pornirea sistemului și pregătirea acestuia pentru lucru, în consolă apare mesajul:

Sistemul pornește, vă rugăm să așteptați

După finalizarea lucrărilor pregătitoare, acesta se va schimba în afișarea adresei IP:

ip curent 192.168.1.32
Gata de lucru

Configurarea zabbix pentru monitorizarea temperaturii

Pentru monitorizarea temperaturii sunt suficiente 2 pași:

• conectează dispozitivul RODOS la portul usb
• creează un element de date în zabbix

Deschidem interfața web zabbix:

• Deschidem secțiunea Configurare → Hosts
• Clic pe Elemente în linia serverului nostru zabbix
• Clic pe Creare element

Introducem următoarele date:

• nume — la alegerea dumneavoastră (de exemplu, serverRoomTemp)
• Tip — agent zabbix
• Cheie — rodos
• Tip — numeric
• Unități — C
• Perioada de stocare a istoricului — perioadă de păstrare a istoriei. Am lăsat 10 zile
• Perioada de stocare a tendințelor — perioada de păstrare a dinamicii modificărilor. Am lăsat 30 zile
• Noua aplicație — server Room Temp

Și clic pe butonul ADĂUGAȚI.

Gestionarea setărilor prin interfața web

Interfața web este scrisă în php. Există funcții principale:

• vizualizarea stării dispozitivului
• modificarea setărilor de rețea
  
• modificarea parolei utilizatorului
• selectarea fusului orar
• backup/restaurare/resetare la setările din fabrci
• posibilitatea de a conecta un disc extern
• Actualizarea sistemului
  

Accesul la interfața web este protejat prin parolă. Pagina de start — ghidul.

Adresa interfeței zabbix: ${ip/dns}/zabbix
Adresa interfeței de gestionare: ${ip/dns}/manage

Pornire în 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

Această comandă va porni sistemul cu 4 nuclee, 2048 RAM, KVM activat, card de rețea pe punte bridge0 și două discuri: pentru sistem și external pentru postgresql.

Imaginile pot fi convertite și rulate în Virtualbox:

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

Apoi, importă-le în Virtualbox și conectează-le prin SATA.

Concluzie

În acest proces, m-a interesat să fac un produs gata de lucru — cu o interfață nu foarte frumoasă (nu-mi plac), dar funcțională și ușor de configurat.

Ultima încercare de a instalare zabbix-appliance în KVM a dovedit corectitudinea acestui pas (după finalizarea instalării, sistemul nu pornește). Poate fac ceva greșit 😉

Materiale

https://buildroot.org/

Sursa: habr.com