Cel slajdu: Przedstawienie paradygmatu konteneryzacji aplikacji monitoringu sieci, architektury silnika Docker oraz orkiestracji za pomocą Docker Compose.
Nowoczesne metody wdrażania infrastruktury monitoringu
Tradycyjna, manualna instalacja systemów NMS na poziomie systemu operacyjnego ustępuje miejsca konteneryzacji, gwarantującej powtarzalność, izolację usług oraz błyskawiczne aktualizacje.
Zakres modułu: Wdrożenie produkcyjnego stosu LibreNMS w środowisku Docker i Docker Compose na serwerze Linux Ubuntu 24.04 LTS
Dekompozycja na mikrousługi: Separacja bazy MariaDB, pamięci podręcznej Redis, bufora RRDcached, serwera WWW Nginx oraz dyspozytora zadań Dispatcher
Trwałość i bezpieczeństwo: Zarządzanie wolumenami trwałymi (volumes), bezpieczne zarządzanie sekretami (.env) oraz standardy CIS Docker Benchmark
Konteneryzacja NMS: Metoda wdrażania systemu monitorowania sieci, w której wszystkie komponenty pracują w izolowanych kontenerach współdzielących jądro systemu operacyjnego hosta.
W piątej części kursu skupiamy się na nowoczesnych praktykach DevOps i NetDevOps w inżynierii monitoringu sieci LAN/WAN. Tradycyjna instalacja pakietów w systemie Linux (Nginx, PHP, dziesiątki modułów, kompilatory MIB, MariaDB, Redis) bywa czasochłonna, podatna na błędy zależności bibliotek i trudna do zreplikowania w środowiskach testowych.
Technologia kontenerowa Docker rozwiązuje ten problem fundamentalnie. Dzięki ustandaryzowanym obrazom Open Container Initiative (OCI) kompletny stos LibreNMS uruchamia się w ciągu kilkudziesięciu sekund za pomocą pojedynczego polecenia powłoki `docker compose up -d`.
W ramach tego modułu przeanalizujemy szczegółowo architekturę kontenerów, zasady bezpiecznego montowania wolumenów trwałych, routing w sieciach wirtualnych Bridge oraz procedury automatycznych kopii zapasowych i bezprzestojowych aktualizacji.
Slajd 2/22
Spis treści prezentacji 5
Cel slajdu: Przedstawienie struktury zagadnień modułu piątego obejmującego wdrożenie stosu NMS w kontenerach Docker.
Układ materiału i plan wykładu
Materiał prowadzi od podstaw technologii kontenerowej, przez konfigurację wielousługowego pliku compose.yml, po zaawansowane procedury Disaster Recovery i automatyzację Ansible.
Blok 1: Fundamenty konteneryzacji i Docker: Wirtualizacja VM a kontenery, architektura Dockera, polecenia CLI i składnia pliku compose.yml
Blok 2: Architektura stosu LibreNMS w kontenerach: Konfiguracja MariaDB, Redis, RRDcached, zmienne .env, rozruch i diagnostyka kontenerów
Blok 3: Trwałość, skalowanie i usługi pomocnicze: Wolumeny dyskowe, procedury aktualizacji, skalowanie pollerów (Dispatcher), Syslog i Oxidized
Blok 4: Sieć, bezpieczeństwo i eksploatacja: Tryby sieciowe (bridge vs host), utwardzanie CIS, kopie zapasowe, Prometheus w Dockerze i dobre praktyki
Plan dydaktyczny modułu 5: Praktyczne opanowanie narzędzi konteneryzacji na potrzeby budowy wysoce dostępnego, skalowalnego i łatwego w utrzymaniu środowiska NMS.
Moduł ten stanowi bezpośrednią kontynuację wiedzy o systemach NMS zaprezentowanej w module 4. O ile wcześniej omawialiśmy funkcjonalności LibreNMS i The Dude z perspektywy architektury logicznej, o tyle teraz skupiamy się na technologii ich niezawodnego uruchamiania.
Współczesny inżynier sieciowy musi biegle posługiwać się narzędziami kontenerowymi. Zdolność do szybkiego podniesienia środowiska testowego, wykonania aktualizacji bez ryzyka uszkodzenia systemu bazowego oraz automatyzacji kopii zapasowych jest dziś kluczową kompetencją zawodową w zespołach Network Operations Center.
Wszystkie prezentowane konfiguracje YAML oraz polecenia CLI zostały przetestowane i są w 100% zgodne z aktualnymi standardami technologicznymi.
Slajd 3/22
Paradygmat konteneryzacji: Docker a maszyny wirtualne w monitoringu sieci
Cel slajdu: Zrozumienie fundamentalnych różnic architektonicznych pomiędzy pełną wirtualizacją sprzętową (VM) a konteneryzacją na poziomie jądra Linuksa.
Współdzielenie jądra a hipernadzorca: narzut zasobowy i elastyczność
Maszyny wirtualne emulują kompletny sprzęt i uruchamiają własne jądro OS (Guest OS), podczas gdy kontenery izolują procesy użytkownika przy użyciu mechanizmów jądra gospodarza.
Narzut zasobowy (Overhead): Kontenery startują w ułamku sekundy i zużywają ułamek pamięci RAM wymaganej przez VM; brak konieczności alokacji pamięci dla wielu instancji jądra
Obraz kontenera (Image) a Kontener (Container): Obraz to niezmienna, wielowarstwowa matryca (read-only); kontener to uruchomiona instancja obrazu z cienką warstwą zapisu
Korzyści dla monitoringu NMS: Spójność środowiska (eliminacja problemu 'u mnie działa'), izolacja konfliktowych wersji bibliotek PHP/Python oraz bezproblemowe aktualizacje
Kontener Docker: Lekki, izolowany proces systemowy uruchomiony w przestrzeni użytkownika, współdzielący jądro systemu Linux z innymi kontenerami i systemem hosta.
W instalacjach monolitycznych aktualizacja dystrybucji Linuxa (np. z Ubuntu 22.04 na 24.04) często prowadzi do wymiany wersji PHP (np. z 8.1 na 8.3), co może unieruchomić starsze wtyczki NMS lub rozszerzenia bazy danych. W środowisku kontenerowym system operacyjny hosta odpowiada wyłącznie za udostępnienie jądra Linux i silnika Docker.
Dzięki konteneryzacji zespół inżynierów może przetestować nową wersję LibreNMS na kopii bazy danych w kilka minut na laptopie roboczym, eliminując ryzyko przestojów w centrum operacji sieciowych.
W systemie monitoringu sieci wydajność ma kluczowe znaczenie. Gdy serwer NMS odpytuje tysiące portów co 300 sekund, narzut generowany przez wirtualizatory (np. emulowane karty sieciowe vNIC) może powodować opóźnienia w obsłudze pakietów UDP SNMP. Kontenery Docker korzystają bezpośrednio ze stosu sieciowego jądra hosta, eliminując to zjawisko.
Mechanizm `cgroups` (Control Groups) pozwala zagwarantować, że proces bazy danych MariaDB nie zostanie zagłodzony przez intensywnie odpytujące skrypty pollerów. Inżynier może przypisać twarde limity: np. kontener bazy ma zagwarantowane 4 rdzenie i 8 GB RAM, a poller nie może przekroczyć 50% dostępnego czasu procesora.
Szczegółowy opis mechanizmów jądra Linux wykorzystywanych przez kontenery dostępny jest w manualu systemowym: `man 7 namespaces` oraz `man 7 cgroups`.
Podstawową zasadą pracy z kontenerami jest ich 'ulotność' (ephemeral nature). Kontener można w każdej chwili zatrzymać, usunąć i odtworzyć na nowo. Z tego powodu żadne krytyczne dane (takie jak rekordy bazy danych MariaDB czy historia wykresów RRD) nigdy nie mogą być zapisywane bezpośrednio wewnątrz kontenera.
Do utrwalania stanu służą wolumeny Dockera (Docker Volumes). Są to wydzielone katalogi w systemie plików hosta, montowane do wnętrza kontenera pod wskazaną ścieżką (np. `/data`). Dane w wolumenie przeżywają restarty i aktualizacje całego stosu.
Wbudowany w Dockera mechanizm Service Discovery eliminuje konieczność ręcznego konfigurowania adresów IP. Jeśli w pliku Compose usługa bazy danych nazwana jest `db`, to kontener LibreNMS łączy się z nią wpisując po prostu host: `db`.
Slajd 4/22
Instalacja silnika Docker i podstawy zarządzania kontenerami z poziomu CLI
Cel slajdu: Opanowanie instalacji silnika Docker Engine na serwerze Linux oraz podstawowych poleceń wiersza poleceń do zarządzania cyklem życia kontenerów.
Wdrożenie repozytorium oficjalnego i elementarz poleceń Docker CLI
Instalacja silnika Docker na serwerze Ubuntu LTS wymaga dodania oficjalnego repozytorium Docker i pobrania pakietów docker-ce oraz wtyczki docker-compose-plugin.
Nadzór nad kontenerami:docker ps -a (lista kontenerów), docker run (uruchomienie), docker stop (zatrzymanie), docker rm (usunięcie)
Inspekcja i logi:docker logs -f <kontener> (podgląd strumienia logów w czasie rzeczywistym), docker exec -it <kontener> bash (wejście do powłoki)
Zarządzanie zasobami:docker stats (ciągły monitoring zużycia procesora, pamięci RAM i operacji sieciowych/dyskowych przez kontenery)
Docker Engine: Podstawowe oprogramowanie typu klient-serwer składające się z demona (dockerd), interfejsu API oraz klienta CLI, zarządzające tworzeniem i uruchamianiem kontenerów.
Współczesny Docker Compose v2 nie jest już skryptem w języku Python (jak historyczny `docker-compose`), lecz integralną wtyczką wiersza poleceń (CLI plugin) napisaną w języku Go. Wywołuje się go spacją: `docker compose`.
Do poprawnego działania na serwerach Ubuntu i Debian niezbędne jest zainstalowanie trzech kluczowych komponentów: `docker-ce` (demon systemowy dockerd), `containerd.io` (niskopoziomowy zarządca cyklu życia kontenerów OCI) oraz `docker-buildx-plugin` (nowoczesny silnik budowania obrazów).
Oficjalna dokumentacja instalacyjna dla wszystkich wiodących dystrybucji Linux znajduje się pod adresem: docs.docker.com/engine/install/.
Polecenie `docker exec` jest najczęściej wykorzystywanym narzędziem przez administratorów LibreNMS. Pozwala ono na wywołanie oficjalnego CLI systemu (narzędzia `lnms`) wewnątrz działającego kontenera bez konieczności uruchamiania serwera SSH.
Warto pamiętać, że zatrzymanie kontenera (`docker stop`) zachowuje jego stan i system plików. Dopiero polecenie `docker rm` bezpowrotnie usuwa kontener z dysku. Jeśli dane były zapisane w wolumenie zewnętrznym, pozostają nienaruszone.
W przypadku środowisk laboratoryjnych opartych na dystrybucji Debian lub Rocky Linux kroki są analogiczne, z użyciem menedżerów pakietów apt lub dnf.
Weryfikacja wersji zainstalowanego oprogramowania: docker version docker compose version Współczesny Docker Compose działa jako wtyczka CLI (komenda `docker compose`, z spacją), zastępując przestarzały skrypt Pythona `docker-compose` (z myślnikiem).
Orkiestracja wielokontenerowa: architektura i składnia Docker Compose (compose.yml)
Cel slajdu: Zrozumienie deklaratywnego definiowania złożonych aplikacji wielokontenerowych za pomocą pliku konfiguracyjnego compose.yml.
Deklaratywny opis infrastruktury w standardzie YAML
Zamiast ręcznie wpisywać dziesiątki skomplikowanych poleceń docker run, całą architekturę wielousługową NMS definiuje się w jednym pliku konfiguracyjnym compose.yml.
Sekcja services: Definicja kontenerów składowych (np. db, redis, rrdcached, librenms); określenie obrazów, polityki restartu (restart: unless-stopped) i portów
Relacje zależności (depends_on): Definiowanie kolejności rozruchu; kontener LibreNMS czeka na zainicjalizowanie i gotowość bazy danych MariaDB
Sekcje networks i volumes: Deklaracja wspólnej sieci wirtualnej łączącej kontenery oraz nazwanych wolumenów dyskowych zapewniających trwałość bazy i wykresów
Polecenia operacyjne Compose:docker compose up -d (uruchomienie całego stosu w tle), docker compose down (zatrzymanie), docker compose pull (pobranie nowych wersji)
Docker Compose: Narzędzie orkiestracji umożliwiające definiowanie i uruchamianie wielokontenerowych aplikacji Docker za pomocą deklaratywnego pliku formatu YAML.
W systemie LibreNMS architektura wymaga jednoczesnej pracy co najmniej czterech procesów: serwera WWW z kodem PHP, relacyjnej bazy danych MariaDB, pamięci podręcznej Redis oraz demona pobierającego dane telemetryczne. W Compose każdy z tych procesów zamykany jest w osobnym kontenerze, a narzędzie dba o ich prawidłowe połączenie.
Dzięki Compose cała wiedza o architekturze systemu staje się kodem (IaC). Plik konfiguracyjny może być umieszczony w wewnętrznym repozytorium GitLab/GitHub, co zapewnia pełną audytowalność zmian wprowadzanych przez zespół inżynierów sieciowych.
Więcej o składni i specyfikacji Compose Specification można dowiedzieć się na oficjalnej stronie: docs.docker.com/compose/.
Warto zwrócić uwagę na dyrektywę `restart: always`. W środowisku produkcyjnym NMS jest ona kluczowa: jeśli serwer fizyczny zostanie zrestartowany (np. po awarii zasilania), demon Dockera automatycznie uruchomi cały stos monitoringu bez konieczności interwencji administratora.
Sekcja `networks` pozwala na precyzyjną definicję adresacji IP. Dzięki dyrektywie `ipam` (IP Address Management) inżynier może przypisać dedykowaną podsieć prywatną (np. `172.28.0.0/16`), co ułatwia późniejsze konfigurowanie reguł firewall iptables/nftables na serwerze hosta.
W nowoczesnej specyfikacji Compose pomija się już dyrektywę `version: '3.8'` na początku pliku – silnik Docker Compose v2 automatycznie stosuje najnowsze rozszerzenia standardu.
Slajd 6/22
Architektura wielousługowego stosu LibreNMS w kontenerach
Cel slajdu: Szczegółowa dekompozycja oficjalnego stosu LibreNMS Docker na współpracujące kontenery mikrousług.
Modułowy podział zadań w oficjalnym stosie kontenerowym
Oficjalny stos LibreNMS Docker dzieli monolit na wyspecjalizowane kontenery, z których każdy realizuje ściśle określone zadanie systemowe.
Kontener bazy danych (db): Serwer MariaDB zoptymalizowany pod kątem intensywnego zapisu metadanych i inwentaryzacji sieci
Kontener pamięci podręcznej (redis): Baza klucz-wartość w pamięci RAM; realizuje mechanizm blokad rozproszonych i kolejkowania zadań dla pollerów
Kontener bufora metryk (rrdcached): Demon buforujący zapisy do plików RRD w pamięci operacyjnej przed zrzuceniem na dysk
Kontener aplikacji głównej (librenms): Serwer webowy Nginx i PHP-FPM; prezentacja GUI, obsługa zapytań użytkowników oraz API REST
Kontenery dyspozytora (dispatcher): Procesy w języku Python cyklicznie pobierające zadania odpytywania węzłów sieciowych z kolejki Redis
Stos LibreNMS Docker: Zbiór współpracujących kontenerów realizujących kompletną funkcjonalność systemu NMS w architekturze mikrousługowej.
W instalacji kontenerowej LibreNMS żaden proces nie jest zbędnie obciążany. Podczas gdy serwer WWW renderuje pulpity operatorskie, osobny kontener `dispatcher` wykonuje tysiące zapytań SNMP w tle, koordynowany przez pamięć podręczną Redis.
Wszystkie kontenery współdzielą wspólny wolumen dyskowy dla bazy RRDtool (`/opt/librenms/rrd`). Gdy poller pobierze nowe dane telemetryczne, zapisuje je bezpośrednio do pliku RRD, skąd interfejs WWW może natychmiast wygenerować zaktualizowany wykres.
Kod źródłowy oficjalnych obrazów oraz przykładowe pliki Compose dostępne są w repozytorium: github.com/librenms/docker.
Slajd 7/22
Usługi bazodanowe i pamięci podręcznej stosu: MariaDB, Redis i RRDcached
Cel slajdu: Poznanie parametrów optymalizacyjnych dla usług składowania danych w środowisku kontenerowym.
Konfiguracja baz danych i pamięci podręcznej pod kątem wysokiej wydajności I/O
Wydajność systemu NMS zależy bezpośrednio od konfiguracji podsystemu bazodanowego i eliminacji wąskich gardeł operacji wejścia/wyjścia (I/O) na dyskach.
Optymalizacja MariaDB: Kodowanie znaków utf8mb4, mechanizm tabel InnoDB, parametr innodb_file_per_table=1, dopasowanie innodb_buffer_pool_size do wielkości RAM
Rola serwera Redis: Przechowywanie kolejki zadań IPC (Inter-Process Communication); obsługa tysięcy operacji na sekundę przy minimalnym opóźnieniu
Strojenie demona RRDcached: Parametry -w 1800 -z 1800 -f 3600 opóźniają fizyczny zapis do plików .rrd o 30 minut, łącząc setki małych zapisów w jeden duży blok
Współdzielenie gniazda unix socket: Komunikacja kontenera LibreNMS z RRDcached poprzez współdzielony wolumen lub dedykowany port TCP 42217
Demon RRDcached w kontenerze: Wyspecjalizowana usługa redukująca obciążenie dysku twardego serwera NMS poprzez agregowanie próbek pomiarowych w pamięci RAM.
Z punktu widzenia cyberbezpieczeństwa bardzo ważną dobrą praktyką jest dyrektywa `MARIADB_RANDOM_ROOT_PASSWORD=yes`. Powoduje ona wygenerowanie losowego hasła konta root, a aplikacja LibreNMS komunikuje się za pośrednictwem dedykowanego użytkownika o ograniczonych uprawnieniach zdefiniowanego w zmiennej `MARIADB_USER`.
W przypadku dużych instalacji (>500 węzłów) zaleca się przekazanie dodatkowych flag w sekcji `command:`, m.in. `innodb_buffer_pool_size=4G` (dopasowane do ilości RAM na hoście) oraz `innodb_log_file_size=512M`, co drastycznie redukuje opóźnienia zapisu zdarzeń Syslog i eventlog.
Dokumentacja oficjalnego obrazu MariaDB na Docker Hub dostępna jest pod adresem: hub.docker.com/_/mariadb.
W instalacjach bez RRDcached każdy 5-minutowy cykl odpytania 500 przełączników (średnio 24 000 portów) zmusza jądro systemu do otwarcia, zmodyfikowania i zamknięcia 24 000 odrębnych plików `.rrd`. Taki profil operacji (Random I/O) potrafi całkowicie zablokować nawet szybkie macierze dyskowe.
Wdrożenie kontenera `librenms/rrdcached` powoduje, że odpytywacze wysyłają proste komendy tekstowe przez protokół sieciowy do demona bufora, który akumuluje zmiany w pamięci RAM. Gdy użytkownik zażąda wykresu w przeglądarce, demon w locie łączy dane z dysku ze świeżymi próbkami z pamięci podręcznej.
Konfiguracja kontenera głównego LibreNMS i separacja zmiennych środowiskowych (.env)
Cel slajdu: Opanowanie zasad bezpiecznego konfigurowania aplikacji kontenerowej poprzez pliki zmiennych środowiskowych .env.
Bezpieczeństwo poświadczeń i parametryzacja w pliku librenms.env
Zgodnie z metodologią Twelve-Factor App, konfiguracja aplikacji i poświadczenia dostępowe nie mogą być zaszyte w obrazie, lecz przekazywane w zmiennych środowiska.
Plik .env (Zmienne globalne Compose): Zawiera wersje obrazów, porty wystawiane na zewnątrz, hasła bazy danych (MYSQL_PASSWORD, MYSQL_ROOT_PASSWORD)
Izolacja sekretów: Pliki .env muszą mieć restrykcyjne uprawnienia systemowe (chmod 600) i być bezwzględnie dodane do .gitignore
Automatyczna migracja bazy: Kontener główny podczas pierwszego startu automatycznie wykonuje migracje schematu bazy danych (artisan migrate)
Plik .env: Plik konfiguracyjny w formacie klucz=wartość, wykorzystywany przez Docker Compose do wstrzykiwania zmiennych konfiguracyjnych i haseł do kontenerów.
Warto zauważyć konstrukcję `depends_on: db: { condition: service_healthy }`. W standardowym Dockerze samo uruchomienie kontenera bazy danych nie oznacza, że jest ona gotowa do przyjmowania połączeń (MariaDB może jeszcze inicjalizować pliki bazy na dysku). Zastosowanie mechanizmu Healthcheck gwarantuje, że LibreNMS nie zakończy się błędem `Connection refused` podczas startu.
Kontener zawiera wewnątrz zintegrowany serwer Nginx skonfigurowany pod kątem wydajnościowego przesyłania wykresów SVG/PNG i ochrony nagłówków HTTP (m.in. Content-Security-Policy).
Wykorzystanie parametrów `PUID` (Process User ID) i `PGID` (Process Group ID) to sprawdzony wzorzec w kontenerach opartych na dystrybucji Alpine Linux. Sprawia on, że procesy wewnątrz kontenera tworzą pliki z identyfikatorami właściciela zgodnymi z kontem administratora na serwerze fizycznym, co umożliwia bezproblemowe wykonywanie backupów.
W przypadku sieci o dużej skali parametr `MEMORY_LIMIT=2048M` zapobiega przerywaniu procesu autoodkrywania (discovery), który przy parsowaniu gigantycznych tablic routingu BGP potrafi zużyć powyżej 512 MB pamięci operacyjnej.
Oficjalna specyfikacja metodologii The Twelve-Factor App w zakresie konfiguracji środowiskowej: 12factor.net/config.
Zaleca się natychmiastowe zablokowanie uprawnień do pliku `.env`, aby inni użytkownicy systemu nie mogli odczytać haseł: chmod 600 /opt/nms-librenms/.env
Narzędzie `docker compose config` wykonuje pełną analizę semantyczną: weryfikuje istnienie zdefiniowanych sieci, poprawność typów portów oraz podstawia wartości zmiennych z pliku `.env` do szablonu YAML.
Wdrożenie, rozruch krok po kroku i diagnostyka operacyjna stosu
Cel slajdu: Przeprowadzenie kompletnej procedury uruchomienia stosu kontenerowego oraz diagnostyka ewentualnych błędów startowych.
Procedura rozruchu stosu i analiza stanów kontenerów
Wdrożenie stosu w kontenerach wymaga zachowania ścisłej kolejności czynności instalacyjnych oraz weryfikacji zdrowia (healthcheck) poszczególnych usług.
Krok 1: Pobranie obrazów i rozruch: Wykonanie polecenia docker compose up -d w katalogu z plikami compose.yml i .env
Krok 2: Weryfikacja statusów usług: Sprawdzenie czy wszystkie kontenery mają stan Up (healthy) poleceniem docker compose ps
Krok 3: Analiza dzienników zdarzeń: Sprawdzenie logów inicjalizacji bazy i serwera WWW: docker compose logs -f librenms
Krok 4: Utworzenie pierwszego administratora: Wykonanie polecenia wewnątrz kontenera: docker compose exec librenms setup-first-run lub przez GUI instalatora
Mechanizm Healthcheck: Wbudowany w Docker mechanizm cyklicznego testowania poprawności działania usługi wewnątrz kontenera (np. zapytanie HTTP lub ping SQL).
W trakcie pierwszego uruchomienia skrypt startowy kontenera sprawdza stan tabel bazy danych. Jeśli baza jest pusta, uruchamiane jest polecenie `php artisan migrate --force`, które automatycznie tworzy ustrukturyzowany schemat relacyjny.
Po zakończeniu migracji generowany jest domyślny użytkownik administracyjny (jeśli zdefiniowano zmienne `LIBRENMS_USER` i `LIBRENMS_PASSWORD` w pliku `.env`), co umożliwia natychmiastowe zalogowanie się do panelu webowego bez konieczności przechodzenia przez kreator przeglądarkowy.
W przypadku napotkania problemów z połączeniem z bazą danych pierwszym krokiem jest weryfikacja logów kontenera MariaDB poleceniem: `docker compose logs db`.
W architekturze kontenerowej status `Up` oznacza jedynie, że proces główny kontenera nie uległ awarii. Dopiero status `(healthy)` gwarantuje, że aplikacja prawidłowo odpowiada na zapytania testowe HTTP na porcie 8000, a baza danych akceptuje zapytania SQL.
Wywołanie `docker compose exec librenms validate.php` pozwala zweryfikować czy wewnątrz kontenera wszystkie rozszerzenia PHP (m.in. fping, rrdtool, snmp) działają poprawnie i czy uprawnienia do współdzielonych wolumenów nie zostały uszkodzone.
W przypadku awarii kontenera i jego ciągłego restartowania (tzw. stan `CrashLoopBackOff`), polecenie `docker compose logs --tail=100 service_name` pozwala natychmiast zidentyfikować przyczynę usterki (np. brakujący parametr w pliku `.env`).
W przypadku pierwszego uruchomienia migracje bazodanowe mogą zająć od 30 do 60 sekund w zależności od wydajności dysków I/O serwera. Nie należy przerywać procesu migracji, gdyż może to pozostawić bazę w stanie niespójnym.
Weryfikacja stanu stosu po uruchomieniu: docker compose exec librenms ./validate.php Polecenie to weryfikuje uprawnienia do katalogów, połączenie z bazą danych, spójność schematu SQL oraz komunikację z demonem RRDcached.
Trwałość danych (Wolumeny Docker) i cykl aktualizacji kontenerów
Cel slajdu: Zrozumienie koncepcji trwałości danych w wolumenach Dockera oraz procedur bezprzerwowej aktualizacji oprogramowania NMS.
Wolumeny nazwane, separacja danych od logiki i procedury update
Kontenery są z definicji ulotne (ephemeral); usunięcie kontenera nie może spowodować utraty bazy danych, plików RRD ani konfiguracji systemu.
Wolumeny nazwane (Named Volumes): Trwałe przestrzenie dyskowe zarządzane przez Docker w /var/lib/docker/volumes/ (np. db_data, rrd_data)
Bindowanie katalogów (Bind Mounts): Mapowanie konkretnych katalogów z dysku gospodarza (np. ./rrd:/opt/librenms/rrd) ułatwiające bezpośredni dostęp
Cykl aktualizacji kontenerów: 1. Pobranie nowych obrazów: docker compose pull; 2. Przeładowanie stosu: docker compose up -d
Brak przestoju (Zero-downtime): Docker najpierw pobiera nowy obraz, a następnie natychmiast podmienia kontener; wolumeny bazy i metryk pozostają nienaruszone
Wolumen Docker (Volume): Mechanizm trwałego składowania danych poza cyklem życia kontenera, gwarantujący zachowanie informacji po jego restarcie lub zniszczeniu.
W instalacjach monitoringu sieciowego zapisywanie plików baz danych RRDtool lub MariaDB bezpośrednio w warstwie CoW kontenera jest poważnym błędem architektonicznym. Sterowniki pamięci masowej (np. overlay2) wprowadzają dodatkowy narzut translacji bloków, co drastycznie obniża IOPS.
Zamontowanie dedykowanego wolumenu (lub bind mount na szybkim nośniku NVMe) pozwala procesowi w kontenerze na bezpośredni zapis blokowy z pominięciem sterownika overlay2, gwarantując 100% natywnej wydajności kontrolera pamięci masowej.
W tradycyjnych systemach aktualizacja LibreNMS odbywała się przez automatyczny skrypt `daily.sh`, który pobierał kod bezpośrednio z gałęzi master Git. Jeśli w kodzie pojawił się błąd lub konflikt bibliotek Composer, monitoring ulegał awarii na serwerze produkcyjnym.
W modelu kontenerowym zespół LibreNMS publikuje gotowe, przetestowane obrazy powiązane ze stabilnymi wydaniami (Releases). Administrator kontroluje dokładny moment aktualizacji i może w każdej chwili powrócić do poprzedniego wydania.
Dobrą praktyką w środowiskach Enterprise jest przypisywanie konkretnych tagów wydań (np. `librenms/librenms:24.9.0`) zamiast zmiennego tagu `:latest`, co zapewnia 100% determinizmu wdrożenia.
Slajd 11/22
Skalowanie horyzontalne pollerów: kontenery Dispatcher i narzędzie lnms CLI
Cel slajdu: Poznanie zasad skalowania procesów odpytujących oraz posługiwania się konsolowym narzędziem lnms wewnątrz kontenera.
Rozproszenie pollerów w kontenerach i zarządzanie z CLI
Dzięki konteneryzacji skalowanie mocy odpytywania sprowadza się do zwielokrotnienia kontenerów dyspozytora zadań (Dispatcher) korzystających ze wspólnej kolejki Redis.
Narzędzie lnms: Oficjalne narzędzie wiersza poleceń frameworka LibreNMS pozwalające na pełną administrację systemem z poziomu powłoki Linuksa.
W tradycyjnej instalacji na pojedynczym serwerze skalowanie pollerów wymagało ręcznej edycji zadań cron i tworzenia skomplikowanych wrapperów skryptowych. W Docker Compose konteneryzacja usługi `dispatcher` pozwala traktować procesy odpytujące jako bezstanowe zasoby obliczeniowe.
Dzięki wykorzystaniu brokera Redis żaden przełącznik nie zostanie odpytany podwójnie. Redis stosuje atomowe operacje blokad rozproszonych (Distributed Locks), przypisując zadanie dokładnie jednemu kontenerowi, który po zakończeniu odpytania zwalnia blokadę w pamięci podręcznej.
Narzędzie `lnms` to zintegrowana konsola administracyjna zbudowana w oparciu o komponent Symfony Console wewnątrz frameworka Laravel. Udostępnia dziesiątki komend do zarządzania urządzeniami, bazą danych, konfiguracją powiadomień oraz wtyczkami.
W przypadku awarii interfejsu graficznego (np. błąd uprawnień sesji w przeglądarce), polecenie `docker compose exec librenms lnms user:add` pozwala na natychmiastowe utworzenie nowego użytkownika o uprawnieniach administratora z poziomu konsoli serwera.
Wszystkie komendy wykonują się w kontekście użytkownika systemowego kontenera, dzięki czemu pliki tworzone w trakcie operacji (np. logi czy zrzuty MIB) zachowują poprawne uprawnienia własności.
W przypadku dodawania urządzenia z protokołem SNMP v3 składnia polecenia przyjmuje dodatkowe argumenty uwierzytelniania: docker compose exec librenms lnms device:add --v3 -u secmon -a SHA -A HasloAuth123! -x AES -X HasloPriv123! 10.99.0.1
Po wykonaniu pierwszego pollowania urządzenie automatycznie pojawia się na liście urządzeń w panelu Web UI, a demon dispatcher przejmuje jego cykliczne odpytywanie co 5 minut.
Usługi pomocnicze w kontenerach: Syslog (syslog-ng), SNMP Traps i kopie Oxidized
Cel slajdu: Integracja usług asynchronicznych i narzędzi archiwizacji konfiguracji w ramach wspólnego stosu Docker Compose.
Rozszerzenie stosu o nasłuch zdarzeń i wersjonowanie konfiguracji
Kompletne środowisko NMS w Dockerze rozszerza bazowy stos o kontenery odbiornika logów Syslog, pułapek SNMP Traps oraz demona archiwizacji urządzeń Oxidized.
Kontener syslog-ng: Nasłuchuje na porcie UDP/TCP 514; parsuje komunikaty urządzeń i zapisuje je bezpośrednio do tabeli syslog w bazie MariaDB
Kontener snmptrapd: Odbiera pułapki SNMP na porcie UDP 162; przekazuje zdekodowane powiadomienia do panelu zdarzeń LibreNMS
Kontener Oxidized: Skonfigurowany w pliku compose; cyklicznie pobiera konfiguracje przełączników i routerów przez SSH, integrując się z API LibreNMS
Repozytorium Git w kontenerze: Automatyczny zapis kopii zapasowych w lokalnym repozytorium Git na wolumenie trwałym
Kontener usług pomocniczych (Sidecar Container): Wzorzec projektowy polegający na dołączeniu wyspecjalizowanego kontenera realizującego dodatkową funkcję (np. logowanie lub backup) obok kontenera głównego.
W oficjalnym ekosystemie LibreNMS dla kontenerów nie istnieje oddzielny obraz `librenms/syslog-ng`. Zamiast tego stosowany jest ten sam jednolity obraz `librenms/librenms:latest`, który po wykryciu zmiennej środowiskowej `SIDECAR_SYSLOGNG=1` przełącza skrypt startowy kontenera w tryb demona odbioru i parsowania logów sieciowych Syslog.
Kontener łączy się bezpośrednio z kontenerem bazy danych przez wewnętrzną sieć mostkową na porcie 3306. Wykorzystuje buforowanie w pamięci RAM, co zabezpiecza bazę MariaDB przed zablokowaniem w przypadku nagłego skoku liczby zdarzeń w sieci LAN.
Wdrożenie dedykowanego kontenera `snmptrapd` chroni główny serwer WWW przed zawieszeniem. W przypadku masowej awarii w sieci szkieletowej (np. awaria zasilania w dużej szafie dystrybucyjnej), setki urządzeń wysyłają pułapki jednocześnie. Dedykowany demon przetwarza je w izolacji i bezpiecznie zapisuje w kolejce bazy danych.
Wewnątrz kontenera demon odczytuje definicję trapów z zamontowanych baz MIB, dzięki czemu w dzienniku zdarzeń zamiast trudnych do interpretacji numerów OID (np. `.1.3.6.1.6.3.1.1.5.3`) inżynier widzi czytelną nazwę `IF-MIB::linkDown` wraz ze wskazaniem nazwy portu.
Włączenie kontenera Oxidized do pliku `docker-compose.yml` zamyka lukę w zarządzaniu konfiguracją. Tradycyjnie administratorzy zapominali o wykonywaniu kopii zapasowych przełączników przed wprowadzeniem zmian, co w przypadku awarii wydłużało czas przywracania sieci (MTTR) o wiele godzin.
Dzięki archiwizacji w Git każdy inżynier może prześledzić pełną historię modyfikacji tras routingu, reguł firewall czy przypisań VLAN z dokładnym znacznikiem czasowym.
Konfiguracja sieci kontenerowych (Docker Networking): tryb bridge a host_mode
Cel slajdu: Przeanalizowanie specyfiki sieciowej kontenerów w kontekście odbioru pakietów UDP i telemetrii sieciowej.
Zarządzanie adresacją, mapowanie portów i analiza trybu host
Wybór trybu sieciowego w środowisku Docker decyduje o wydajności odbierania milionów pakietów telemetrycznych oraz prawidłowej identyfikacji adresów IP nadawców.
Dedykowana sieć Bridge: Domyślny tryb Compose; izolowana podsieć wirtualna (np. 172.20.0.0/16); porty są mapowane (np. 8000:80/tcp) przez reguły iptables
Problem NAT w trybie Bridge: W niektórych konfiguracjach translacja adresów zaciera rzeczywisty adres źródłowy pakietu UDP (np. Syslog), utrudniając identyfikację węzła
Tryb network_mode: host: Kontener współdzieli bezpośrednio stos sieciowy i adresy IP serwera fizycznego; zerowy narzut wydajnościowy translacji pakietów
Rekomendacja architektoniczna: Zastosowanie trybu bridge dla baz danych (bezpieczeństwo) oraz trybu host lub precyzyjnego mapowania UDP dla odbiorników Syslog i Traps
Tryb sieciowy host (Docker): Konfiguracja, w której kontener nie otrzymuje własnego wirtualnego interfejsu sieciowego, lecz korzysta bezpośrednio z kart sieciowych serwera gospodarza.
Dzięki sieci typu Bridge architektura NMS uzyskuje wysoki poziom bezpieczeństwa. Nawet jeśli baza danych MariaDB lub pamięć Redis nie posiadają skomplikowanych haseł, intruz znajdujący się w sieci LAN firmy nie ma możliwości nawiązania z nimi połączenia, ponieważ ich porty nie są wystawione na zewnątrz hosta.
W przypadku zapytań SNMP wysyłanych przez kontener `dispatcher` do przełączników w sieci fizycznej, jądro Linux stosuje regułę `iptables -t nat -A POSTROUTING -s 172.28.0.0/16 -j MASQUERADE`. Z punktu widzenia monitorowanego routera zapytanie SNMP pochodzi z fizycznego adresu IP serwera NMS.
Gdy kontener działa w trybie `bridge`, każdy wysyłany pakiet ICMP Echo Request narzędzia `fping` musi zostać zarejestrowany przez mechanizm Connection Tracking jądra Linux. W skrajnych przypadkach (np. skanowanie podsieci `/16` z tysiącami nieodpowiadających hostów) może to doprowadzić do błędu `nf_conntrack: table full, dropping packet`.
W trybie `network_mode: host` pakiety wychodzą bezpośrednio z gniazda fizycznego z pominięciem reguł translacji NAT, co eliminuje narzut procesora o około 5-10% i zapewnia najniższe możliwe opóźnienia pomiarowe (RTT).
Ceną za wydajność trybu host jest jednak utrata bezpieczeństwa: porty aplikacji stają się bezpośrednio dostępne na wszystkich interfejsach fizycznych serwera.
Slajd 14/22
Bezpieczeństwo kontenerów: standardy CIS, Docker Rootless i zarządzanie sekretami
Cel slajdu: Poznanie zasad utwardzania środowiska kontenerowego zgodnie ze standardami Center for Internet Security (CIS Benchmark).
Utwardzanie silnika Docker i ochrona poświadczeń produkcyjnych
Serwer NMS posiada poświadczenia dostępowe do wszystkich urządzeń w firmie; skompromitowanie kontenera NMS stwarza krytyczne zagrożenie dla całej infrastruktury.
Standard CIS Docker Benchmark: Zbiór zaleceń audytowych: regularne aktualizacje obrazów bazowych, ograniczenie uprawnień demona dockerd, audyt konfiguracji (docker-bench-security)
Tryb Docker Rootless: Uruchomienie demona Docker i kontenerów w przestrzeni zwykłego użytkownika bez uprawnień roota; zapobiega eskalacji uprawnień w przypadku ucieczki z kontenera
Zasada najniższych uprawnień (Non-root user): Konfiguracja dyrektywy USER librenms w plikach Dockerfile kontenerów aplikacyjnych
Zarządzanie sekretami (Docker Secrets): Przechowywanie haseł bazodanowych i kluczy SNMPv3 w zaszyfrowanych strukturach zamiast jawnych plików tekstowych
Docker Rootless: Tryb pracy silnika Docker eliminujący konieczność uruchamiania demona z uprawnieniami superużytkownika root na serwerze gospodarza.
W kontekście europejskiej dyrektywy NIS 2 oraz polskiej Ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC), system NMS jest kwalifikowany jako element infrastruktury krytycznej podmiotu kluczowego. Oznacza to prawny wymóg regularnego audytu podatności obrazów kontenerowych.
Wdrożenie trybu Docker Rootless (lub alternatywnie technologii Podman) gwarantuje, że nawet w przypadku znalezienia luki zero-day w silniku PHP i ucieczki z kontenera (container breakout), atakujący znajdzie się na serwerze fizycznym jako nieuprzywilejowany użytkownik bez praw modyfikacji systemu.
Szczegółowy przewodnik zabezpieczeń dostępny jest w dokumencie Center for Internet Security: CIS Docker Benchmark.
W przypadku wycieku logów z wdrożeń CI/CD zmienne środowiskowe są często mimowolnie wypisywane na ekranie w trybie debugowania powłoki (`set -x`). Wykorzystanie mechanizmu Docker Secrets całkowicie eliminuje to zagrożenie.
Aplikacja wewnątrz kontenera traktuje zamontowany sekret jako zwykły plik tekstowy. W momencie uruchomienia proces odczytuje hasło z pamięci RAM i nawiązuje bezpieczne połączenie z bazą danych.
Monitorowanie samego serwera monitoringu (tzw. monitoring monitora) to fundament architektury wysokiej dostępności. cAdvisor rozróżnia pamięć faktycznie alokowaną przez procesy kontenera od pamięci podręcznej systemu plików (disk cache), co eliminuje fałszywe alarmy.
W połączeniu z Grafaną inżynierowie mogą stworzyć dedykowany dashboard obrazujący zużycie zasobów przez poszczególne mikroserwisy LibreNMS: ile RAM-u zużywa MariaDB, ile Redis, a jakie piki procesora generuje kontener `dispatcher` podczas cykli odpytywania.
Alternatywne środowiska uruchomieniowe: Podman oraz klasteryzacja Kubernetes
Cel slajdu: Przedstawienie alternatywnych technologii konteneryzacji bezdemonicznej (Podman) oraz orkiestracji w klastrach Kubernetes.
Architektura bezdemoniczna Podman i orkiestracja w K8s
Poza technologią Docker inżynierowie mają do dyspozycji bezdemoniczny silnik Podman oraz przemysłowy standard orkiestracji Kubernetes.
Technologia Podman (Pod Manager): W pełni kompatybilny zamiennik Dockera (Red Hat); architektura bez centralnego demona (Daemonless) z domyślnym trybem Rootless
Narzędzie podman-compose: Obsługa standardowych plików compose.yml w środowisku Podman bez zmian w strukturze projektu
Systemy NMS w klastrze Kubernetes: Zastosowanie kontrolerów StatefulSet dla baz danych (MariaDB, RRD) oraz Deployment dla bezstanowych pollerów i panelu WWW
Zalety orkiestracji K8s: Automatyczne samonaprawianie (Self-healing), skalowanie horyzontalne pollerów w zależności od obciążenia oraz scentralizowane zarządzanie sekretami
Środowisko Podman: Nowoczesne, bezdemoniczne narzędzie do uruchamiania kontenerów zgodnych ze standardem OCI (Open Container Initiative) bezpośrednio w przestrzeni użytkownika.
Podman powstał w firmie Red Hat jako odpowiedź na zastrzeżenia bezpieczeństwa związane z centralnym demonem Dockera. W klasycznym Dockerze demon `dockerd` działa z uprawnieniami superużytkownika root, co w przypadku błędu w oprogramowaniu stwarzało ryzyko przejęcia kontroli nad całym serwerem.
W Podmanie każdy kontener wykonuje się w przestrzeni użytkownika z wykorzystaniem mapowania identyfikatorów (`subuid` i `subgid`). Proces bazy MariaDB może myśleć, że jest rootem wewnątrz kontenera, podczas gdy na serwerze fizycznym posiada uprawnienia zwykłego użytkownika `jnowak`.
Chociaż Kubernetes znakomicie sprawdza się w orkiestracji bezstanowych mikrousług internetowych, systemy NMS oparte na starszych silnikach RRDtool natrafiają w nim na poważne wyzwania architektoniczne. RRDtool zakłada, że pliki znajdują się na lokalnym systemie plików POSIX.
W nowoczesnych projektach realizowanych w Kubernetesie coraz częściej rezygnuje się z tradycyjnego stosu RRD na rzecz natywnych baz szeregów czasowych, takich jak VictoriaMetrics lub Prometheus TSDB, które posiadają wbudowane rozproszone mechanizmy zapisu sieciowego.
Architektura sieci zarządzania (Management VLAN) i wymiarowanie zasobów serwera
Cel slajdu: Zaplanowanie dedykowanej sieci zarządzania oraz wyznaczenie parametrów sprzętowych pod produkcyjny serwer kontenerowy.
Izolacja ruchu telemetrycznego i kalkulacja zasobów serwera
Serwer kontenerowy NMS musi być wpięty do dedykowanego, bezpiecznego segmentu sieci zarządzania, a jego zasoby obliczeniowe dobrane z bezpiecznym zapasem.
Wydzielona sieć zarządzania (Management VLAN): Odseparowana podsieć logiczna (np. VLAN 99, 10.99.0.0/24) łącząca wyłącznie porty zarządzające urządzeń aktywnych i serwer NMS
Restrykcyjna polityka zapory: Całkowity zakaz routingu z podsieci użytkowników i Internetu do Management VLAN; dostęp wyłącznie przez szyfrowany tunel VPN/WireGuard
Wymiarowanie zasobów sprzętowych: Do 100 urządzeń: 4 rdzenie vCPU, 8 GB RAM, 100 GB SSD NVMe; do 1000 urządzeń: 8-16 rdzeni vCPU, 32 GB RAM, 500 GB NVMe w RAID-1
Kluczowy parametr IOPS: Zapis wykresów RRD generuje tysiące losowych operacji wejścia/wyjścia na sekundę; dyski mechaniczne HDD są całkowicie nieodpowiednie pod serwer NMS
Management VLAN: Logicznie wyizolowana sieć wirtualna IEEE 802.1Q dedykowana wyłącznie do komunikacji administracyjnej, telemetrycznej i diagnostycznej urządzeń sieciowych.
Częstym błędem młodych zespołów IT jest próba wdrożenia klastra Kubernetes dla monitorowania sieci liczącej 100 przełączników. W rezultacie inżynierowie poświęcają więcej czasu na debugowanie problemów z siecią CNI i wolumenami CSI w klastrze K8s niż na nadzór nad rzeczywistą siecią LAN.
Współczesne serwery z procesorami AMD EPYC lub Intel Xeon oraz pamięciami masowymi NVMe posiadają tak potężną moc obliczeniową, że pojedynczy serwer o wysokości 1U bez trudu obsługuje całą telemetrię dużego kampusu uniwersyteckiego.
Kluczem do niezawodności podejścia Standalone jest regularne testowanie procedury Disaster Recovery: cotygodniowy automatyczny test odtworzenia kontenerów na zapasowej maszynie testowej.
W Docker Compose dyrektywa `deploy.resources` pozwala zabezpieczyć serwer przed skutkami awarii aplikacji. Jeśli skrypt pollerowy wpadnie w nieskończoną pętlę i zacznie alokować pamięć, demon Dockera ograniczy go do zdefiniowanego limitu (np. `4096M`) i w razie potrzeby zrestartuje wyłącznie ten jeden kontener.
Warto zwrócić uwagę na przestrzeń dyskową dla logów Dockera. Domyślnie Docker zapisuje wyjście standardowe kontenerów w plikach JSON (`/var/lib/docker/containers/...`), które potrafią zapełnić cały dysk. W pliku Compose lub w `/etc/docker/daemon.json` należy skonfigurować rotację logów (`max-size: 50m`, `max-file: 3`).
W konfiguracji z Dockerem serwer hosta może posiadać dwie fizyczne karty sieciowe: interfejs `eth0` wpięty do sieci biurowej (na którym wystawiony jest port HTTP 8000 dla operatorów) oraz dedykowany interfejs `eth1` wpięty bezpośrednio do sieci zarządzającej (bez routingu do Internetu).
Dzięki temu kontener aplikacji LibreNMS pełni rolę bezpiecznej bramy: operatorzy logują się do panelu przez sieć LAN, a zapytania SNMP wychodzą wyłącznie przez odizolowaną sieć OOB/Management.
Konfiguracja nadawania Syslog: Skierowanie strumienia zdarzeń na adres IP serwera kontenerowego (port UDP 514)
Access Control List w SNMP: Reguła filtrująca w urządzeniu sieciowym zezwalająca na wykonywanie zapytań SNMP wyłącznie ze wskazanego adresu IP serwera NMS.
Po skonfigurowaniu routera MikroTik inżynier może natychmiast przetestować połączenie z poziomu konsoli serwera hosta: `docker compose exec librenms snmpwalk -v2c -c NmsCorpCommunity 10.99.0.1 sysName.0`. Jeśli konfiguracja jest poprawna, polecenie zwróci nazwę routera.
Włączenie zdalnego logowania (`/system logging`) z filtrem na tematy `critical, error, warning` pozwala LibreNMS na natychmiastowe wykrywanie incydentów takich jak restarty zasilania, błędy negocjacji interfejsów czy ataki typu brute-force na port SSH routera.
W przełącznikach Cisco Catalyst polecenie `snmp-server community Nazwa RO ACL_NAME` jest najskuteczniejszą metodą ochrony procesora przed atakami DoS na usługę SNMP. Pakiety pochodzące z adresów innych niż zdefiniowane w ACL są natychmiast odrzucane na poziomie układów ASIC przełącznika.
Włączenie komendy `logging host 10.99.0.10` z poziomem `warnings` sprawia, że zdarzenia takie jak zmiana stanu drzewa rozpinającego Spanning Tree czy wykrycie pętli kablowej są natychmiast rejestrowane w bazie LibreNMS i widoczne w dzienniku zdarzeń.
W systemach Linux usługa Net-SNMP domyślnie nasłuchuje na wszystkich interfejsach (`0.0.0.0`). Jeśli serwer posiada publiczny adres IP, otwiera to wektor ataku typu SNMP Amplification Attack (wzmocnienie ataku DDoS). Jawne wpisanie `agentaddress udp:10.99.0.20:161` całkowicie eliminuje to zagrożenie.
Wdrożenie SNMP v3 na serwerach Linux jest szczególnie istotne, ponieważ tablice MIB serwera ujawniają wrażliwe informacje o systemie: listę uruchomionych procesów (`hrSWRunTable`), strukturę partycji dyskowych oraz wersję zainstalowanego jądra Linux.
Strategia tworzenia kopii zapasowych wolumenów i procedura odzyskiwania awaryjnego (Disaster Recovery)
Cel slajdu: Opracowanie i przetestowanie procedury tworzenia kopii zapasowych wolumenów Dockera oraz odtworzenia serwera od zera po katastrofie.
Archiwizacja bazy, wolumenów RRD oraz scenariusz Disaster Recovery
Awaria serwera NMS nie może oznaczać utraty wielomiesięcznej historii pomiarowej; procedura DR musi umożliwiać postawienie nowego serwera w kilkanaście minut.
Zrzut bazy MariaDB (mysqldump): Wykonanie spójnego zrzutu z poziomu kontenera: docker compose exec -T db mysqldump -u root -p... librenms > backup.sql
Kopia wolumenów RRD i konfiguracji: Archiwizacja katalogu ./rrd oraz plików compose.yml i .env do archiwum tar.gz z wysyłką na zewnętrzny serwer NAS
Scenariusz odtworzenia awaryjnego (DR): 1. Nowy serwer z zainstalowanym Dockerem; 2. Sklonowanie plików konfiguracyjnych; 3. Rozpakowanie wolumenów RRD; 4. Import bazy SQL
Czas powrotu do sprawności (RTO): Odtworzenie pełnego środowiska kontenerowego z kopii zapasowej zajmuje poniżej 15 minut (Recovery Time Objective)
RTO (Recovery Time Objective): Maksymalny dopuszczalny czas, w jakim system informatyczny musi zostać w pełni przywrócony do działania po wystąpieniu awarii.
Wykonywanie testów z poziomu systemu operacyjnego hosta może prowadzić do fałszywych wniosków. Jeżeli host ma bezpośredni dostęp do sieci zarządzającej, a kontener działa w odizolowanym mostku bez odpowiedniej trasy, ping z hosta zadziała, a z kontenera poller zakończy się błędem. Dlatego wszystkie polecenia sprawdzające muszą być wywoływane przez `docker compose exec librenms <polecenie>`.
W środowiskach korporacyjnych procedurę testową warto zautomatyzować za pomocą prostego skryptu bash lub zadania CI/CD, które po każdej aktualizacji obrazów automatycznie weryfikuje status kodu wyjścia (exit code 0) poszczególnych testów syntetycznych.
Sekwencja poleceń w procedurze odtworzeniowej na nowym serwerze: 1. git clone https://github.com/librenms/docker.git /opt/librenms-docker && cd /opt/librenms-docker/examples/compose 2. Przywrócenie pliku .env z bezpiecznego magazynu (posiadającego identyczny APP_KEY). 3. docker compose up -d db redis 4. docker compose exec -T db sh -c 'exec mariadb -u librenms -p"$MYSQL_PASSWORD" librenms' < /opt/backups/librenms_db.sql 5. docker compose up -d 6. docker compose exec librenms ./validate.php
Dzięki kontenerom inżynier sieciowy nie musi ręcznie instalować interpretera PHP, rozszerzeń PECL, serwera Nginx czy kompilować RRDtool. Całe środowisko aplikacyjne jest hermetycznie zamknięte w pobieranych obrazach OCI.
Po odtworzeniu bazy i plików RRD studenci logują się do panelu Web UI i weryfikują, czy historia wykresów interfejsów sprzed 'katastrofy' została w pełni zachowana bez przerw czasowych.
W środowiskach produkcyjnych skrypt wykonujący takie ćwiczenie powinien być uruchamiany okresowo na maszynie zapasowej (staging/DR), aby potwierdzić poprawność automatycznie generowanych backupów.
Konteneryzacja nowoczesnej telemetrii: Prometheus, snmp_exporter i Grafana
Cel slajdu: Przedstawienie wdrożenia alternatywnego stosu telemetrycznego Prometheus/Grafana w kontenerach Docker Compose.
Równoległy stos telemetryczny nowej generacji w Compose
W nowoczesnych organizacjach LibreNMS jest często uzupełniany przez stos Prometheus + Grafana, realizujący ultraszybką telemetrię łączy szkieletowych.
Usługa snmp_exporter w kontenerze: Obraz prom/snmp-exporter; plik konfiguracyjny snmp.yml z wygenerowanymi profilami OID dla przełączników
Konfiguracja Prometheus (prometheus.yml): Definicja zadania (scrape_job) odpytującego eksporter z interwałem np. scrape_interval: 15s
Wizualizacja w Grafana: Kontener grafana/grafana; automatyczne podłączenie źródła danych Prometheus przez mechanizm Provisioning
Synergia rozwiązań: LibreNMS odpowiada za inwentaryzację, topologię i logi Syslog, a Prometheus/Grafana za wyświetlanie pulpitów operacyjnych wysokiej częstotliwości
Scraping (Prometheus): Proces cyklicznego pobierania metryk przez serwer Prometheus poprzez wysyłanie zapytań HTTP GET do zdefiniowanych eksporterów.
W przeciwieństwie do LibreNMS, który przechowuje metryki w plikach RRD o stałym rozmiarze na urządzenie, Prometheus składuje wszystkie szeregi czasowe w wydajnych blokach 2-godzinnych na dysku z kompresją algorytmem Gorilla. Umożliwia to wykonywanie zaawansowanych korelacji matematycznych (np. pochodne, estymacje wysycenia łącza za 3 dni komendą `predict_linear()`).
Uruchomienie takiego stosu w Docker Compose wymaga zaledwie kilkunastolinijkowego pliku `docker-compose.yml` oraz zamontowania dwóch plików konfiguracyjnych: `prometheus.yml` oraz `snmp.yml`.
Plik `snmp.yml` rzadko jest tworzony ręcznie. Generator eksportera (`snmp_exporter/generator`) kompiluje pliki MIB dostarczone przez producenta sprzętu (np. Cisco, Juniper, MikroTik) do zoptymalizowanego formatu YAML. Kontener generatora przetwarza pliki tekstowe MIB i automatycznie rozwiązuje zależności OID.
Przykładowe wywołanie diagnostyczne za pomocą narzędzia curl bezpośrednio z hosta: curl -s "http://localhost:9116/snmp?target=10.99.0.1&module=if_mib" | grep ifHCInOctets pozwala natychmiast podejrzeć wygenerowane metryki bez uruchamiania bazy Prometheus.
Kluczowe jest wcześniejsze utworzenie pliku `prometheus.yml` przed wywołaniem `docker compose up -d`. Jeśli plik montowany w sekcji `volumes:` nie istnieje na hoście, silnik Dockera automatycznie utworzy pusty katalog o tej nazwie, co uniemożliwi uruchomienie Prometheusa z błędem typu 'not a directory'.
W przeciwieństwie do tradycyjnych systemów NMS, Grafana pozwala na import gotowych szablonów dashboardów z repozytorium społeczności (np. oficjalny dashboard SNMP Switch Dashboard o ID 12411).
Po zaimportowaniu szablonu student otrzymuje w pełni interaktywny panel prezentujący status wszystkich portów, utylizację pasma, błędy CRC oraz obciążenie procesora przełącznika.
Źródło prawdy (NetBox w Dockerze) oraz automatyzacja wdrożeń z narzędziem Ansible
Cel slajdu: Wdrożenie systemu NetBox w środowisku kontenerowym oraz automatyzacja instalacji stosu NMS za pomocą skryptów Ansible Playbook.
Infrastructure as Code: automatyzacja rozruchu i inwentaryzacji
Zastosowanie narzędzi Infrastructure as Code (IaC) pozwala na w pełni zautomatyzowane wdrażanie identycznych instancji monitoringu na wielu węzłach brzegowych.
NetBox Docker: Gotowy stos Docker Compose dla NetBox (aplikacja Django, baza PostgreSQL, kolejki Redis); centralna baza adresacji IPAM i zasobów DCIM
Automatyzacja z Ansible: Playbook instalujący silnik Docker, klonujący repozytorium z plikami Compose, generujący plik .env i uruchamiający stos
Dynamic Inventory: Ansible pobiera listę urządzeń sieciowych bezpośrednio z API NetBox i automatycznie konfiguruje ich odpytywanie w LibreNMS
Standaryzacja środowisk: Całkowita eliminacja ręcznej konfiguracji 'klikanej'; cała infrastruktura monitoringu opisana w kodzie w repozytorium Git
Infrastructure as Code (IaC): Podejście inżynierskie polegające na zarządzaniu infrastrukturą teleinformatyczną za pomocą plików definicyjnych podlegających kontroli wersji.
Wdrożenie NetBoksa w Dockerze realizuje się poprzez sklonowanie oficjalnego repozytorium: git clone -b release https://github.com/netbox-community/netbox-docker.git Po skonfigurowaniu pliku środowiskowego i uruchomieniu komendy `docker compose up -d`, NetBox automatycznie wykonuje migracje schematu PostgreSQL i udostępnia interfejs REST API oraz GraphQL.
Integracja NetBox z LibreNMS eliminuje problem zapomnianych urządzeń: nowe urządzenia wpięte do sieci są natychmiast objęte monitoringiem bez udziału człowieka.
Zastosowanie Ansible w połączeniu z Dockerem stanowi fundament podejścia NetDevOps. Zmiana wersji LibreNMS polega na podbiciu tagu obrazu w repozytorium Git, po czym potok CI/CD uruchamia playbook Ansible aktualizujący serwery monitorujące.
Dzięki Ansible wdrożenie nowego serwera NMS w nowej lokalizacji (np. w oddziale firmy) sprowadza się do dopisania adresu IP do inwentarza i wykonania polecenia: ansible-playbook -i inventory.ini deploy_nms.yml --ask-vault-pass
Diagnostyka problemów (Troubleshooting) i zbiór dobrych praktyk eksploatacji
Cel slajdu: Poznanie najczęstszych problemów występujących w skonteneryzowanych systemach NMS oraz sprawdzonych zasad ich eksploatacji.
Metodyka usuwania usterek w kontenerach i złote zasady
Zarządzanie NMS w kontenerach wymaga opanowania specyficznych metod diagnostycznych łączących analizę warstwy sieciowej, bazodanowej i uprawnień Dockera.
Problem uprawnień do wolumenów: Niezgodność identyfikatorów UID/GID (np. błąd zapisu do katalogu rrd); rozwiązanie: chown -R 1000:1000 ./rrd
Restart w pętli (CrashLoopBackOff): Inspekcja logów kontenera bazy danych (docker compose logs db); najczęstsza przyczyna: brak pamięci RAM (OOM Killer)
Limitowanie zasobów w compose.yml: Wymóg definiowania limitów pamięci (mem_limit) i procesora (cpus) zapobiegający zawieszeniu serwera gospodarza
Automatyczna rotacja logów Dockera: Konfiguracja sterownika json-file z opcjami max-size: "50m" i max-file: "3" chroni dysk przed zapełnieniem
OOM Killer (Out of Memory Killer): Mechanizm jądra Linuksa bezwzględnie uśmiercający proces zużywający najwięcej pamięci w sytuacji krytycznego wyczerpania pamięci RAM.
Wzorcowa konfiguracja rotacji logów w pliku `/etc/docker/daemon.json`:
Po zapisaniu pliku należy zrestartować demona poleceniem `sudo systemctl restart docker`.
W przypadku awarii zapisu do bazy RRD najczęstszym błędem jest brak uprawnień do zapisu po ręcznym rozpakowaniu archiwum kopii zapasowej pod kontem root. Polecenie naprawcze: sudo chown -R 1000:1000 /opt/nms-librenms/data natychmiast przywraca sprawność.
W systemach produkcyjnych każdy kontener powinien posiadać zdefiniowaną politykę restartu `restart: unless-stopped`. Zapobiega to sytuacji, w której po restarcie serwera fizycznego (np. po aktualizacji jądra Linux) system monitorowania sieci nie wstanie automatycznie.
Wskazane jest również wdrożenie automatycznych narzędzi do aktualizacji obrazów (np. Watchtower w trybie powiadamiania) lub dedykowanych potoków Ansible sprawdzających dostępność nowych wydań bezpieczeństwa obrazów bazowych.
Połączenie narzędzia Containerlab ze skonteneryzowanym stosem LibreNMS lub Prometheus pozwala studentom i inżynierom na symulowanie awarii fizycznych portów (np. odcięcie wirtualnego łącza) i obserwowanie w czasie rzeczywistym zachowania alertów NMS.
Podejście to całkowicie eliminuje ryzyko wdrożenia błędnej konfiguracji monitorowania na środowisku produkcyjnym, realizując ideę 'Shift-Left Testing' w inżynierii sieciowej.
Słownik terminów konteneryzacji, pytania kontrolne i literatura
Cel slajdu: Podsumowanie modułu piątego, usystematyzowanie pojęć konteneryzacji oraz weryfikacja wiedzy poprzez pytania i zadania wdrożeniowe.
Leksykon pojęciowy modułu 5 i weryfikacja kompetencji
Zakończenie modułu konteneryzacji; student powinien potrafić samodzielnie uruchomić, skonfigurować, zabezpieczyć i zaktualizować wielousługowy stos NMS w środowisku Docker Compose.
Pytania teoretyczne: 1. Czym różni się wirtualizacja sprzętowa (VM) od konteneryzacji procesów (Docker)? 2. Dlaczego wolumeny nazwane są niezbędne w stosie NMS? 3. Jakie ryzyko niesie brak limitów pamięci dla kontenerów?
Zadania laboratoryjne: 1. Uruchom oficjalny stos LibreNMS w Docker Compose; 2. Sprawdź obciążenie kontenerów poleceniem docker stats; 3. Wykonaj kopię bazy danych z poziomu CLI
Kompetencje modułu 5: Praktyczna biegłość we wdrażaniu, administrowaniu, skalowaniu i tworzeniu kopii zapasowych skonteneryzowanych platform telemetrii sieciowej.
Biegła znajomość tych pojęć jest niezbędna podczas egzaminów zawodowych, rozmów rekrutacyjnych na stanowiska Network/NOC Engineer, DevOps oraz Cloud Administrator.
Warto zwrócić uwagę na przejście od tradycyjnego podziału ról (administrator sieci vs administrator systemów) do zintegrowanego modelu inżynierii sieciowej (NetDevOps).
Pytania te stanowią doskonałą bazę do dyskusji seminaryjnej lub kolokwium zaliczeniowego z przedmiotu Administracja i Monitorowanie Sieci Komputerowych.
Warto zachęcić studentów do samodzielnego przetestowania w laboratorium zachowania systemu przy sztucznym wywołaniu wycieku pamięci lub zablokowaniu portu Redis.