Buildroot: creación de firmware multiplataforma con zabbix-server

Buildroot: creación de firmware multiplataforma con zabbix-server

Historial de problemas

As pequenas empresas, por unha banda, necesitan un seguimento de alta calidade da súa infraestrutura (especialmente á vista da virtualización xeneralizada), por outra banda, cústalles económicamente adquirir novos equipos. Os problemas de servidor/hardware tamén son comúns: moitas veces hai 1-3 servidores de torre xunto ás estacións de traballo dos usuarios ou nun pequeno nicho/armario.

É máis doado usar un conxunto (distribución) preparado, que só tes que cargar nunha tarxeta microSD e inserir nun ordenador común de placa única (familias beaglebone, raspberry pi e orange pi, asus tinker board). Ademais, estes equipos son baratos e pódense instalar en calquera lugar.

Declaración de problemas

En moitos sentidos, o proxecto desenvolveuse como unha especie de traballo de laboratorio coa posibilidade de aplicar os resultados.

Elixiuse Zabbix como sistema de vixilancia porque é un sistema potente, gratuíto e ben documentado.

O problema coa plataforma de hardware agudizouse. Poñer unha máquina separada baixo vixilancia tampouco é unha solución moi boa - ou é caro comprar equipos novos ou buscar equipos antigos + nas pequenas empresas hai problemas frecuentes co servidor/ hardware.

Usar o sistema de compilación buildroot permítelle crear solucións especializadas que poden ser operadas por persoal cun coñecemento mínimo dos sistemas operativos Linux. Este sistema é amigable para os principiantes, pero ao mesmo tempo ofrece amplas oportunidades de personalización en mans dun programador experimentado. É perfecto para resolver o problema da vixilancia económica, pero totalmente funcional, da infraestrutura informática, con requisitos mínimos para a formación do persoal que a opera.

Pasos da solución

Decidiuse inicialmente crear firmware para que x86_64 se executase en qemu, xa que esta é unha solución cómoda e rápida para a depuración. A continuación, lévao a un ordenador de placa única de brazo (gústame a placa asus tinker).

buildroot foi seleccionado como o sistema de compilación. Inicialmente carece do paquete zabbix, polo que tivo que ser portado Houbo problemas coa configuración regional rusa, que se solucionaron aplicando os parches axeitados (nota: nas versións máis novas de buildroot, estes parches xa non son necesarios).

A portabilidade do propio paquete zabbix describirase nun artigo separado.

Dado que todo debería funcionar como firmware (imaxe do sistema non modificable + ficheiros de configuración/base de datos recuperables), era necesario escribir os seus propios obxectivos, servizos e temporizadores do sistema (destino, servizo, temporizador).

Decidiuse dividir os medios en 2 seccións: unha sección con ficheiros do sistema e outra con configuracións modificables e ficheiros de base de datos zabbix.

Resolver problemas relacionados coa base de datos resultou un pouco máis difícil. Non quería colocalo directamente nos medios. Ao mesmo tempo, o tamaño da base de datos pode alcanzar un tamaño que supera o tamaño dun posible disco ram. Por iso, optouse por unha solución de compromiso: a base de datos está situada na segunda partición da tarxeta SD (as modernas tarxetas SLC teñen ata 30 ciclos de escritura), pero hai unha configuración que permite o uso de medios externos (por exemplo, usb- disco duro).

Implementouse a monitorización da temperatura a través do dispositivo RODOS-5. Por suposto, podes usar o Dallas 1820 directamente, pero era máis rápido e sinxelo conectar un USB.

Seleccionouse grub86 como cargador de arranque para x64_2. Era necesario escribir unha configuración mínima para lanzalo.

Despois da depuración en qemu, portouse á placa asus tinker. A estrutura da miña superposición inicialmente pretendía ser multiplataforma: asignar configuracións específicas para cada placa (defconfig da placa, cargador de arranque, xerar unha imaxe cunha partición do sistema) e a máxima uniformidade na personalización do sistema de ficheiros/creación dunha imaxe con datos. Debido a tal preparación, a portada foi rapidamente.

