Krzysztof Kaletka

Homelab jako projekt

Zbudowane jako kod, nie jako notatka

Cała infrastruktura stoi na wirtualnej maszynie AlmaLinux 9, uruchomionej na QNAP TS-264 przez Virtualization Station. Osiem ról Ansible — Docker, DNS z blokowaniem reklam (Blocky), ta strona, reverse proxy z automatycznym TLS (Caddy), monitoring, menedżer haseł (Vaultwarden), dashboard usług (Homepage) i zero-trust tunnel (cloudflared) — są spięte wspólną siecią Docker i wdrażane jednym poleceniem. Każda zmiana przechodzi ten sam proces co w firmie: osobny branch, pull request, automatyczny lint i syntax-check w GitHub Actions, Vagrant, dopiero potem wdrożenie na żywy system.

• Ansible
• Docker
• Caddy
• Cloudflare Tunnel
• Prometheus
• Grafana
• GitHub Actions

Zobacz kod →

Dowody, nie deklaracje

Cztery razy, gdy coś się zepsuło

Homelab jako kontenery nie eliminuje awarii — zamienia jedną kategorię problemów na inną. Poniżej cztery, które faktycznie wystąpiły i zostały zdiagnozowane od zera.

• incident-node-exporter-netns.log RESOLVED

  node_exporter i namespace sieciowy kontenera

  node_exporter uruchomiony bez network_mode: host widzi tylko interfejsy sieciowe własnego namespace'u kontenera, nie hosta — zamontowanie /proc z --path.procfs tego nie naprawia, bo /proc/net jest per-namespace, a nie per-mount. Zdiagnozowane empirycznie: porównanie metryk z zawartością /proc/net/dev bezpośrednio na hoście. Zamiast zostawić w Grafanie panel sieciowy pokazujący nieprawdziwe dane, został on usunięty z dashboardu — metryki CPU, RAM i dysku pozostają dokładne i widoczne.

• incident-cadvisor.log RESOLVED

  cAdvisor a containerd snapshotter

  cAdvisor poniżej wersji v0.54.0 nie rozumiał sposobu przechowywania warstw kontenerów w containerd-snapshotterze — kontener startował, ale nie widział żadnych innych kontenerów do monitorowania. Do tego rejestr obrazu zmienił się z gcr.io na ghcr.io przy wersji v0.53.0, więc sama zmiana tagu bez zmiany rejestru kończyła się błędem pobierania. Wersja i rejestr są dziś przypięte na stałe w kodzie, z komentarzem tłumaczącym dlaczego.

• incident-caddy-image.log RESOLVED

  Osierocony obraz Caddy po rebuildzie

  Przebudowa obrazu Caddy pod tym samym tagiem zostawia działający kontener wskazującym na już nieistniejący sha — Docker Compose wywala się wtedy błędem „No such image" przy najbliższej próbie odświeżenia. Zwykły restart nic nie naprawia, bo kontener nie jest odtwarzany, tylko zatrzymywany i uruchamiany ponownie z tą samą, nieaktualną referencją. Naprawa to pełne docker compose down && up.

• incident-cloudflared-mount.log RESOLVED

  Bind mount, inode i cichy fail configu

  Plik zamontowany do kontenera pojedynczo, nie jako cały katalog, wiąże się z konkretnym inode'em w momencie startu kontenera. Edytor, który zapisuje przez utworzenie nowego pliku i podmianę — a większość, łącznie z nano i sed, tak właśnie robi — tworzy nowy inode. Kontener dalej czyta stary, osierocony plik, mimo że na dysku widać już nową treść. Jak przy poprzednim incydencie: dopiero pełne odtworzenie kontenera, nie sam restart, rozwiązuje problem.

Monitoring

Metryki

Prometheus, node_exporter, cAdvisor i Grafana — dashboardy provisionowane w całości jako kod (allowUiUpdates: false), nie klikane ręcznie w interfejsie. Definicje paneli JSON żyją w repozytorium jako jedyne źródło prawdy.

Zobacz kod monitoringu →