Buildroot: creació de microprogramari multiplataforma amb zabbix-server

Buildroot: creació de microprogramari multiplataforma amb zabbix-server

Historial de problemes

Les petites empreses, d'una banda, necessiten un seguiment d'alta qualitat de la seva infraestructura (sobretot a la vista de la virtualització generalitzada), d'altra banda, els costa econòmicament adquirir nous equips. Els problemes de servidor/maquinari també són habituals: sovint hi ha 1-3 servidors de torre al costat de les estacions de treball dels usuaris o en un petit nínxol/armari.

És més fàcil utilitzar un conjunt (distribució) ja fet, que només cal carregar a una targeta microSD i inserir-lo en un ordinador comú d'una sola placa (famílies beaglebone, raspberry pi i orange pi, asus tinker board). A més, aquest equip és econòmic i es pot instal·lar a qualsevol lloc.

Declaració de problemes

En molts sentits, el projecte es va desenvolupar com una mena de treball de laboratori amb la possibilitat d'aplicar els resultats.

Zabbix va ser escollit com a sistema de monitorització perquè és un sistema potent, gratuït i ben documentat.

El problema amb la plataforma de maquinari s'ha agravat. Posar una màquina separada sota control tampoc és una solució molt bona: o és car comprar equip nou o buscar equip antic + a les petites empreses hi ha problemes freqüents amb el servidor/ maquinari.

L'ús del sistema de compilació buildroot us permet crear solucions especialitzades que poden ser operades per personal amb un coneixement mínim dels sistemes operatius Linux. Aquest sistema és amigable per als principiants, però al mateix temps ofereix àmplies oportunitats de personalització en mans d'un desenvolupador experimentat. És perfecte per resoldre el problema d'un seguiment econòmic, però totalment funcional, de la infraestructura informàtica, amb uns requisits mínims per a la formació del personal que l'explota.

Passos de solució

Es va decidir inicialment crear firmware perquè x86_64 s'executi a qemu, ja que aquesta és una solució còmoda i ràpida per a la depuració. A continuació, porteu-lo a un ordinador d'una sola placa de braç (em va agradar l'asus tinker board).

buildroot es va seleccionar com a sistema de compilació. Inicialment, no té el paquet zabbix, per la qual cosa s'ha hagut de portar.Hi va haver problemes amb la configuració regional russa, que es van resoldre aplicant els pedaços adequats (nota: en les versions més noves de buildroot, aquests pedaços ja no són necessaris).

La portabilitat del paquet zabbix es descriurà en un article separat.

Com que tot hauria de funcionar com a microprogramari (imatge del sistema no canviable + fitxers de configuració/base de dades recuperables), era necessari escriure els vostres propis objectius, serveis i temporitzadors del sistema (destí, servei, temporitzador).

Es va decidir dividir els mitjans en 2 seccions: una secció amb fitxers del sistema i una secció amb configuracions canviables i fitxers de base de dades zabbix.

La resolució de problemes relacionats amb la base de dades va resultar una mica més difícil. No volia posar-ho directament als mitjans. Al mateix temps, la mida de la base de dades pot assolir una mida que superi la mida d'un possible disc ram. Per tant, es va triar una solució de compromís: la base de dades es troba a la segona partició de la targeta SD (les targetes SLC modernes tenen fins a 30 cicles d'escriptura), però hi ha una configuració que permet l'ús de suports externs (per exemple, usb- hdd).

El control de la temperatura es va implementar mitjançant el dispositiu RODOS-5. Per descomptat, podeu utilitzar el Dallas 1820 directament, però era més ràpid i més fàcil connectar un USB.

grub86 es va seleccionar com a carregador d'arrencada per a x64_2. Calia escriure una configuració mínima per llançar-la.

Després de depurar qemu, es va portar a la placa asus tinker. L'estructura de la meva superposició inicialment estava pensada per ser multiplataforma: assignar configuracions específiques per a cada tauler (defconfig de la placa, carregador d'arrencada, generació d'una imatge amb una partició del sistema) i la màxima uniformitat a l'hora de personalitzar el sistema de fitxers/crear una imatge amb dades. A causa d'aquesta preparació, la portabilitat va anar ràpidament.

