Czym jest projekt “Arvalis”?

Pod nazwą “Arvalis” kryje się w rzeczywistości hosting własnej instancji oprogramowania Zabbix w celu monitorowania domowych homelabów. Mówię o liczbie mnogiej, ponieważ w projekt zaangażowanych jest kilka osób, a instancja Zabbix jest współdzielona. Projekt też wykorzystuje wiele praktyk i czynności kojarzonych raczej z infrastrukturami produkcyjnymi, a nie domowymi, jednakże zostały one wybrane, aby ułatwić deployment i utrzymanie. O projekcie więcej dowiecie się z tego wpisu.

Co się zmieniło?

Od października zaszło kilka zmian, choć nie staraliśmy się poświęcać zbyt sporo czasu.

Jest nas więcej!

Już publikując poprzedni wpis informowałem, że liczba osób uczestniczących w projekcie wzrosła do 5. W tym momencie jest nas aż sześciu, co sprawiło, że koszt miesięczny za styczeń 2026 wyszedł około 6 złotych za osobę. Jak za enterprise-level monitoring jest to naprawdę świetna cena.

Niestety, Hetzner poinformował, że jest zmuszony podnieść ceny i dotyka to również nas. W celu zminimalizowania kosztów postanowiliśmy więc w końcu przejść na nowy typ instancji CX23. Pierwotnie infrastruktura została zbudowana na bazie CX22, czyli najtańszego wariantu instancji EC2 od Hetzner. Jednak nieco później udostępniono nowe typy, gdzie CX22 zastępuje właśnie nieco tańszy CX23, a CX22 szybciutko został oznaczony jako deprecated. I tak, faktycznie nowy CX23 jest tańszy od CX22, jednakże, tak jak wspomniałem, Hetzner ogólnie podniósł ceny swoich usług i nawet ten nowy typ instancji stał się droższy. Nadal jednak są to koszty rozsądne, tym bardziej, że dzielone na parę osób.

Problem zmiennego IP

Największym problemem był onboardowanie osób ze zmiennym adresem IP. Jako że podstawą kontroli dostępów jest mechanizm whitelistowania adresów IP, to publiczny, wyjściowy adres danego użytkownika musi być znany (dotyczy to również podwójnego NAT-u, w naszej konfiguracji korzystamy z Zabbix Proxy w trybie Active, a więc otwieranie się na ruch wchodzący po stronie userów jest zbędne). Niestety, u niektórych z nas był to spory problem, bo czasami adres mógł się zmieniać nawet co kilka dni.

Udało się to jednak rozwiązać wykorzystując fakt, że już infrastruktura była opisana w kodzie. Dodaliśmy więc selfhostowany worker Forgejo i utworzyliśmy workflow, gdzie odpowiedni event informuje o zmianie adresu IP i uruchamia automatyzację, która aplikuje nową definicję infrastruktury. Aby to działało sprawniej musieliśmy też przerobić moduły związane z firewallem… i to dwa razy. Najlepszym rozwiązaniem było utworzenie oddzielnej security grupy (oj, firewalli…) dla każdego usera, ale okazało się, że Hetzner narzuca niezmienny limit, gdzie jedna instancja może mieć maksymalnie 5 security grup. Przearanżowaliśmy więc SG ponownie i uzyskaliśmy potrzebny efekt.

Rozwój IaC

Poszliśmy dalej z architekturą rozwiązania. Przerobiliśmy jak zarządzamy użytkownikami po stronie serwerów, a definicję kontenerów wrzuciliśmy do oddzielnego stacka. Udało się też opisać infrastrukturę Cloudflare w kodzie, co jest kolejnym, ważnym krokiem. Gdzieś po drodze zmodyfikowaliśmy konfigurację Zabbixa, aby wyciągnąć wyższą wydajność, a także staramy się regularnie robić aktualizacje minor. Poza wyżej opisanym workflow dla zmiennego IP, dodaliśmy też inne automatyzacje, stricte związane z OpenTofu.

Podsumowanie

Arvalis, mimo wszystko, to projekt hobbystyczny, a więc rozwój jest powolny, bo bazuje tylko i wyłącznie na wolnym czasie użytkowników. A jednak udało się wprowadzić trochę zmian i ciągle trwają prace nad usprawnieniami. Mamy backlog wypełniony kolejnymi działaniami, większymi i mniejszymi. No i oczywiście czekamy na Zabbix 8.0, który wniesie sporo nowości.

Zabbix jako narzędzie do monitoringu homelaba podoba mi się coraz bardziej i bardzo lubię z niego korzystać, a jego konstrukcja oparta o Server i Proxy niesamowicie dobrze sprawdza się w tym użyciu. Niewielkim kosztem mamy dostęp do monitoringu klasy enterprise, a jeśli tylko sobie ktoś z nas wymarzy jakiś monitoring czy sposób działania, to zapewne będzie mógł to zrobić. Fajnie by było, jakby Zabbix dostał choć trochę lepszy interfejs GUI i najlepiej oficjalnego providera Terraform…

Zaraz na samym początku korzystania z Zabbixa w chmurze Hetzner przygotowaliśmy skrypt, którym można było łatwo definiować strony internetowe, które następnie były monitorowane poprzez Web Scenarios. Skrypt szybko dodawał monitoring i zakładał odpowiednie triggery i inne elementy bez potrzeby ręcznego klikania. Troszkę taki wyszedł z tego pseudo Terraform, ale w Pythonie. Skrypt nie jest kompletny, nie jest idealny, ale zrobił to co trzeba, czyli po prostu dodał ten monitoring, który skutecznie zastąpił Uptime Kuma.

Sposób tworzenia tego monitoringu i alarmu bardzo mi się spodobał. Finalnym elementem dla użytkownika było w zasadzie wpisanie adresu strony i ważności monitorowania w JSON-ie, a następnie odpalenie skryptu. Pomyślałem, że coś takiego można byłoby dodać do innych rzeczy, a dobrym testem byłoby przerobienie skryptu na monitoring ważności apteczek samochodowych.

Dodawanie pozycji do apteczki

Utworzenie nowego skryptu jednak nie było tak proste. Fakt, można utworzyć pozycje i ustawić daty ważności w Zabbix, ale nie ustawimy odmierzania czasu. Tak, Zabbix sam z siebie czasu nie odmierza, a więc nie możemy ustawić, że np. odliczamy do 31 grudnia 2025, a Zabbix sam z siebie będzie odejmował z puli kolejne godziny. Niestety, tutaj potrzebny jest jakiś zewnętrzny bodziec, który ten czas odliczy i prześle wartości do serwera.

Ale od początku. Pierwszy skrypt dodaje nowe rzeczy do apteczki i ustawia dla nich datę ważności. Każda pozycja w apteczce to osobny item w Zabbix. Skrypt automatycznie tworzy też triggery – w moim przypadku są trzy alarmy dla każdego przedmiotu: pierwszy 30 dni przed końcem ważności, drugi na 14 dni, a trzeci na 7 dni przed przeterminowaniem.