É moi recomendable ler os artigos introdutorios:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Como montar

O proxecto está almacenado en github
Despois de clonar o repositorio, obtense a seguinte estrutura de ficheiros:

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

buildroot-2019.05.tar.gz - limpar o arquivo buildroot
overlay é o meu directorio con external-tree. Aquí é onde se almacena todo o que precisa para construír o firmware usando buildroot.
README.md - descrición do proxecto e manual en inglés.
run_me.sh é un script que prepara o sistema de compilación. Amplía buildroot desde o arquivo, engádelle unha superposición (a través do mecanismo de árbore externa) e permítelle seleccionar a placa de destino para a montaxe

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

Despois diso, só tes que ir ao directorio buildroot-2019.05 e executar o comando make.
Unha vez completada a compilación, todos os resultados da compilación estarán no directorio saída/imaxes:

[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

Ficheiros necesarios:

  • sdcard.img - imaxe multimedia para gravar nunha tarxeta SD (a través de dd ou rufus baixo wibdows).
  • qemu.qcow2 - imaxe multimedia para executar en qemu.
  • external.qcow2: imaxe multimedia externa para a base de datos
  • monitor-0.9-beta.tar.gz - arquivo para actualizar a través da interface web

Xeración de Guías

Non paga a pena escribir as mesmas instrucións varias veces. E o máis lóxico é escribilo unha vez en markdown, e logo convertelo a PDF para descargalo e html para a interface web. Isto é posible grazas ao paquete pandoc.

Ao mesmo tempo, todos estes ficheiros deben xerarse antes de montar a imaxe do sistema; eses scripts posteriores á construción xa son inútiles. Polo tanto, a xeración realízase en forma de paquete de manuais. Podes ver a superposición/paquete/manuais.

O ficheiro manuals.mk (que fai todo o traballo)

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

O mundo de Linux está pasando activamente a systemd, e eu tamén tiven que facelo.
Unha das novidades agradables é a presenza de temporizadores. En xeral, estase escribindo un artigo separado sobre eles (e non só sobre eles), pero vouche contar brevemente.

Hai accións que deben realizarse periodicamente. Necesitaba executar logrotate para borrar os rexistros lighttpd e php-fpm. O habitual sería escribir os comandos en cron, pero decidín usar o temporizador monotónico systemd. Polo tanto, logrotate execútase nun intervalo de tempo estrito.

Por suposto, é posible crear temporizadores que se activen en determinadas datas, pero non necesitaba isto.
Exemplo de temporizador:

  • Ficheiro do temporizador
    
    [Unit]
    Description=RODOS temp daemon timer

[Timer] OnBootSec=1 min
OnUnitActiveSec=1 min

[Instalar] WantedBy=timers.target

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

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

Placas soportadas

Asus tinker board é a placa principal na que todo debería funcionar. Seleccionado como barato e moi potente.

Beaglebone black é o primeiro taboleiro no que se probou o funcionamento (durante a selección dun taboleiro máis potente).

Qemu x86_64 - usado para o desenvolvemento de depuración.

Como funciona

No inicio, prodúcese unha restauración da configuración en dúas etapas:

  • executando o script settings_restore (a través do servizo). Restaura a configuración básica do sistema: zona horaria, configuración local, configuración de rede, etc.
  • executando o script de preparación (a través do servizo): aquí prepáranse zabbix e a base de datos, a IP móstrase á consola.

Cando o inicias por primeira vez, determínase o tamaño da segunda partición da tarxeta SD. Se aínda hai espazo sen asignar, o soporte está reparticionado e a sección de datos ocupa todo o espazo libre. Isto faise co fin de reducir o tamaño da imaxe de instalación (sdcard.img). Ademais, o directorio de traballo postgresql créase neste momento. É por iso que o primeiro lanzamento cunha nova operadora será máis longo que os posteriores.

Ao conectar unha unidade externa, no momento do inicio busca unha unidade libre e formatea en ext4 coa etiqueta externa.

Atención! Ao conectar unha unidade externa (así como desconectala ou substituíla), cómpre facer unha copia de seguridade e restaurar a configuración.

Para a monitorización da temperatura úsase o dispositivo RODOS 5. O fabricante proporciona o código fonte da súa utilidade para traballar co dispositivo. Cando o sistema está acendido, iníciase o temporizador rodos, que executa esta utilidade unha vez por minuto. A temperatura actual escríbese no ficheiro /tmp/rodos_current_temp, despois de que zabbix pode supervisar este ficheiro como sensor.

O soporte de almacenamento de configuración está montado no directorio /data.

Ao iniciar o sistema e preparalo para o seu funcionamento, aparece a seguinte mensaxe na consola:

System starting, please wait

Despois de completar o traballo preparatorio, cambiará a mostrar o enderezo IP:

current ip 192.168.1.32
Ready to work

Configurando zabbix para a monitorización da temperatura

Para controlar a temperatura, só tes que seguir 2 pasos:

  • conecte o dispositivo RODOS ao porto USB
  • crear un elemento de datos en zabbix

Abra a interface web de zabbix:

  • Abra a sección Configuración → Hosts
  • Fai clic en Elementos na liña do noso servidor zabbix
  • Fai clic en Crear elemento

Buildroot: creación de firmware multiplataforma con zabbix-server

Introduza os seguintes datos:

  • nome: á súa discreción (por exemplo, serverRoomTemp )
  • Tipo - axente zabbix
  • Chave - Rodos
  • Tipo numérico
  • Unidades - C
  • Período de almacenamento do historial: período de almacenamento do historial. quedan 10 días
  • Período de almacenamento da tendencia: período de almacenamento para a dinámica dos cambios. Quedan 30 días
  • Nova aplicación: servidor Temp

E prema o botón ENGADIR.
Buildroot: creación de firmware multiplataforma con zabbix-server

Xestionar a configuración a través da interface web

A interface web está escrita en PHP. Hai funcións principais:

  • ver o estado do dispositivo
  • cambiar a configuración da rede
    Buildroot: creación de firmware multiplataforma con zabbix-server
  • cambiar o contrasinal do usuario
  • selección de zona horaria
  • copia de seguridade/restauración/restablecemento de fábrica
  • capacidade de conectar un disco externo
  • Actualización do sistema
    Buildroot: creación de firmware multiplataforma con zabbix-server

O inicio de sesión na interface web está protexido por contrasinal. Páxina de inicio - manual.

Enderezo da interface de Zabbix: ${ip/dns}/zabbix
Enderezo da interface de xestión: ${ip/dns}/manage
Buildroot: creación de firmware multiplataforma con zabbix-server

Correndo 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 -unidade ficheiro=saída/imaxes/qemu.qcow2,formato=qcow2,aio=threads -device virtio-scsi-pci,id=scsi0 -drive ficheiro=saída/imaxes/external.qcow2,format=qcow2,aio=threads

Este comando iniciará un sistema con 4 núcleos, 2048 RAM, KVM habilitado, unha tarxeta de rede en bridge0 e dous discos: un para o sistema e outro externo para postgresql.

As imaxes pódense converter e executar en Virtualbox:

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

Despois impórtaos a virtualbox e conéctate a través de sata.

Conclusión

No proceso, interesoume facer un produto listo para usar, cunha interface non moi bonita (non me gusta escribilas), pero que funcione e sexa fácil de configurar.

O último intento de instalar zabbix-appliance en KVM mostrou que este paso era correcto (despois de completar a instalación, o sistema non se inicia). Quizais estou facendo algo mal 😉

Obras

https://buildroot.org/

Fonte: www.habr.com

Engadir un comentario