És molt recomanable llegir els articles introductoris:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Com muntar

El projecte s'emmagatzema a github
Després de clonar el repositori, s'obté l'estructura de fitxers següent:

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

buildroot-2019.05.tar.gz - netejar l'arxiu buildroot
overlay és el meu directori amb external-tree. Aquí és on s'emmagatzema tot el que necessiteu per crear el microprogramari mitjançant buildroot.
README.md - descripció del projecte i manual en anglès.
run_me.sh és un script que prepara el sistema de compilació. Amplia l'arrel de construcció des de l'arxiu, s'hi adjunta una superposició (mitjançant el mecanisme d'arbre extern) i us permet seleccionar el tauler de destinació per al muntatge.

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

Després d'això, només cal que aneu al directori buildroot-2019.05 i executeu l'ordre make.
Un cop finalitzada la compilació, tots els resultats de la compilació estaran al directori de sortida/imatges:

[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

Fitxers obligatoris:

  • sdcard.img - imatge multimèdia per gravar en una targeta SD (mitjançant dd o rufus sota wibdows).
  • qemu.qcow2: imatge multimèdia per executar-se a qemu.
  • external.qcow2: imatge de suport extern per a la base de dades
  • monitor-0.9-beta.tar.gz - arxiu per actualitzar mitjançant la interfície web

Generació de guies

No val la pena escriure les mateixes instruccions diverses vegades. I el més lògic és escriure'l una vegada a la reducció, i després convertir-lo a PDF per descarregar-lo i html per a la interfície web. Això és possible gràcies al paquet pandoc.

Al mateix temps, tots aquests fitxers s'han de generar abans de muntar la imatge del sistema; aquests scripts posteriors a la creació ja són inútils. Per tant, la generació es fa en forma de paquet de manuals. Podeu consultar la superposició/paquet/manuals.

El fitxer manuals.mk (que fa tot el treball)

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

El món Linux s'està movent activament a systemd, i jo també ho havia de fer.
Una de les novetats agradables és la presència de temporitzadors. En general, s'està escrivint un article a part sobre ells (i no només sobre ells), però us ho explicaré breument.

Hi ha accions que s'han de realitzar periòdicament. Necessitava executar logrotate per esborrar els registres lighttpd i php-fpm. L'habitual seria escriure les ordres a cron, però vaig decidir utilitzar el temporitzador monòton systemd. Per tant, logrotate s'executa en un interval de temps estricte.

Per descomptat, és possible crear temporitzadors que s'encenen en determinades dates, però no ho necessitava.
Exemple de temporitzador:

  • Fitxer del temporitzador
    
    [Unit]
    Description=RODOS temp daemon timer

[Temporitzador] OnBootSec=1 min
OnUnitActiveSec=1min

[Instal·la] WantedBy=timers.target

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

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

Taulers suportats

Asus tinker board és la placa principal en la qual hauria de funcionar tot. Seleccionat com a barat i molt potent.

Beaglebone negre és el primer tauler en què es va provar el funcionament (durant la selecció d'un tauler més potent).

Qemu x86_64: s'utilitza per al desenvolupament de depuració.

Com funciona?

A l'inici, es produeix una restauració de la configuració en dues etapes:

  • executant l'script settings_restore (mitjançant el servei). Restaura la configuració bàsica del sistema: zona horària, configuració regional, configuració de xarxa, etc.
  • executant l'script de preparació (mitjançant el servei): aquí es preparen zabbix i la base de dades, la IP s'envia a la consola.

Quan l'inicieu per primera vegada, es determina la mida de la segona partició de la targeta SD. Si encara hi ha espai sense assignar, el suport es reparticiona i la secció de dades ocupa tot l'espai lliure. Això es fa per tal de reduir la mida de la imatge d'instal·lació (sdcard.img). A més, en aquest punt es crea el directori de treball postgresql. És per això que el primer llançament amb un nou transportista serà més llarg que els posteriors.

Quan es connecta una unitat externa, en el moment de l'inici cerca una unitat lliure i la formata a ext4 amb l'etiqueta externa.

Atenció! Quan connecteu una unitat externa (a més de desconnectar-la o substituir-la), heu de fer una còpia de seguretat i restaurar la configuració.

Per controlar la temperatura s'utilitza el dispositiu RODOS 5. El fabricant proporciona el codi font de la seva utilitat per treballar amb el dispositiu. Quan el sistema està encès, s'inicia el temporitzador rodos, que executa aquesta utilitat una vegada per minut. La temperatura actual s'escriu al fitxer /tmp/rodos_current_temp, després del qual zabbix pot controlar aquest fitxer com a sensor.

El suport d'emmagatzematge de configuració està muntat al directori /data.

En iniciar el sistema i preparar-lo per al funcionament, apareix el missatge següent a la consola:

System starting, please wait

Després de completar el treball preparatori, canviarà a mostrar l'adreça IP:

current ip 192.168.1.32
Ready to work

Configuració de zabbix per al control de la temperatura

Per controlar la temperatura, només cal fer 2 passos:

  • connecteu el dispositiu RODOS al port USB
  • crear un element de dades a zabbix

Obriu la interfície web de zabbix:

  • Obriu la secció Configuració → Amfitrions
  • Feu clic a Elements a la línia del nostre servidor zabbix
  • Feu clic a Crea un element

Buildroot: creació de microprogramari multiplataforma amb zabbix-server

Introduïu les dades següents:

  • nom: segons el vostre criteri (per exemple, serverRoomTemp )
  • Tipus: agent zabbix
  • Clau - Rodos
  • Tipus numèric
  • Unitats - C
  • Període d'emmagatzematge de l'historial — període d'emmagatzematge de l'historial. queden 10 dies
  • Període d'emmagatzematge de tendències: període d'emmagatzematge de la dinàmica dels canvis. Queden 30 dies
  • Nova aplicació - servidor Temp

I premeu el botó AFEGIR.
Buildroot: creació de microprogramari multiplataforma amb zabbix-server

Gestioneu la configuració mitjançant la interfície web

La interfície web està escrita en PHP. Hi ha funcions principals:

  • veure l'estat del dispositiu
  • canviant la configuració de la xarxa
    Buildroot: creació de microprogramari multiplataforma amb zabbix-server
  • canvi de contrasenya d'usuari
  • selecció de zona horària
  • còpia de seguretat/restauració/restabliment de fàbrica
  • possibilitat de connectar una unitat externa
  • Actualització del sistema
    Buildroot: creació de microprogramari multiplataforma amb zabbix-server

L'inici de sessió a la interfície web està protegit amb contrasenya. Pàgina d'inici - manual.

Adreça de la interfície Zabbix: ${ip/dns}/zabbix
Adreça de la interfície de gestió: ${ip/dns}/manage
Buildroot: creació de microprogramari multiplataforma amb zabbix-server

Córrer en 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 -unitat fitxer=sortida/imatges/qemu.qcow2,format=qcow2,aio=fils -dispositiu virtio-scsi-pci,id=scsi0 -unitat fitxer=sortida/imatges/external.qcow2,format=qcow2,aio=fils

Aquesta ordre iniciarà un sistema amb 4 nuclis, 2048 RAM, KVM habilitat, una targeta de xarxa al bridge0 i dos discs: un per al sistema i un extern per a postgresql.

Les imatges es poden convertir i executar a Virtualbox:

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

A continuació, importeu-los a virtualbox i connecteu-vos mitjançant sata.

Conclusió

En el procés, em vaig interessar per fer un producte llest per utilitzar, amb una interfície poc bonica (no m'agrada escriure'ls), però que funcioni i sigui fàcil de configurar.

L'últim intent d'instal·lar zabbix-appliance a KVM va mostrar que aquest pas era correcte (un cop finalitzada la instal·lació, el sistema no s'inicia). Potser estic fent alguna cosa malament 😉

Materials

https://buildroot.org/

Font: www.habr.com

Afegeix comentari