Dzięki temu mam czas na spokojne zakupienie nowych produktów i wymianę tych, które wkrótce stracą ważność.

Odświeżanie danych

Tutaj pojawia się wcześniej wspomniana kwestia techniczna. Zabbix sam w sobie nie odmierza czasu dla pozycji. Jeśli mam item z datą ważności na “2025-12-31”, to Zabbix nie będzie sam sprawdzał, ile dni zostało. Potrzebny jest “zewnętrzny bodziec”, który zaktualizuje wartość i zmusi Zabbix do ponownego sprawdzenia triggerów.

Dlatego powstał drugi skrypt, który uruchamiam jako cronjob co 12 godzin w Forgejo Actions. Skrypt odpytuje Zabbix API, pobiera wszystkie pozycje związane z apteczkami i aktualizuje ich wartości.

Praca w praktyce

Kiedy zbliża się termin ważności jakiegoś produktu, dostaję powiadomienie na Telegram, tak samo jak w przypadku alertów z infrastruktury IT. Wszystko scentralizowane w jednym miejscu, więc nie muszę pamiętać, która apteczka była ostatnio sprawdzana ani co w niej się znajduje.

Ograniczenia

Największy problem to brak automatycznego usuwania pozycji. Jeśli jakiś przedmiot znika z apteczki, to muszę ręcznie usunąć go z Zabbixa. Przydałoby się, żeby skrypt porównywał aktualny stan inventory w kodzie z tym, co jest w Zabbix i sam usuwał nieaktualne pozycje. Te wszelkie problemy rozwiązałby Terraform, ale niestety, provider do Zabbixa jest przestarzały i już nie działa. Innym sposobem byłoby skorzystanie z Ansible, ale niestety, nie badałem czy jeszcze Ansible działa.

Co dalej

Myślę, aby ponownie wykorzystać ten zestaw narzędzi do podobnych rzeczy. Monitoring terminu ważności to przecież uniwersalny problem - leki w domowej apteczce, produkty spożywcze w spiżarni, przeglądy techniczne samochodu, ważność dokumentów czy subskrypcje oprogramowania. Wszystko to mogłoby być monitorowane tym samym mechanizmem.

Przydałoby się jednak usuwanie danych pozycji, kiedy te znikną z inventory w kodzie. Wymaga to refaktoringu i lepszego zaprojektowania struktury danych, ale z czasem do tego wrócę.

Na początku dodam, że choć niezbyt lubię to słowo, tak w tym wpisie będę stosował słowo “homelab” w celu nazwania domowego serwera opartego o sprzęt konsumpcyjny.

Początki monitorowania mojego homelaba

Kiedy to zacząłem bawić się w selfhosting, to nie przykładałem żadnej uwagi monitorowaniu. Nic dziwnego, początki to właśnie faza na szukanie coraz to ciekawszych aplikacji, wszak otworzył się przede mną kompletnie nowy katalog oprogramowania, którego nigdy wcześniej nie eksplorowałem. Początki monitoringu więc sięgają dopiero instalacji Home Assistanta, na którego skusiłem się po około 6 miesiącach zabawy. W Home Assistant monitorowałem zużycie energii przez serwer, a także dodałem (co jest w Home Assistant bardzo proste) zbieranie takich metryk jak użycie CPU, RAM, zajętość dysków itd. Nie miałem żadnych alertów, więc zdany byłem tylko i wyłącznie na to, że jak zauważyłem, że coś działa nie tak, to wchodziłem i sprawdzałem metryki.

Uptime Kuma

Pierwszym takim oprogramowaniem, które faktycznie pełniło rolę źródła informowania o problemach była aplikacja Uptime Kuma, która jest w zasadzie silnikiem dla healtchecków, tudzież sprawdza czy strona pod danym adresem “żyje”/odpowiada kodem 200. Jeśli nie, to wysyłany jest alert, w moim przypadku na Telegrama. Po drodze uznałem, że posiadanie tego programu na tym samym serwerze, który monitoruję jest bez sensu, więc przeniosłem go na zewnątrz, na “VPS-a” od dostawcy Mikrus. Później dodałem kolejną instancję Uptime Kuma, która monitorowała ten serwer VPS i tym samym obydwie Kumy sprawdzały siebie. Z takiego rozwiązania korzystałem do niedawna.

W tak zwanym międzyczasie zacząłem swoją pracę zawodową na pozycji SysOps. Dla osoby zajmującej to stanowisko monitoring i support to główne “dania” i zajawki. Szybko poznałem kilka rozwiązań do monitorowania, w tym właśnie Zabbix czy Amazon CloudWatch. To mnie też skłoniło do uznania, że monitoring moich usług jest po prostu słaby, nieistniejący, choć - muszę przyznać - Uptime Kuma to dobry początek. Dlatego też po jakimś czasie znalazłem bardzo świeże na tamten moment rozwiązanie o nazwie Beszel.

Beszel

Beszel pozostaje oprogramowaniem, które do dzisiaj jestem w stanie polecić. Jest ono stale ulepszane i dodawane są kolejne ważne funkcje dlatego warto je mieć na uwadze. A co robi Beszel? Zapewnia funkcje monitorowania podstawowych pozycji (pozycje to oficjalne tłumaczenie słowa items w Zabbix) takich jak użycie CPU, RAM, zajętość dysków, ale też monitoring użycia zasobów przez kontenery Docker. Jako administrator można ustawić progi alertowania. No właśnie, alertowania, bo można też wysyłać alarmy z użyciem wybranego sposobu, ja zdecydowałem się na bota Telegram.

Beszel nieco przypomina Zabbixa, bowiem mamy tutaj oprogramowanie serwer+frontend (jako monolit), które deployujemy gdzieś i mamy także agentów, które instalujemy na sprzętach, które mają być monitorowane. Instalacja agenta może odbyć się zarówno z użyciem Dockera, jak i natywnej instalacji (skryptem). Z Beszela korzystałem całkiem długo i w zasadzie potrafi on być wystarczający dla wielu entuzjastów selfhostingu, a nawet myślę, że sprawdziłby się w mniejszych firmach. Zarówno agent, jak i oprogramowanie serwer+frontend jest niezwykle lekkie i szybkie - ja to drugie utrzymywałem z powodzeniem na Mikrus Frog. Dlatego do dzisiaj Beszela potrafię polecać.

