Coś mnie wzięło na robienie porządków na strychu przy okazji przygotowań do świat wielkanocnych i powoli, powoli to robię. Przy okazji „odkryłem” starego kompa, a że młody chce rozwijać się w kierunku IT, to wakacje spędzimy na budowie homelabu. Dziś „jak zawsze pierwsza” część opowieści o home labie na bazie starego PC’ta. Zanim przejdziemy do hardware’u (bo ten wymaga wizyty u specjalisty) zajmiemy się częścią softwarową, a dokładnie takim minimum usług, które chcę ustawić na labie.

Co chcę mieć – minimum?

Pomysł jest następujący. Na docelowej maszynie uruchomimy dockera, a następnie w ramach tego dockera uruchomimy:

  • Postgresa do zarządzania różnymi bazami
  • Jakiegoś menadżera repozytoriów do lokalnej pracy z mavenem, dockerem itp.
  • Sewer www do domowych rzeczy (współdzielenie plików, linków itd.)
  • NAS

NAS jest już hardwarowym tematem, więc na razie musi poczekać. Cała reszta nadaje się do przetestowania na moim obecnym komputerze, by później nie mieć fakapów i nie tracić czasu na duperele.

Jak zacząć?

Najlepiej od początku, ale wbrew pozorom nie jest to takie oczywiste. W tym przypadku podejście „odpal docker compose i nara” nie do końca zadziała. Inaczej. Zadziała, ale tak naprawdę tracimy z oczu całe tło, które przy migracji na docelową maszynę będzie bardzo istotne. Przecież sama migracja będzie gdzieś w połowie wakacji, więc też część wiedzy „wyparuje”.

Jeżeli nie jest się pełnoetatowym administratorem lub nie pracuje się w zespole hołdującym zasadom DevOps (DevOps to podejście do pracy, a nie stanowisko!), to też nie ma się wprawy w takich administracyjnych zadaniach. Zatem warto spędzić chwilę i zaplanować sobie pracę. Dodatkowo warto całość na koniec gdzieś wypchnąć, żeby później na środowisku docelowym nie musieć klepać wszystkiego od zera.

Plan

Plan był taki jak zawsze, czyli, że kiedyś to zrobimy. Jednak jakieś ~1,5 tygodnia temu stwierdziłem, że potrzebuję lokalne repo Artifactory, żeby ogarnąć jeden z moich projektów. I postanowiłem zrobić to dobrze :D

Plan był zatem następujący.

  1. Stawiamy Artifactory jako kontener
  2. Stawiamy bazę Postgres, jako kontener
  3. Całość „zasłaniamy” nginx.

Niby proste, ale jak zwykle okazało się, że chciałem zrobić to dobrze, więc będzie pod górkę.

Przygotowania

Na moim GH znajdziecie repozytorium, w którym trzymam różne swoje konfiguracje. Jest to jedno z tych miejsc, które kiedyś sprzątnę, ale nie teraz :D Jakoże jest to taki „zakwas” dla moich komputerów, więc naturalną rzecz jest umieszczenie wszystkiego właśnie w tym repo. Nie chcę teraz dokładnie omawiać, co i jak w tym repo, bo to zupełnie osobny temat. W skrócie, mamy część w katalogu services, która będzie zawierać potrzebne mi rzeczy.

Postgres

Najprostszym do ogarnięcia wydawał się postres. I rzeczywiście, konfiguracja w kontenerze jest bardzo prosta, o ile nie chcesz nic zmieniać. Jedyne co dodałem, to init.sql, który sprawdza i w razie czego tworzy kilka baz danych. Ale…

Jeżeli chcemy przykryć wszystko za pomocą nginx, to mamy „mały” problem. Do takiej bazy danych nie dostaniemy się z zewnątrz. Należy zatem zrobić kilka rzeczy. Po pierwsze mapowanie portu 5432 na port hosta. To jest standardowe podejście, jeżeli używamy dockera. Jednak w docelowym systemie, nie możemy sobie pozwolić na dostęp do tego portu nikomu spoza wyznaczonej listy hostów. Hosty możemy zdefiniować na dwa sposoby:

  1. Możemy utworzyć sieć dockerową, zakładając, że wszyscy zainteresowani będą łączyć się z tej sieci.
  2. Możemy wystawić port, a następnie na hoście zablokować ruch do tego portu spoza naszej sieci za pomocą firewalla.

I tak źle i tak niedobrze. Pierwsze rozwiązanie pozbawia nas dostępu do bazy z aplikacji działających na innych maszynach. Ten postgres ma służyć do pracy, a nie do udawania, więc trzeba inaczej. Druga opcja jest lepsza, bo domowe komputery będą mogły się połączyć, ale nie mam dostępu „jakby co” spoza domu. Nie mamy dostępu do portu. Trzeba zatem postawić pgadmina i w nim skonfigurować dostęp do bazy. Zwykły obraz wystarcza. Kontener z pgAdminem działa w tej samej sieci dockerowej co postgres, więc formalnie łączy się z hostem postgres:5432. Komputery w LAN-ie będą łączyć się z hostem po IP_HOST:5432. Firewall załatwi resztę. Więcej nie potrzeba, bo poważne awarie i tak będe musiał obarnąć z domu.

nginx

Okazał się prostszy niż postgres :D Co jednak warto zrobić, to trzymać konfiguracje poszczególnych usług w osobnych plikach oraz nazwać serwer inaczej niż localhost. To przyda się później jak postawimy DNS, który ułatwi dostęp do maszyny innym komputerom w domowej sieci. Ale to później.

Artifactory, a w zasadzie Nexus

Największym problemem okazała się konfiguracja Artifactory. I nie mówię tuo prostej konfiguracji obrazu, ale o odpowiedniej konfiguracji proxy. Po kilku dniach wojowania stwierdziłem, że Artifactory nie jest moim must have, a Nexus też jest OK. Koniec końców zainstalowałem nexusa. Tutaj jedna sztuczka – przy pierwszym uruchomieniu należy to zrobić jako root ustawiając user: root w docer-compose.yml. Po wstępnym skonfigurowaniu hasła administratora należy zaaplikować chown -R 200:200 na pliki nexusa i zrestartować kontener. Ta magia jest potrzebna, jeżeli chcemy trzymać pliki poza domyślnym katalogiem z wolumenami dockera. Czyli w praktyce zawsze :D O tym dlaczego kiedy indziej.

Po skonfigurowaniu nexusa warto też sprawdzić, czy nasze lokalne buildy działają, jak należy. Pierwsze uruchomienie może być znacznie dłuższe, bo nexus będzie zaciągać pliki z głównego repozytorium.

Podsumowanie

Zabawa jest przednia. Dżepetto i Klaudyna pomagają pisać żmudne rzeczy, ale nie można im ufać. Modele AI mają wiedzę, która nie zawsze jest aktualna i odnosi się do starszych wersji narzędzi. Nie warto też walczyć, jeżeli coś nie chce działać, a nie mamy przymusu użycia. Zmarnowałem kilka dni an potyczkę z Artifactory, teraz wiem, że było to zbędne.

W miarę rozwoju projektu będę wrzucać kolejne opisy.