Buildroot: Tworzenie wieloplatformowego oprogramowania sprzętowego z zabbix-server

Historia zadania

Małe firmy z jednej strony potrzebują jakościowego monitorowania swojej infrastruktury (szczególnie w świetle powszechnej wirtualizacji), z drugiej strony, mają trudności finansowe z zakupem nowego sprzętu. Często napotykają też problemy z serwerami/sprzętem: zazwyczaj obok stanowisk pracy znajduje się 1-3 wieżowych serwerów lub w małych wnękach/schowkach.

Łatwiej jest użyć gotowego rozwiązania (dystrybucji), którą wystarczy załadować na kartę microSD i włożyć do popularnego komputera jednopłytowego (beaglebone, rodziny raspberry pi i orange pi, asus tinker board). Ponadto, taki sprzęt jest niedrogi i może być zainstalowany w dowolnym miejscu.

Sformułowanie zadania

Projekt rozwijał się głównie jako pewnego rodzaju praca laboratoryjna z możliwością zastosowania wyników.

Do monitorowania wybrano zabbix, ponieważ jest to potężny, darmowy i dobrze udokumentowany system.

Pojawił się pilny problem z platformą sprzętową. Postawienie oddzielnej maszyny do monitorowania również nie jest najlepszym rozwiązaniem - albo drogo jest kupować nowy sprzęt, albo trzeba szukać starego, a w małych firmach często występują problemy z serwerami/sprzętem.

Użycie systemu budowy buildroot pozwala na tworzenie specjalizowanych rozwiązań, które mogą być eksploatowane przez personel z minimalną wiedzą o systemach Linux. Ten system jest przyjazny dla nowicjuszy, ale oferuje szerokie możliwości dostosowania w rękach doświadczonego programisty. Idealnie nadaje się do rozwiązania problemu taniego, ale pełnofunkcjonalnego monitorowania infrastruktury IT, minimalnie wymagającego przygotowania personelu.

Kroki rozwiązania

Postanowiono początkowo stworzyć oprogramowanie dla x86_64 do uruchomienia w qemu, ponieważ jest to wygodne i szybkie rozwiązanie do debugowania. Następnie portować na komputer jednopłytowy arm (spodobała mi się asus tinker board).

Do budowy wybrano buildroot. Początkowo brakowało w nim pakietu zabbix, więc trzeba było go portować. Były problemy z lokalizacją rosyjską, które rozwiązano nałożeniem odpowiednich poprawek (uwaga: w nowszych wersjach buildroot te poprawki są już niepotrzebne).

Portowanie samego pakietu zabbix zostanie opisane w osobnym artykule.

Ponieważ wszystko musi działać jak oprogramowanie układowe (niezmienny obraz systemu + pliki konfiguracyjne/bazy danych, które można odzyskać), konieczne było napisanie własnych celów systemd, usług i timerów (target, service, timer).

Podjęto decyzję o podzieleniu nośnika na 2 partycje — jedna z plikami systemowymi, a druga z zmiennymi konfiguracjami i plikami bazy danych Zabbix.

Nieco trudniejsze okazało się rozwiązanie zadań związanych z bazą danych. Umieszczanie jej bezpośrednio na nośniku nie było pożądane. Jednocześnie rozmiar bazy może osiągnąć rozmiar przekraczający możliwości ramdysku. Dlatego wybrano kompromisowe rozwiązanie: baza danych jest umieszczona na drugiej partycji karty SD (nowoczesne karty SLC mają do 30 000 cykli zapisu), ale istnieje opcja umożliwiająca użycie zewnętrznego nośnika (np. USB-HDD).

Monitorowanie temperatury zrealizowano za pomocą urządzenia RODOS-5. Oczywiście, można użyć Dallas 1820 bezpośrednio, ale szybciej i łatwiej było podłączyć USB.

Jako bootloader dla x86_64 wybrano grub2. Konieczne było napisanie minimalnej konfiguracji do uruchomienia.