Ale zaczęło mi brakować większej liczby funkcji. Zwłaszcza monitorowania innych sprzętów, chociażby routera, ale też jakichś aplikacji, np. RabbitMQ. Beszel Agent nie działał też na każdym sprzęcie, na przykład nie mogłem z powodzeniem uruchomić go na Orange Pi Zero 2. Co więcej, chciałem rozpocząć monitoring SMART dysków, które mam w RAID1. Myślałem o jakichś skryptach Bash i powiadomieniach, ale uznałem, że to bez sensu – wszystko powinno być scentralizowane. Czarę goryczy przelała sama Uptime Kuma, która zaczęła generować fałszywe alarmy, a także miewała problemy, które były oznaczone jak wontfix na Githubie. I nie, przesiadka na Uptime Kuma v2 nic nie dała. Finalnie też chciałem zdobywać ekspercką wiedzę w oprogramowaniu poziomu enterprise, a Zabbix bardzo mi się spodobał, bo zacząłem poświęcać mu całkiem dużo czasu w pracy. Co więcej, rozpocząłem proces certyfikacji i na moment pisania tego artykułu mam certyfikat Zabbix Certified User 7.0 oraz nabyłem książkę polskiego autora Mateusza Dampca pod tytułem “Zabbix 7.0. Efektywny monitoring infrastruktury IT dla każdego”, która bardzo mi się spodobała, ale potrzebowałem miejsca, gdzie będę mógł testować nowe rozwiązania.

Początki Zabbixa w moim domu

Po tym, jak ułożyłem sobie potrzeby wobec monitoringu, nieco lepiej poznałem Zabbixa, a także zapoznałem się z częścią książki “Zabbix 7.0. Efektywny monitoring infrastruktury IT dla każdego” uznałem, że Zabbix faktycznie będzie najlepszym wyjściem. Postanowiłem jednak zrobić sobie pewnego rodzaju dry-run i zdeployowałem Zabbixa u siebie w domu, na komputerze Mini PC z Proxmoxem. Wykorzystałem do tego OpenTofu oraz przygotowałem sobie skrypt Cloud Init. Do tego uznałem, że najlepszym wyborem jest architektura z dwoma maszynami wirtualnymi, gdzie jedna hostuje zarówno Zabbix-Frontend (czyli moduł odpowiedzialny za GUI) oraz Zabbix-Server (czyli serce tego systemu). Natomiast na drugiej maszynie wirtualnej zainstalowałem MariaDB jako bazę danych dla Zabbixa. Dodam, że obydwie aplikacje Zabbixa zainstalowałem z użyciem Dockera, natomiast bazę danych natywnie, za pomocą wbudowanego w Debiana menedżera pakietów.

Na różnych maszynach doinstalowałem agentów, skonfigurowałem media do wysyłania alarmów i… zaczęło mi się to podobać – tym bardziej, że do świata monitoringu dołączył kolejny mój sprzęt, czyli router ASUS AX-53U z OpenWrt – pakiet zabbix-agent tak sobie czekał w repozytorium na zainstalowanie i skonfigurowanie. Do tego zacząłem szukać różnych templatek i innych rzeczy do monitorowania. Tak zacząłem dodawać monitoring kontenerów Docker dzięki zabbix-agent2 i wtyczce Docker, monitoring Home Assistanta z użyciem niestandardowej templatki czy brokera MQTT RabbitMQ. Wiem też, że mam sporo innych rzeczy, które mogę łatwo wchłonąć do monitoringu, ale nie miałem za bardzo czasu, aby do tego przysiąść. Nie miałem czasu, bo zacząłem myśleć nad produkcyjną wersją tego monitoringu.

Przygotowania do wypuszczenia Zabbixa w świat

Dalej wiedziałem, że monitoring powinien żyć poza moim domem, a więc musiał być zdeployowany w jakiejś chmurze, ale nie mógł być to Mikrus, ponieważ nie sprawdziłby się – w dłuższej perspektywie jest trudny w utrzymaniu i nie oferuje personalnego adresu IP. Mikrus ma sporo ciekawych funkcji potrzebnych i ułatwiających życie z perspektywy osoby wchodzącej w ten świat, ale ja już potrzebowałem czegoś innego. Szybko zdecydowałem więc, że najlepszym wyjściem będzie deployment w chmurze Hetzner. Nie będę kłamał, wielkim fanem tej usługi nie jestem, ale akurat w tym przypadku spełniała większość wymogów, przede wszystkim instancje EC2 można deployować za pomocą Terraforma oraz płaci się w formie Pay as you Go, a nie w abonamencie. Ponadto, nawet najniższy typ instancji EC2 jest naprawdę wydajny i spełniający wymogi, a cena za nią jest wręcz bajeczna. CX22, bo taki typ wybrałem (aktualnie zastąpiony przez jeszcze tańszy typ CX23) kosztuje lekko ponad 4 Euro z polskim VAT-em i za taki hajs oferuje 4 GB RAM i 2 rdzenie vCPU.

Koszt dwóch instancji i jednego publicznego adresu IP nie byłby wysoki, jednakże chciałem ten koszt obniżyć, a także zachować podejście projektowe, gdzie kilka osób pracuje nad utrzymaniem i rozwojem infrastruktury. Dlatego też do projektu zaprosiłem dwóch kolegów, którzy również posiadają domowe serwery. Długo namawiać ich nie musiałem, ponieważ obydwaj korzystali z Beszel i szybko zrozumieli zalety Zabbixa. To podzieliło koszty na trzech. Finalnie jednak, na moment pisania tego artykułu, w skład projektu wchodzi już 5 osób.

Deployment w chmurze Hetzner

Przejdźmy więc do głównego dania. Hetzner nie daje ogromnych możliwości w projektowaniu rozwiązań chmurowych – liczba usług jest mała, a opcje modyfikacji tych istniejących są po prostu niewielkie. Przykładowo, byłem gotowy zacząć płacić nieco więcej zyskując zmniejszenie swojej odpowiedzialności i właśnie w tym mogłaby mi pomóc instancja silnika bazodanowego, coś w stylu RDS. Niestety, Hetzner czegoś takiego nie oferuje. Również myślałem nad skorzystaniem z Load Balancera, ale pricing za takowy w Hetzner nie jest dla mnie korzystny. Co więcej, chciałem też skorzystać z bucketów S3 (chociażby do trzymania pliku stanu Terraforma), ale, ponownie, pricing za buckety w Hetzner jest niekorzystny. Finalnie potrzebowałem też menedżera sekretów, którego w Hetzner po prostu nie ma.

Ale to też nie oznacza, że nie da się czegoś wymyślić. Dlatego też przyjąłem kilka zasad:

1. Architektura będzie powielona z dry-run, tudzież znowu postawię dwie instancje EC2, gdzie jedna będzie serwować frontend oraz serwer Zabbixa, a druga bazę danych (MariaDB).
2. Tylko instancja z serwerem będzie dostępna bezpośrednio dla użytkowników.
3. Skorzystam z usługi Networks w Hetzner, aby umieścić obydwie instancje w sieci prywatnej.
4. Skorzystam z firewalla dostępnego w Hetzner.
5. Kod IaC będzie zawierał jak najwięcej możliwie ustawień, ale bez zapisanych sekretów czystym tekstem.
6. Skorzystam z funkcji backupów w Hetzner.

