Buildroot: Opprette plattformuavhengig fastvare med zabbix-server

Historikk for oppgaven

Små bedrifter, på den ene siden, trenger kvalitetsmonitorering av infrastrukturen sin (spesielt med tanke på den utbredte virtualiseringen), men på den andre siden er det økonomisk utfordrende for dem å kjøpe nytt utstyr. Det oppstår også ofte problemer med server- og maskinvare: oftest står det 1-3 tower-servere ved siden av brukerarbeidsplasser eller i et lite rom/sjakt.

Det er enklere å bruke en ferdig bygging (distribusjon) som kan lastes opp på et microSD-kort og settes inn i en vanlig enkeltkortdatamaskin (beaglebone, raspberry pi-familien og orange pi, asus tinker board). I tillegg er slikt utstyr rimelig og kan installeres hvor som helst.

Definering av oppgaven

Prosjektet har i stor grad utviklet seg som et laboratoriumsarbeid med mulighet for å anvende resultatene.

Zabbix ble valgt som overvåkingssystem fordi det er et kraftig, gratis og godt dokumentert system.

Spørsmålet om maskinvareplattformen ble akutt. Å bruke en egen maskin for overvåkning er heller ikke en god løsning — enten er det kostbart å kjøpe nytt utstyr, eller så må man lete etter gammelt + små firmaer har ofte problemer med server- og maskinvare.

Bruken av byggesystemet buildroot lar deg lage spesialiserte løsninger som kan brukes av personale med minimal kunnskap om Linux-operativsystemer. Dette systemet er vennlig mot nybegynnere, men gir samtidig omfattende muligheter for tilpasning i hendene på en erfaren utvikler. Det er perfekt for å løse oppgaven med kostnadseffektiv, men fullfunksjonell overvåkning av IT-infrastrukturen, som krever minimalt med opplæring for de som drifter det.

Løsningstrinn

Det ble besluttet å først lage fastvaren for x86_64 for kjøring i qemu, da dette er en praktisk og rask løsning for feilsøking. Deretter ble det portert til en enkeltdatamaskin med arm (jeg likte asus tinker board).

Buildroot ble valgt som byggesystem. I utgangspunktet manglet det zabbix-pakken, så den måtte porteres. Det var problemer med russisk lokal, som ble løst ved å påføre de relevante oppdateringene (merking: i nyere versjoner av buildroot er ikke disse oppdateringene nødvendige).

Portering av zabbix-pakken vil bli beskrevet i en egen artikkel.

Siden alt må fungere som fastvare (uendret systembilde + gjenopprettbare konfigurasjonsfiler/databasefiler), var det nødvendig å skrive egne systemd-mål, tjenester og timere (target, service, timer).

Det ble besluttet å dele lagringsmediet i 2 partisjoner — en partisjon for systemfiler og en partisjon for endringsbare konfigurasjoner og zabbix-databasefiler.

Det viste seg å være litt mer komplisert å løse oppgaver relatert til databasen. Det var lite ønskelig å plassere den direkte på lagringsmediet. Samtidig kan størrelsen på databasen bli større enn størrelsen på et mulig ramdisk. Derfor ble det valgt en kompromissløsning: databasen plasseres på den andre partisjonen til sd-kortet (moderne SLC-kort har opptil 30 000 skriveperioder), men det finnes en innstilling som lar deg bruke ekstern lagring (for eksempel usb-hdd).

Temperaturmonitorering ble realisert gjennom en enhet RODOS-5. Selvfølgelig kan man bruke dallas 1820 direkte, men det var raskere og enklere å bruke USB.

Som bootloader for x86_64 ble grub2 valgt. Det var nødvendig å skrive en minimal konfigurasjon for oppstart.

Etter feilsøking på qemu ble det utført portering til asus tinker board. I strukturen til overlayen min var det opprinnelig planlagt plattformuavhengighet — å skille spesifikke konfigurasjoner for hvert brett (defconfig for brettet, bootloader, generering av bilde med systempartisjon) og maksimalt enhetlighet i tilpassing av filsystemet/oppretting av bilde med data. På grunn av denne forberedelsen gikk porteringen raskt.

Det anbefales på det sterkeste å lese de innledende artiklene:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Hvordan samle

Prosjektet lagres på github
Etter kloning av depotet oppnås følgende filstruktur:

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

buildroot-2019.05.tar.gz — arkiv av ren buildroot
overlay — min katalog med external-tree. Det er her alt nødvendig lagres for å bygge fastvaren med buildroot
README.md — prosjektbeskrivelse og veiledning på engelsk.
run_me.sh — skript som forbereder byggesystemet. Den pakker ut buildroot fra arkivet, kobler det til overlay (gjennom external-tree-mekanismen) og lar deg velge målbrett for bygging.

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Velg defconfig, trykk A for å avbryte. Standard [0]

Etter dette er det bare å gå til katalogen buildroot-2019.05 og kjøre kommandoen make.
Etter at byggingen er fullført, vil alle byggeresultater være i katalogen 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

Nødvendige filer:

• sdcard.img — bilde av lagringsenheten for å skrive til sd-kortet (via dd eller rufus under windows).
• qemu.qcow2 — bilde av lagringsenheten for å kjøre i qemu.
• external.qcow2 — bilde av extern enhet for databasen.
• monitor-0.9-beta.tar.gz — arkiv for oppdatering via webgrensesnitt.

Generering av manualer

Det er ikke nødvendig å skrive den samme instruksjonen flere ganger. Det er logisk å skrive det én gang i markdown, og deretter konvertere det til PDF for nedlasting og html for webgrensesnittet. Dette er mulig takket være pandoc-pakken.