Po debugowaniu na qemu wykonano portowanie na ASUS Tinker Board. W strukturze mojego overlay’a od początku zakładano kompatybilność międzyplatformową — wydzielenie specyficznych dla każdej płyty konfiguracji (defconfig płyty, bootloader, generacja obrazu z partycją systemu) i maksymalna jednolitość w dostosowywaniu systemu plików/tworzeniu obrazu z danymi. Z uwagi na takie przygotowanie portowanie przebiegło szybko.

Zaleca się uważne przeczytanie wprowadzających artykułów:
https://habr.com/ru/post/448638/
https://habr.com/ru/post/449348/

Jak zbudować

Projekt jest przechowywany na GitHubie
Po sklonowaniu repozytorium uzyskuje się następującą strukturę plików:

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

buildroot-2019.05.tar.gz — archiwum czystego buildroot
overlay — mój katalog z external-tree. To w nim przechowywane jest wszystko, co potrzebne do zbudowania oprogramowania układowego za pomocą buildroot
README.md — opis projektu oraz instrukcja w języku angielskim.
run_me.sh — skrypt, który przygotowuje system budowy. Rozpakowuje buildroot z archiwum, dołącza do niego overlay (za pomocą mechanizmu external-tree) i pozwala wybrać docelową płytę do budowy.

[0] my_asus_tinker_defconfig
[1] my_beaglebone_defconfig
[2] x86_64_defconfig
Wybierz defconfig, naciśnij A, aby przerwać. Domyślne [0]

Po tym wystarczy przejść do katalogu buildroot-2019.05 i wykonać polecenie make.
Po zakończeniu budowy wszystkie wyniki budowy będą znajdować się w katalogu 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

Potrzebne pliki:

• sdcard.img — obraz nośnika do zapisania na karcie sd (przez dd lub rufus na winde).
• qemu.qcow2 — obraz nośnika do uruchamiania w qemu.
• external.qcow2 — obraz zewnętrznego nośnika dla bazy danych
• monitor-0.9-beta.tar.gz — archiwum do aktualizacji przez interfejs webowy

Generowanie instrukcji

Nie ma sensu pisać tej samej instrukcji wiele razy. Najrozsądniej jest napisać ją raz w markdown, a następnie przekonwertować na PDF do pobrania i HTML do interfejsu webowego. Jest to możliwe dzięki pakietowi pandoc.

Wszystkie te pliki muszą być generowane przed zbudowaniem obrazu systemu, post-build skrypty już są bez użyteczne. Dlatego generacja odbywa się w formie paczki manuals. Można je zobaczyć w overlay/package/manuals.

Plik manuals.mk (który wykonuje całą pracę)

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

Świat Linuxa aktywnie przechodzi na systemd, więc musiałem to zrobić także ja.
Z przyjemnych nowości — obecność timerów. W ogóle na ich temat (i nie tylko) pisana jest osobna artykuł, ale krótko opowiem.

Są działania, które należy wykonywać okresowo. Potrzebowałem uruchomić logrotate do czyszczenia logów lighttpd i php-fpm. Zwykle pisałbym to w cron, ale postanowiłem użyć monotonnego timera systemd. W ten sposób, logrotate uruchamia się przez stały interwał czasowy.

Oczywiście istnieje możliwość tworzenia timerów, które uruchamiają się w określonych datach, ale to nie było mi potrzebne.
Przykład timera:

• Plik timera

  
  [Unit]
  Description=RODOS temp daemon timer

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min

[Install]
WantedBy=timers.target