Musiałem więc przeskoczyć niektóre z braków Hetznera. Brak usługi RDS zastąpiłem po prostu drugą instancją EC2. Brak menedżera sekretów nadrobiłem usługą Secret Manager w BitWarden, natomiast bucket S3 zapewniła mi chmura Scaleway, z którą już miałem do czynienia. Firewall pozostał w Hetzner, ale zarządzanie domeną (tak jak planowałem od samego początku) przeniosłem do Cloudflare. Zapytacie więc jak zarządzać tym chaosem korzystania z wielu usług? Normalnie byłby to koszmar, ale mając jeden interfejs do tego wszystkiego nie jest tak ciężko. A właśnie takim interfejsem jest Terraform, choć w rzeczywistości to jego fork o lepszej licencji, czyli OpenTofu. Mając OpenTofu tak naprawdę nie ma dla mnie znaczenia gdzie spoczywają sekrety, gdzie zapisany jest plik stanu Terraforma czy inne elementy, bo w kodzie to niemalże wszystko to samo. Niejako widać to na listingu poniżej.

module "zabbix_database" {
  source = "../../Modules/hetzner_server_instance" #moduły są wersjonowane tagami w git, ta linia jest zamiennikiem na potrzeby artykułu

  name     = local.instance.database_server.name
  location = local.hetzner.location
  type     = local.instance.type
  image    = local.instance.image
  backups = true

  networking = {
    ipv4_enabled = false
    ipv6_enabled = true
  }
  private_network = {
    network_id = module.arvalis_network.id
    alias_ips  = []
  }

  cloud_init = {
    config = join("\n", [
      templatefile("${path.module}/files/cloud-init/users-init.yaml.tpl", {
        users = local.users_list
      }),
      templatefile("${path.module}/files/cloud-init/database-instance/cloud-init.yaml.tpl", {
        users                  = local.users_list
        hostname               = local.instance.database_server.name
        zabbixdb_user_password = sensitive(data.bitwarden_secret.zabbixdb_user_password.value)
      })
    ])
    gzip          = true
    base64_encode = true
  }

  labels = merge(
    local.common_tags,
    local.instance.database_server.tags,
    {
      name = local.instance.database_server.name
    }
  )
}

OpenTofu daje tak bardzo koherentne doświadczenie, że wiele elementów deploymentu w Proxmox mogłem po prostu skopiować do kodu infrastruktury Hetznera. Ważnym też dla mnie elementem była konfiguracja użytkowników. Ta zapisana jest w pliku user-data.yaml.tpl i to właśnie tam zdefiniowani są wszyscy użytkownicy wraz z publicznymi kluczami SSH. Plik ten jest częścią standardu Cloud init (często w chmurach chowającego się pod postacią skryptu User Data) i deployowany jest na obie instancje. Wspomniany Cloud Init używam również do wstępnej konfiguracji maszyn, np. instalacji Dockera czy instalacji MariaDB.

Wspomniane kontenery Docker również deployuję z poziomu OpenTofu, co umożliwia mój autorski moduł, który ma niejako udawać Docker Compose. Definicja wygląda tak:

module "zabbix_frontend_container" {
  source       = "git::ssh://git@codeberg.org/cichy1173/cichyform.git//Docker/docker_service?ref=docker_service_v1.0.0"
  service_name = "zabbix-web-nginx-mysql"
  image_name   = "zabbix/zabbix-web-nginx-mysql:alpine-7.0.21"

  volumes = []

  ports = [
    {
      internal = 8080
      external = 80
      protocol = "tcp"
    },
  ]

  environment_variables = [
    "DB_SERVER_HOST=${module.zabbix_database.ipv4_private_address}",
    "MYSQL_DATABASE=zabbix",
    "MYSQL_USER=zabbix",
    "ZBX_SERVER_HOST=${module.zabbix_server_frontend.ipv4_private_address}",
    "ZBX_SERVER_PORT=10051",
    "ZBX_SERVER_NAME=Arvalis Monitoring"
  ]
  depends_on = [module.zabbix_server_frontend, module.zabbix_database]
}

Praca z Zabbix zainstalowanym w Hetzner oraz koszty

Od samego początku infrastruktura zakładała skorzystanie z Zabbix Proxy w trybie Active. Dlaczego? Nie chciałem, aby każdy z nas w jakiś sposób otwierał port 10051 u siebie, tym bardziej, że niektórzy są za podwójnym NAT-em. Ponadto korzystanie z Zabbix Proxy Active jest mniej zasobożerne dla instancji Zabbixa.

A czym jest Zabbix Proxy? W skrócie, Proxy to taka usługa, która może zbierać metryki z różnych instancji w danej sieci, a następnie przesłać je do faktycznego Zabbix Serwera. No to czym więc jest tryb Active? Zabbix Proxy w trybie Active sam inicjuje połączenie do serwera, wysyła metryki do Zabbix-Server na port 10051, a ten w odpowiedzi przesyła konfigurację. W trybie Passive połączenie odbywa się w odwrotną stronę – Server inicjuje połączenie na port 10051 Proxy, a to w odpowiedzi zwraca metryki. W dosyć analogiczny sposób działa Zabbix Agent Passive/Active, ale agenci w tej historii nie są ważni.

No więc plan zakładał, że każdy sobie deployuje Zabbix Proxy w swojej sieci, gdziekolwiek tam sobie chce, jakkolwiek sobie chce, a następnie w trybie Active przesyła dane do Zabbix Server. Ponadto, dołożyliśmy szyfrowanie za pomocą certyfikatów TLS. Zadziałało to bardzo fajnie. Zabbix Server też prowadzi działania odpytujące, aczkolwiek bardziej w celu zastąpienia Uptime Kuma, bowiem Zabbix może robić dokładnie to samo dzięki Web Scenarios. Jednak aby sobie ułatwić proces dodawania i zarządzania monitoringiem Web, utworzyliśmy skrypt Python, który, wykorzystując bibliotekę Zabbix-Python-Utils, wrzuca nam monitoring stron internetowych zarówno z poziomu internetu, jak i w sieci lokalnej (dzięki monitoringu za pomocą Zabbix Proxy).

Tak jak wspomniałem, do projektu dołączyły kolejne osoby, co nie zamęczyło Zabbix Server. Użycie RAM wynosi około 50%, a CPU to użycie około 10-15%. Naprawdę niewiele i mamy spory margines mocy, aby wrzucać kolejne hosty do monitorowania, a nawet całe lokalizacje wraz z Zabbix Proxy Groups. Tak, z Proxy Groups też korzystamy i to naprawdę fajna funkcja.

A jak kilku użytkowników może korzystać z Zabbix? Wykorzystujemy funkcję Host Groups, gdzie każdy z nas ma swoją dedykowaną, imienną grupę hostów. Natomiast hosty do monitorowania są rozdzielone między użytkownikami właśnie z użyciem tych grup. Każdy użytkownik ma dostęp tylko do swojej grupy hostów i tym samym widzi metryki i alarmy związane tylko ze swoją grupą. Rozdzielenie logiczne jest nieco większe, ale sercem tego podziału są właśnie te grupy.

