O tym, jak wycisnąć chmurę do ostatniego centa, opowiedział Robert Szulist – certyfikowany specjalista i trener Zabbixa, który postanowił przetestować granice bezpłatnych usług Google’a na własnej skórze i homelabie.
Rzecz miała miejsce podczas jednego z naszych stacjonarnych meetupów SysOps/DevOps Polska. Jeśli lubisz na żywo dopytać prelegenta o nietypowe, przypadki, zderzyć swoje architektoniczne wątpliwości albo po prostu pogadać o środowiskach produkcyjnych przy piwie – koniecznie wpadaj na kolejne spotkania na żywo!
Jak zbudować architekturę Zabbixa na GCP bez czyszczenia portfela?
Cały koncept opiera się na maksymalnym wykorzystaniu oferty GCP Free Tier. Fundamentem naszej maszyny jest mikroskopijna instancja Compute Engine (E2-micro), dostarczająca 1 GB pamięci RAM i współdzielone vCPU. Ekspert wskazuje na fakt, że jeszcze do niedawna darmowe F1-micro oferowało ledwo pół giga RAM-u – zatem, obecne zasoby to wręcz komfortowe warunki na start. Do tego dochodzi 30 GB darmowego dysku, na którym z powodzeniem mieści się skompresowana baza PostgreSQL.
Żeby jednak odciążyć naszą małą instancję Compute Engine od obsługi interfejsu graficznego, Robert zastosował sprytny zabieg: wyniósł cały frontend Zabbixa do App Engine. Google przyznaje darmowy limit 28 godzin działania App Engine na dobę, co z nawiązką pokrywa ciągłą pracę paneli administracyjnych.
Co ciekawe, analityka budżetowa Google’a nie do końca popiera takie eksperymenty. Gdy wbijemy w panel GCP, optymalizator kosztów potrafi wyświetlić ostrzeżenie o “finansowej nieodpowiedzialności” i sugeruje, że modyfikacja zasobów mogłaby wygenerować tysiące procent oszczędności… chociaż fizyczny rachunek z całego roku wynosi dokładnie 8,39 PLN. Te parę złotych to zresztą nie koszt samych maszyn, lecz wynik minimalnego ruchu sieciowego oraz powiadomień.
Szyfrowanie, certyfikaty i wyboje w App Engine
Optymalizacja budżetowa wymaga kompromisów, zwłaszcza gdy mowa o bezpieczeństwie sieciowym. Komunikacja między agencją Zabbixa w środowisku domowym (odpaloną choćby na Raspberry Pi) a serwerem w chmurze nie może lecieć otwartym tekstem – zwłaszcza przy aktywnych sprawdzaniach (active checks), gdzie w ruchu mogą pojawić się hasła czy poświadczenia. Prelegent twierdzi, że najprostszym i całkowicie darmowym rozwiązaniem jest tu użycie kluczy PSK (Preshared Key), które gwarantują sprawną szyfrowaną autoryzację na porcie 10051.
Prawdziwa zabawa zaczyna się jednak na styku App Engine (Frontend) <-> PostgreSQL (Baza). Aby nie płacić za dedykowane integracje sieciowe (VPC Peering), ruch trzeba puścić przez internet, zabezpieczając go obustronnym szyfrowaniem mTLS na własnym, lokalnie wygenerowanym urzędzie certyfikacji (CA).
W tym miejscu Robert trafił na genialną pułapkę technologiczną. Wdrożenie konfiguracji do App Engine powodowało, że pliki certyfikatów lądowały w katalogu roboczym ze zbyt szerokimi uprawnieniami (np. 644). PHP pod spodem Zabbixa natychmiast odrzucał takie klucze ze względów bezpieczeństwa, a sam App Engine ma chroniony, podglądowy system plików.
Jak to obejść? Prelegent wpadł na łopatologiczny, ale wysoce skuteczny pomysł: wziął plik wrappera include/config.inc.php i dopisał do niego funkcję, która przy każdym żądaniu sprawdza, czy certyfikaty znajdują się w tymczasowym katalogu /tmp. Jeśli ich tam nie ma, skrypt kopiuje je z przestrzeni roboczej i w czasie rzeczywistym nadaje im rygorystyczne uprawnienia (np. 600). Proste, darmowe i – jak pokazuje praktyka – niezawodne od ponad czterech lat!
Słabe punkty architektury i raportowanie za darmo
Warto pamiętać o ograniczeniach, jakie narzuca rozdzielenie frontendu i backendu bez płatnej sieci prywatnej. Frontend Zabbixa co jakiś czas musi odpytać bezpośrednio proces serwera (np. do podglądu żywej kolejki czy testowania pozycji). Ponieważ połączenie to normalnie przesyła zaszyfrowany token sesji, wystawienie go bez pośrednictwa VPN na świat niesie ryzyko przechwycenia.
Ekspert wskazuje, że mamy tu do wyboru trzy drogi:
- Pójść na żywioł (YOLO): podać publiczny adres i liczyć na szczęście.
- Zaakceptować ograniczenia: skierować frontend na localhost, godząc się z brakiem podglądu kolejki na żywo.
- Dopłacić: zestawić pełnoprawną sieć VPC/Tailscale/WireGuard w chmurze (co nieco podnosi koszty).
A co z tygodniowymi raportami graficznymi dla biznesu? Zabbix do ich generowania wykorzystuje usługę Zabbix Web Service, która pod spodem odpala headless Chromium, robi screenshoty dashboardów i wysyła je mailowo. Robert postawił tę usługę w kontenerze na Cloud Run, a maile wypycha poprzez zewnętrzny, darmowy serwer SMTP (np. Brevo). Efekt? Raporty PDF spływają co tydzień, a koszty infrastruktury nadal dążą do zera.
Chcesz więcej?
Przykłady takie jak ten pokazują, że do zbudowania stabilnego monitoringu w chmurze nie są potrzebne wielkie budżety enterprise – wystarczy dobra znajomość architektury danego rozwiązania, znajomość limitów dostawców cloudowych i odrobina inżynierskiej zaciętości.
Jeśli chcesz podyskutować o takich architekturach, wymienić się doświadczeniami i nie przegapić kolejnych technicznych mięsistych prezentacji – śledź nadchodzące wydarzenia społeczności SysOps/DevOps Polska i wpadaj na nasze meetupy: https://www.sysopspolska.pl/eventy/
A jeżeli prelekcja to za mało i potrzebujesz zagłębić się w tajniki Zabbixa od podstaw, sprawdź szkolenie: https://www.sysopspolska.pl/szkolenia/zabbix/