- Plik serwisu wywoływanego przez timer:
```bash
[Unit]
Description=RODOS temp daemon

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

Obsługiwane płyty

Asus tinker board — główna płyta, na której wszystko powinno działać. Wybrana jako niedroga i mocna.

Beaglebone black — pierwsza płyta, na której testowano działanie (w czasie poszukiwania mocniejszej płyty).

Qemu x86_64 — używana do rozwoju i debugowania.

Jak to działa

Podczas uruchamiania następuje dwuetapowe przywracanie ustawień:

• uruchomienie skryptu settings_restore (przez serwis). Przywraca on główne ustawienia systemu — strefę czasową, lokalizację, ustawienia sieci itp.
• Uruchomienie skryptu prepare (przez serwis) — tutaj przygotowywany jest zabbix, baza danych, a adres IP wyświetlany jest w konsoli.

Podczas pierwszego uruchomienia określany jest rozmiar drugiej partycji karty sd. W przypadku, gdy nadal istnieje niewykorzystane miejsce — nośnik jest ponownie partycjonowany, a partycja na dane zajmuje całe wolne miejsce. Zrobiono to w celu zmniejszenia rozmiaru obrazu instalacyjnego (sdcard.img). Ponadto w tym momencie tworzony jest roboczy katalog postgresql. Dlatego pierwsze uruchomienie z nowym nośnikiem będzie dłuższe niż kolejne.

Podczas podłączania zewnętrznego dysku, w momencie uruchomienia wyszukiwany jest wolny dysk i formatowany jest w ext4 z etykietą external.

Uwaga! Podczas podłączania zewnętrznego dysku (a także jego odłączania lub wymiany), konieczne jest wykonanie kopii zapasowej i przywrócenie ustawień!

Do monitorowania temperatury używane jest urządzenie RODOS 5. Producent udostępnia źródła swojej aplikacji do pracy z urządzeniem. Po uruchomieniu systemu startuje licznik rodos, który uruchamia tę aplikację co minutę. Bieżąca temperatura zapisywana jest w pliku /tmp/rodos_current_temp, po czym zabbix może monitorować ten plik jako czujnik.

Nośnik do przechowywania konfiguracji montowany jest w katalogu /data.

Podczas uruchamiania systemu i przygotowywania go do pracy w konsoli pojawia się komunikat:

System uruchamia się, proszę czekać

Po zakończeniu prac przygotowawczych, zmieni się on na wyświetlenie adresu IP:

aktualny IP 192.168.1.32
Gotowy do pracy

Konfiguracja zabbix do monitorowania temperatury

Aby monitorować temperaturę, wystarczy wykonać 2 kroki:

• podłączyć urządzenie RODOS do portu usb
• utworzyć element danych w zabbix

Otwieramy interfejs webowy zabbix:

• Otwieramy sekcję Konfiguracja → Hosty
• Klikamy na Elementy w wierszu naszego serwera zabbix
• Klikamy na Utwórz element

Wprowadzamy następujące dane:

• nazwa — według uznania (na przykład serverRoomTemp)
• Typ — agent zabbix
• Klucz — rodos
• Typ — liczbowy
• Jednostki — °C
• Okres przechowywania historii — okres przechowywania historii. Zostawiłem 10 dni
• Okres przechowywania trendów — okres przechowywania dynamiki zmian. Zostawiłem 30 dni
• Nowa aplikacja — server Room Temp

I klikamy przycisk DODAJ.

Zarządzanie ustawieniami przez interfejs webowy

Interfejs webowy jest napisany w php. Istnieją podstawowe funkcje:

• podgląd stanu urządzenia
• zmiana ustawień sieciowych
  
• zmiana hasła użytkownika
• wybór strefy czasowej
• tworzenie kopii zapasowej / przywracanie / resetowanie do ustawień fabrycznych
• możliwość podłączenia zewnętrznego dysku
• Aktualizacja systemu
  

Dostęp do interfejsu webowego jest zabezpieczony hasłem. Strona startowa — przewodnik.

Adres interfejsu zabbix: ${ip/dns}/zabbix
Adres interfejsu zarządzania: ${ip/dns}/manage

Uruchamianie w 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

To polecenie uruchomi system z 4 rdzeniami, 2048 RAM, aktywowanym KVM, kartą sieciową na moście bridge0 oraz dwoma dyskami: dla systemu i zewnętrznym dla postgresql.

Obrazy można konwertować i uruchamiać w Virtualbox:

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

Następnie importować je do virtualbox i podłączyć po sata.

Podsumowanie

W trakcie pracy zainteresowało mnie stworzenie gotowego do użycia produktu — z niezbyt ładnym interfejsem (nie lubię ich pisać), ale działającego i prostego w konfiguracji.

Ostatnia próba zainstalowania zabbix-appliance w KVM pokazała słuszność tego kroku (po zakończeniu instalacji system nie uruchamia się). Może robię coś źle 😉

Materiały

https://buildroot.org/

Źródło: habr.com