Co z kosztami? No jest lepiej niż myślałem. Musimy płacić za dwie instancje EC2, adres publiczny IPv4, bucket S3 (to są grosze) oraz za domenę (koszt jednorazowy, raz na rok). Finalnie miesięcznie koszt to 10-13 złotych za osobę. Jak za tak potężny monitoring jest to wręcz niewiele.

Podsumowanie

To nie koniec rozwoju projektu! Nadal musimy opracować wiele rozwiązań, które pomogą nam zarządzać usługą. Pierwszą rzeczą w tej kolejce jest wprowadzenie automatyzacji do obsługi zmiennego adresu IP. Chcę również dodać wykrywanie dryftów w kodzie infry (Forgejo Actions jest już gotowe, należy tylko je wdrożyć w repo), czy lepiej zautomatyzować patchowanie. Ale już na tym etapie uważam, że projekt działa fajnie. W żaden sposób nie jest skomplikowany, w zasadzie to niezwykle prosta architektura, ale z jakiegoś powodu nawet może być zadowalająca.

Jest taki żart brzmiący “It’s always DNS”, który wyjaśnia, że w razie jakichś problemów z dostępem do internetu, to zazwyczaj winnym jest DNS. I tak też bywa u mnie, ponieważ sam korzystam z alternatywnego DNS, aby móc blokować reklamy i inne nieprzyjemne połączenia. Wykorzystuję do tego oprogramowanie AdGuard Home, które spełnia podobną rolę jak Pi-Hole, ale AdGuard Home ma przewagę w postaci świetnie działającego providera do Terraform/OpenTofu. Dlatego też postanowiłem zmigrować konfigurację AdGuarda właśnie do OpenTofu. Wiedziałem jednak, że tylko jeden node z AdGuardem to nie jest najlepsze wyjście, a niedługo później miałem się o tym przekonać.

W tym artykule słowa “OpenTofu” i “Terraform” będę wykorzystywać naprzemiennie.

Problem jednego node’a DNS

Kiedy to poprawiałem zasilanie swojej “szafy”, to odpiąłem z prądu komputer, na którym to AdGuard Home był zainstalowany. Po chwili mój telefon przestał odtwarzać film na YouTube, który uruchomiłem sobie w tle, a Telegram przestał otrzymywać nowe wiadomości. Szybko zrozumiałem co się stało i postanowiłem rozwiązać przyszłe występowanie tego problemu tak, abym mógł bezproblemowo odpinać node’y z AdGuardem z zachowaniem pełnej funkcjonalności sieci.

Dlatego też zdecydowałem, że dołożę kolejne dwa urządzenia z instalacjami AdGuarda Home – jeden w sieci lokalnej, a drugi poza nią, w momencie pisania artykułu na serwerze Mikrus. Wszystkie te node’y (w sumie trzy) spiąłem za pomocą sieci Tailscale. Pozostał jednak problem zarządzania konfiguracją. Nawet jeśli teraz zaprę się i ręcznie poustawiam tak samo wszystkie te instalacje, to i tak w przyszłości każda jedna zmiana będzie bolączką. Całe szczęście, miałem już konfigurację zapisaną w kodzie Terraform/OpenTofu, a więc doszło mi tylko rozdystrybuowanie jej na więcej urządzeń.

Postanowiłem więc pozostać w świecie Terraforma. Wyzwaniem jednak był fakt, że dokładnie ten sam kod w tym samym repozytorium miał zacząć obsługiwać kilka równorzędnych sobie node’ów z oprogramowaniem AdGuard Home. To problem logiczny, którego do tej pory jeszcze nie spotkałem.

Dlaczego Terraform?

Idea IaC (Infrastructure as Code) jest mi bardzo bliska, głównie ze względu na pracę zawodową. Ideę tę postanowiłem też pielęgnować i rozwijać w ramach homelabu, jednakże w środowisku “domowym” zasobnik wykorzystywanych narzędzi jest znacznie inny. To jednak mnie nie zraziło i zacząłem rozwijać swój kod OpenTofu, najpierw dla maszyn wirtualnych w Proxmox (specjalnie dla OpenTofu zacząłem korzystać z Proxmoxa), a później właśnie dla AdGuard Home.

A dlaczego w ogóle wybrałem Terraforma/OpenTofu? Przyznam, że pisanie kodu właśnie w tym narzędziu/środowisku zaczęło mi dawać dużo zabawy i chęci eksploracji. W pracy miałem dużo okazji, aby zapoznać się z Terraformem i szybko uznałem, że idea i sposób działania świetnie odnajdzie się również w środowisku homelabowym.

Możliwe, że ktoś z Was korzysta z AdGuard Home zainstalowanego na wielu urządzeniach i wcale nie musiał rozwiązywać takich problemów, a przynamniej nie w taki sposób jak zrobiłem to ja. I to prawda, jest to możliwe, bowiem istnieje oprogramowanie adguardhome-sync, które właśnie pozwala na łatwe zarządzanie replikami Adguarda. Jednakże, jest to kolejny software, który trzeba instalować, ponadto nie jest on zgodny z ideą GitOps i, przede wszystkim, byłoby to pójście na skróty, a ja ten projekt chciałem wykorzystać do nauki.

GitOps i “Load Balancing”

Do nauki właśnie metodologii GitOps do zarządzania konfiguracją. Adguard Home to oprogramowanie całkiem proste, a przygotowany przeze mnie kod Terraform również nie należy do najbardziej zaawansowanych (wszystko na czystych resources, bez żadnych modułów). Dlatego też uznałem że mógłbym się trochę pobawić w automatyzacje i GitOps. Do tego od jakiegoś czasu korzystałem z codeberg.org (Forgejo), co też dawało mi okazję do pouczenia się Forgejo Actions i to na własnym (self-hosted) runnerze.

Musiałem jednak najpierw rozwiązać wcześniej wspomniane problemy. Wiedziałem, że do wszystkich node’ów powinien być tylko jeden config, tudzież jedno repozytorium z jednym katalogiem – to ograniczy potrzebę skakania po folderach. Jednak, aby działała dystrybucja konfiguracji, to muszę mieć wiele plików stanu (plik stanu w Terraform przechowuje aktualne odwzorowanie zasobów w infrastrukturze na definicje w kodzie, dzięki czemu Terraform wie, co istnieje i jakie zmiany trzeba wprowadzić). Dlatego też uznałem, że ścieżka do pliku stanu może być zmienną podawaną na wejściu komendy tofu apply (komenda, która najpierw wyświetla zmiany, które zostaną wdrożone, a następnie wdraża zmiany na prawdziwą architekturę). Wszelkie inne potrzebne wartości (jak adresy IP, loginy, hasła) również zacząłem zapodawać jako variables, które są podawane przy komendzie wdrożenia zmian. Całe szczęście już wcześniej plik stanu miałem przechowywany w miejscu zdalnym, a dokładnie w buckecie S3. To mi znacznie ułatwiło pracę.