Samtidig må alle disse filene genereres før systembildet er bygget, da post-build skriptene allerede er ubrukelige. Derfor er genereringen utført i form av en pakke manualer. Dette kan sees i overlay/package/manuals.

Filen manuals.mk (som utfører alt arbeidet)

################################################################################
#
# 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-verdenen går aktivt over til systemd, så jeg måtte gjøre det samme.
Av de hyggelige nyhetene er det timer. En egen artikkel skrives om dem (og ikke bare om dem), men jeg skal kort fortelle.

Det er handlinger som må utføres regelmessig. Jeg måtte starte logrotate for å rense loggene til lighttpd og php-fpm. Den mest vanlige metoden ville vært å skrive kommandoene i cron, men jeg valgte å bruke den monotone systemd-timeren. Slik at logrotate kjøres med strenge tidsintervaller.

Selvfølgelig er det mulig å lage timere som utløses på spesifikke datoer, men jeg trengte ikke det.
Eksempel på timer:

• Timerfil

  
  [Unit]
  Description=RODOS temp daemon timer

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- Tjenestefilen som kalles av timeren:
```bash
[Unit]
Description=RODOS temp daemon

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

Støttede kort

Asus tinker board — hovedkortet som alt skal fungere på. Valgt som rimelig og ganske kraftig.

Beaglebone black — det første kortet hvor funksjonen ble testet (i perioden med å finne et mer kraftig kort).

Qemu x86_64 — brukes til utviklingsfeilsøking.

Slik fungerer det

Ved oppstart skjer det en to-trinns gjenoppretting av innstillinger:

• kjøring av skriptet settings_restore (via tjenesten). Det gjenoppretter de grunnleggende systeminnstillingene — tidssone, lokale innstillinger, nettverksinnstillinger osv.
• køyring av skriptet prepare (via tenesta) — her blir zabbix forberedt, databasen oppretta, og IP-adressa blir vist i konsollen.

Ved første oppstart skjer det en bestemmelse av størrelsen på den andre partisjonen av sd-kortet. Dersom det fortsatt er ubrukt plass — blir lagringsmediet ompartisjonert, og partisjonen for data tar all ledig plass. Dette er gjort for å redusere størrelsen på installasjonsbildet (sdcard.img). I tillegg blir det på dette tidspunktet opprettet en arbeidsmappe for postgresql. Derfor vil den første oppstarten med et nytt medium ta lengre tid enn påfølgende oppstarter.

Når en ekstern disk kobles til, søker systemet under oppstart etter en ledig disk og formaterer den til ext4 med etikett external.

Merk! Ved tilkobling av en ekstern disk (også ved frakobling eller utskifting) er det nødvendig å ta backup og gjenopprette innstillingene!

For temperaturmonitorering brukes enhet RODOS 5. Produsenten gir kildekoden til sitt verktøy for å arbeide med enheten. Når systemet startes, aktiveres en timer for rodos, som starter dette verktøyet hvert minutt. Den nåværende temperaturen blir skrevet til filen /tmp/rodos_current_temp, hvoretter zabbix kan overvåke denne filen som en sensor.

Lagringsmediet for konfigurasjonen monteres i katalogen /data.

Ved oppstart av systemet og forberedelse for drift vises følgende melding i konsollen:

Systemet starter, vennligst vent

Etter fullføring av forberedelsene, endres dette til visning av IP-adressen:

nåværende ip 192.168.1.32
Klar for arbeid

Konfigurasjon av zabbix for temperaturmonitorering

For temperaturmonitorering er det tilstrekkelig å gjøre 2 trinn:

• koble RODOS-enheten til usb-porten
• opprette dataelement i zabbix

Åpne webgrensesnittet til zabbix:

• Åpne seksjonen Konfigurasjon → Vertar
• Klikk på Elementer i linjen til vår zabbix-server
• Klikk på Opprett element

Fyll inn følgende opplysninger:

• navn — etter eget valg (for eksempel, serverRoomTemp)
• Type — zabbix-agent
• Nøkkel — rodos
• Type — numerisk
• Enheter — C
• Historikk lagringsperiode — periode for lagring av historikk. Jeg har satt 10 dager
• Trend lagringsperiode — periode for lagring av endringsdynamikk. Jeg har satt 30 dager
• Ny applikasjon — server Room Temp

Og klikk på knappen LEGG TIL.

Håndtering av innstillinger via webgrensesnittet

Webgrensesnittet er skrevet i php. Det har hovedfunksjoner:

• visning av enhetens tilstand
• endring av nettverksinnstillinger
  
• endring av brukerpålogging
• valgt tidssone
• backup/gjenoppretting/nullstilling til fabrikkinnstillinger
• mulighet for tilkobling av ekstern disk
• Systemoppdatering
  

Inngang til webgrensesnittet er passordbeskyttet. Hovedsiden er en veiledning.

Grensesnittadresse for zabbix: ${ip/dns}/zabbix
Administrasjonsgrensesnittadresse: ${ip/dns}/manage

Start i 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

Denne kommandoen vil starte systemet med 4 kjerner, 2048 RAM, aktivert KVM, nettverkskort på broen bridge0 og to disker: for systemet og ekstern for postgresql.

Images kan konverteres og kjøre i Virtualbox:

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

Deretter importere dem i virtualbox og koble dem til via sata.

Konklusjon

Underveis ble jeg interessert i å lage et ferdig produkt — med et ikke så pent grensesnitt (jeg liker ikke å skrive dem), men som fungerer og er enkelt å konfigurere.

Den siste forsøket på å installere zabbix-appliance i KVM viste riktigheten av dette steget (etter fullført installasjon starter ikke systemet). Kanskje gjør jeg noe galt 😉

Materialer

https://buildroot.org/

Kilde: habr.com