tofu init -var="state_file_path=${{ secrets.STATEFILE_PATH_HOST1 }}"
tofu validate
tofu apply -auto-approve \
    -var="adguard_url=${{ secrets.ADGUARD_URL_HOST1 }}" \
    -var="adguard_username=${{ secrets.ADGUARD_USERNAME_HOST1 }}" \
    -var="adguard_password=${{ secrets.ADGUARD_PASSWORD_HOST1 }}" \
    -var="state_file_path=${{ secrets.STATEFILE_PATH_HOST1 }}"

Nie chciałem jednak trzy razy wpisywać tofu apply z różnymi zmiennymi. Wszak nie jest to zbyt wygodne i może sprawić, że zapomnę o którymś z node’ów, a przejście na Terragrunta nie wchodziło w grę. Dlatego też zacząłem pisać własny workflow dla Forgejo Actions. Nie było to trudne, bowiem Forgejo Actions to w rzeczywistości Github Actions, więc byłem już obyty ze składnią czy konceptami. Finalnie przygotowałem workflow, który wdraża zmiany po merge’u do głównej gałęzi. Workflow testuje kod, a następnie wdraża zmiany komendą tofu apply na wszystkich dostępnych node’ach. Przyznam jednak, że workflow wymaga aktualizacji, ponieważ działa na zbyt sztywnych komendach.

Postanowiłem jeszcze się nieco pobawić i przygotowałem kolejne workflowy. Wiedziałem, że odwiecznych problemem DevOpsów są drifty, czyli rozbieżności między kodem, a realną infrastrukturą. Dlatego też przygotowałem cronjoba, który regularnie sprawdza czy takowe drifty występują. Finalnie też przygotowałem workflow, który generuje plan zmian (tofu plan) na wskutek utworzenia nowego PR (zmiany są dodawane jako komentarz do PR).

A jak zacząć korzystać z tych wszystkich node’ów? To bardzo proste. W przypadku sieci lokalnej rozwiązanie było przewidywalne – wystarczy podać adresy obydwóch node’ów w ustawieniach DNS w routerze. Dla reszty urządzeń wykorzystałem Tailscale, gdzie podałem wszystkie trzy node’y jako adresy DNS. Co więcej, ustawiłem, że DNS Tailscale’a nadpisuje domyślny DNS na urządzeniach, gdzie Tailscale jest zainstalowany, dzięki czemu mam pewność, że mój Adguard Home jest w użyciu.

A może jakiś dashboard do tego?

Uznałem jednak, że fajnie byłoby wyciągać metryki ze wszystkich node’ów i je jakoś ładnie wizualizować. Tak się składa, że Adguard Home integruje się z Home Assistant. Wystarczyło dodać wszystkie trzy instalacje AGH do Home Assistanta i utworzyć widgety z wykresami, gdzie widziałbym połączone wyniki.

Utworzyłem sobie również automatyzację, które pozwala mi włączać i wyłączać blokowanie reklam na wszystkich node’ach jednocześnie. Wykorzystuję do tego właśnie automatyzację oraz pomocnik w postaci przełącznika, który jest w stanie ON, kiedy wszystkie node’y mają włączone blokowanie i w stanie OFF kiedy chociaż jeden z node’ów ma wyłączone blokowanie.

Kod tych rozwiązań udostępniłem w repozytorium. Dodam jednak, że wykresy wykorzystują zewnętrzny widget custom:mini-graph-card, który można zainstalować za pomocą HACS (Home Assistant Community Store).

Publikacja projektu AdGuard Home CM Repository

No właśnie, repozytorium. Tak się składa, że projekt postanowiłem opublikować. Nie jest on w żaden sposób zaawansowany, w zasadzie to naprawdę prosty kod i niezbyt rozbudowane automatyzacje. Jednakże projekt reprezentuje kilka ważnych dla mnie rzeczy.

1. Projekt może być zarówno dla mnie, jak i dla innych prototypem i wzorcem dla innych repozytoriów wdrażających GitOps w homelab.
2. Projekt pokazuje inne podejście do zarządzania i konfiguracji oprogramowania Adguard Home.
3. Projekt wykazuje, że Forgejo to nowoczesne oprogramowanie typu Forge, które sprawdzi się w środowisku domowym i biznesowym.
4. Projekt dokłada malutką cegiełkę do zjawiska migracji użytkowników z GitHuba na alternatywne rozwiązania Forge.
5. Projekt, wbrew pozorom, może przydać się wielu entuzjastom selfhostingu, a jednocześnie prezentuje rzadko wykorzystywane podejście w takim środowisku. Projekt tym samym może zachęcić do nauki Terraforma/OpenTofu i poznania Forgejo Actions.

Podsumowanie

Adguard Home CM Repository to projekt, z którego ciągle korzystam. Adguard spełnia u mnie kilka funkcji, jest blockerem reklam i złośliwych stron, tworzy proste przekierowania domen .local, a także wytworzył u mnie podstawy metodologii GitOps do homelaba. W połączeniu z Tailscale i właśnie Forgejo dostałem bardzo wygodne rozwiązanie, które potrafi sporo nauczyć i zabezpiecza mi bardzo ważny element sieci domowej, czyli właśnie DNS.

Mam za sobą 6 lat studiów na polskich uczelniach, kierunek: Informatyka. 5 lat na popularnej, publicznej uczelni, czyli Politechnice Lubelskiej (3,5 roku studiów inżynierskich + 1,5 roku studiów magisterskich) w trybie dziennym, stacjonarnym oraz rok studiów na uczelni prywatnej (poziom magisterski, specjalizacja “cyberbezpieczeństwo”) w trybie niestacjonarnym. Na tych studiach korzystałem z Linuxa, również gdy te przyjęły rolę zdalnych z powodu COVID.

Ten artykuł został przeze mnie udostępniony już kilka miesięcy temu, za pomocą aplikacji HedgeDoc. Udostępniam go jednak jeszcze raz tutaj, ale w nieco zmodyfikowanej, zaktualizowanej formie.

W tym artykule słowo “Linux” będę wykorzystywał zamiennie ze słowem “system operacyjny”. Pisząc więc “Linux” mam na myśli “System operacyjny typu Linux”. Nie będę natomiast wskazywał na konkretne dystrybucje Linux, z których korzystałem, bowiem jest to tak naprawdę wtórne.

tl;dr

Przejście całych studiów wykorzystując tylko system Linux jest możliwe, a nawet można uzyskać sporą przewagę nad innymi studentami niekorzystającymi z Linuxa, ale trzeba do tego OS-a podejść nieco chętniej, poznać go lepiej - mowa tu, przede wszystkim, o podstawach jego działania, korzystania z terminala i różnych menedżerów pakietów. Warto też dodać, że linuksowe GUI jest naprawdę dobre - sam uwielbiam GNOME - i zalety DE można fajnie wykorzystać w codziennej pracy (patrz: workspace’y, tiling i inne). GNOME służy mi do dzisiaj, nie tylko prywatnie, ale również i w pracy zawodowej.

Warto dodać, żę są osoby, które poszły z tematem o krok dalej i uznały, że będą korzystać tylko z oprogramowania FOSS -> https://www.gnu.org/education/how-i-fought-to-graduate-without-using-non-free-software.html

Politechnika Lubelska

Pierwsze 1,5 roku studiów

Pierwsze półtora roku studiów odbyło się w pełni stacjonarnie, wszak to jeszcze było przed pandemią. Na kierunku “Informatyka” pierwsze 3 semestry to czas nauki nie tylko tematów stricte komputerowych, ale też matematyki, fizyki i innych. Dlatego też ograniczę się do samych komputerów. Tak naprawdę głównie miałem programowanie i jego podstawy. Pisanie w C czy w C++ nie jest na Linuxie problemem, uważam je nawet za łatwiejsze, bo potrzebny stack jest zainstalowany na dzień dobry w większości dystrybucji. Miłym faktem było to, że uczyliśmy się również Qt, a Qt to natywna technologia dla Linuxa, zwłaszcza w KDE Plasma. Oczywiście wykorzystywany Qt Creator jest dostępny na Linux.

Niecodzienny software

Taką wewnętrzną aplikacją dla uczelni był NS Builder - program do budowania i testowania schematów blokowych NS. Aplikacja jest open source, napisana w Qt i dostępna na Linux.

Problememem mógł być HLA, czyli High Level Assembler. Jednakże stack do programowania w HLA włączaliśmy w VM z Windows XP, również na uczelni. Włączenie VM na Linuxie to żaden problem (do czego będę tutaj nawiązywał wielokrotnie).

Był też przedmiot poświęcony Linuxowi. Użytkownik Linuxa tutaj zyskiwał pewną przewagę, bowiem jest z nim bardziej obyty, a nawet sama znajomość GUI w postaci GNOME (czyli podstawowe DE w Ubuntu) była pomocna. Warto dodać, że Ubuntu to też taki domyślny system operacyjny typu Linux, z którym z pewnością większość osób spotka się na studiach.

Semestr IV

Początek 2020 roku, a więc był to pierwszy semestr zdalny. Wszystkie potrzebne aplikacje do pracy zdalnej były dostępne na Linux – a przynajmniej w przypadku mojej uczelni. Pierwszy semestr takiej pracy to też czas braku normalizacji, tudzież pewnej samowolki, dlatego dominował Discord (ale czasami potrzebny był Zoom). Jeden prowadzący zajęcia chciał korzystać z Webex, którego na Linuxa nie ma, ale udało się go namówić na Discord.

Jeśli chodzi o inne laboratoria (czyli zajęcia praktyczne w grupach do 15 osób), to nie miałem większych problemów - programowanie web/frontend lub w Javie wraz z narzędziami JetBrains to była przyjemność. Nie inaczej było na zajęciach z grafiki komputerowej, gdzie dominał w pełni zestaw aplikacji Open Source – Blender, GIMP czy Inkspace są dostępne na Linux. Do doświadczenia z Blenderem właśnie powoli wracam, ponieważ zakupiłem drukarkę 3D :-).

Reasumując, ten semestr był naprawdę nieproblematyczny i przejście go z komputerem pracującym pod kontrolą systemu Linux było jak najbardziej możliwe.

III rok studiów

Przechodzimy do kolejnego roku studiów, w zasadzie finalnego dla przyszłych inżynierów informatyki. No i w tym momencie zaczynają się schody, głównie z zajęciami z związanymi z mikrokontrolerami oraz systemami wbudowanymi. Wykorzystywane narzędzia były dostępne tylko na Windowsa ale:

1. W przypadku Atmel Studio wystarczyła maszyna wirtualna z Windows 10 AME (dzisiaj ten projekt już nie istnieje w tej postaci).
2. W przypadku innych narzędzi wystarczyła maszyna wirtualna z Windows XP. Co tutaj ważne, dla lepszej kompatybilności z takiej maszyny korzystali również użytkownicy Windowsa.

Mniej znany software

Na tym semestrze pojawiły się również duże zalety Linuxa będące zarazem przewagą nad Windowsem. Otóż instalacja dwóch mniej znanych interpretatorów języków programowania była ułatwiona - mowa o Haskellu oraz PROLOG (+Python, ale to akurat znane rozwiązanie).

W kontekście baz danych, to również tutaj mamy przewagę Linuxa, ale z małą gwiazdką. MySQL i Postgres wraz z dedykowanymi klientami GUI to żaden problem na Linux, ponieważ można i skorzystać z Dockera, i z natywnych paczek. Problem pojawił się przy MS SQL. Sam silnik jest dostępny na Linuxa, ale dedykowane narzędzie GUI - SQL Server Management Studio - zostało udostępnione tylko dla użytkowników systemu od MS. Całe szczęście wystarczyło tutaj skorzystanie z DBeaver czy, w moim przypadku, Visual Studio.

Największym problemem był dosyć przestarzały stack deweloperski w postaci XAMPP. Istnieje on na Linuxa w wersji LAMPP, ale nie ma wszystkich narzędzi i może strasznie namieszać, ponieważ (jak dobrze pamiętam) katalog deweloperski tworzy się w /opt. Jest to o tyle tragiczne, że domyślnie tam dostępy są tylko dla root. Praca z takim stackiem wymaga kombinowania i rodzi problemy. Dlatego też programowanie w PHP z LAMPP to był dla mnie ogromny problem i z wiedzą, którą zdobyłem nieco później podszedłbym do tematu kompletnie inaczej, chociażby korzystając z Dockera.

w kontekście baz danych (a raczej laboratoriów dotyczących nauki zagadnień bazodanowych) pojawił się zgrzyt na tle formatów i korporacji (czyli coś, co mastodończycy uwielbiają najbardziej). Otóż pewien prowadzący chciał przyjmować sprawozdania tylko w formacie .docx. Udało się go jednak przekonać, że ograniczenie tylko do formatu korporacyjnego nie jest dobrym pomysłem i .odt został dopuszczony. Nie zabrakło jednak argumentu od drugiej strony na tle finansowym, twierdzącego, że pewnie nie stać mnie na MS Office i dlatego używam LibreOffice (xDD).

A co z programowaniem aplikacji na systemy mobilne? Uczelnia wybrała platformę Android, na którą to przygotowywaliśmy projekty. Tutaj mamy kolejną, wielką przewagę Linuxa, ponieważ Android Studio działa szybciej na tym systemie i nawet mając niezbyt wydajny sprzęt (a właśnie taki miałem), nadal mogliśmy cieszyć się wysoką szybkością.

Oprócz programowania…

W zasadzie pamiętam tylko jedne zajęcia niezwiązane stricte z pisaniem kodu. Były to laboratoria “Inżynieria oprogramowania”, na których pracowałem w Draw.io (ciekawostka - zalecany był odpowiednik od Microsoftu, ale na niego narzekało wielu studentów, aż wszyscy wraz z prowadzącym przeszli na Draw.io, również za moim poleceniem) oraz w LibreOffice.

Ostatni semestr i praca inżynierska

W kontekście laboratoriów to dalej wykorzystywane były podobne narzędzia, które na Linux były dostępne lub po prostu istniała dowolność w doborze narzędzi.

Pracę inżynierską napisałem w stosie technologicznym: PHP, Laravel i MariaDB. Ponadto sama aplikacja “stała” na Raspberry Pi. Nie ma co tutaj dodawać, ponieważ wszystko tutaj działało na Linuxie. Problemem było jednak samo napisanie pracy, ponieważ odpowiednie formatowanie było trudne do odwzorowania w LibreOffice Writer, tym bardziej, że nie wszyscy w mojej grupie z LibreOffice korzystali. Pomoc kolegów z MS Office Word (lub z VM z Wordem) była tutaj bardzo przydatna.

Poziom magisterski - semestr I

Tutaj niestety pojawiły się problemy. Na jednym z przedmiotów wykorzystywany był Microsoft Project niedostępny na Linuxie, a żadne alternatywne programy nie wchodziły w grę. Pomogła jednak maszyna wirtualna z Windows 10 AME. Na kolejnym przedmiocie wykorzystywane były inne zamknięte narzędzia i ograniczone do samego Windowsa. Byłby to problem gdyby nie fakt, że i tak nie mieliśmy licencji do uruchomienia tego oprogramowania poza uczelnią. Laboratoria można było spokojnie wykonać na uczelnianych komputerach. Co ważne, tutaj zacząłem bawić się w selfhosting i notatki oraz sprawozdania zacząłem pisać w HedgeDoc. Co więcej, HedgeDoc pomógł mi również w notowaniu na komputerach uczelnianych.

Reszta narzędzi z innych laboratoriów była dostępna na Linux.

Semestr II i III magisterki

Kolejne semestry to kontynuacja wykorzystywania tych samych narzędzi - albo sam korzystałem z narzędzi linuxowych, bo była taka dowolność, albo narzucone narzędzia były dostępne na Linux. Pojawił się też PLSQL (w Oracle SQL), jednak nie miałem z nim żadnych problemów - połączenie kontenera dockerowego oraz DataGrip sprawdzało się świetnie.

Problemem niejako mógł być też przedmiot związany z hurtowniami danych. O ile głównie wykorzystywane narzędzie Knime jest Open Source i dostępne na Linux, tak problem był z Tableau. Na szczęście pomogła mi maszyna wirtualna z Windowsem 10.

Zadania związane z DevOps

Wyszczególniam ten dział z dwóch powodów - po pierwsze, zawodowo właśnie jestem inżynierem DevOps, a po drugie, tutaj też wychodzi przewaga w korzystaniu z systemu typu Linux. Zajęcia związane z chmurą internetową dotyczyły głównie Dockera, a jeśli mówimy o Dockerze, to też mówimy o Linuxie. Znajomość pisania konfiguracji, korzystania z Dockera czy pisania skryptów Bash była tutaj nieoceniona. Budowanie obrazów Docker również było wygodniejsze na Linuxie, głównie ze względu na znacznie wyższą wydajność. Kiedy przeszliśmy do fazy wdrożeń, to korzystaliśmy z Github Actions, które również bazują na Linuxie.

Praca magisterska

Finałem studiów była praca magisterska. Nauczony doświadczeniem, magisterkę pisałem tym razem w LaTeX, czyli po prostu w kodzie. Problemem mogło być napisanie artykułu naukowego (publikacja takiego artykułu była obowiążkowa dla każdego studenta POLLUB), co było możliwe tylko w Microsoft Word. Pomogła mi tutaj maszyna wirtualna.

A praca magisterska? No cóż, pisałem o Linuxie :-), a dokładnie o menedżerach pakietów Flatpak i Snap. OGROMNYM skrótem pracy jest artykuł naukowy, który znajdziecie tutaj. Przy okazji dodam, że sam szablon pracy dyplomowej LaTeX udostępniłem publicznie m.in. na Codeberg.

Druga uczelnia

Tak jak wspomniałem, Rozpocząłem również studia na drugiej uczelni. Ponownie na poziomie magisterskim, tym razem jednak na innej specjalizacji. Tutaj też mówimy o mniejszej, prywatnej uczelni, gdzie studiowałem w trybie niestacjonarnym.

Druga magisterka - rok pierwszy

Jako osoba doświadczona korzystałem ze stacku już mi znanego na Linuxie - powróciłem do PHP, Laravel oraz Pythona. Tylko jeden przedmiot wymagał oprogramowania niedostępnego na Linuxie (MS Office Excel), ale wysyłałem arkusze zaliczeniowe w LibreOffice Calc, które były pozytywnie oceniane.

Mogę wspomnieć o małym narzędziu, które utworzyłem z myślą o studiach i ułatwieniu sobie pracy. Otóż plan zajęć zmieniał się bardzo często i nie byliśmy o tym informowani. Sam plan natomiast był udostępniany jako arkusz kalkulacyjny. Dlatego też przygotowałem bota, który pobierał aktualnie znajdujący się plan zajęć z systemu e-learningowego (Moodle) i porównywał go z poprzednią wersją (z użyciem skrótów kryptograficznych). Jeśli została wykryta zmiana, to była wysyłana wiadomość na kanał telegramowy z należytą informacją oraz plikiem najnowszego planu zajęć. Skrypt był uruchamiany w cronie. Ten mały projekcik został doceniony też przez innych studentów.

Podsumowanie

Cóż, tl;dr to było dobre podsumowanie, ale chętnie powtórzę. Studia informatyczne w Polsce dla użytkowników Linuxa są możliwe do ukończenia i nie jest to niczym specjalnym. Polskie uczelnie chętnie wykorzystują open sourcowy stack - pewnie z różnych, finansowych powodów, ale jest to na korzyść takich studentów jakim byłem ja. Oczywiście pojawiły się zamknięte narzędzia, ale też nie uważam, że nie wolno takowych uczyć, zwłaszcza jak są bardzo popularne. Gorzej jednak jak student nie jest dopuszczony do wykorzystywania własnych alternatyw, które spełniają założenia laboratoriów (np. LibreOffice zamiast Microsoft Office jako narzędzie do sporządzenia sprawozdania).

Mało mówiłem o selfhostingu, ale ten też okazał się pomocny i żałuję, że nie zacząłem się w to bawić wcześniej. HedgeDoc i Overleaf (selfhosted jest naprawdę szybki i dobrze działający) to narzędzia niezwykle przydatne. Taki też był NextCloud z dostępem do Decka, kalendarza czy list zadań. Przydatna była też Vikunja, którą zresztą przedstawiałem na swojej uczelni jako rozwiązanie do realizacji projektów zespołowych. Dostępnych jest też wiele aplikacji naśladujących popularne rozwiązania do notatek itd. Zapewne ich funkcje znacznie ułatwią i uprzyjemnią naukę.