Docker Compose w Homelab: organizacja, profile i najlepsze praktyki

Informatec Digital » Zasoby » Docker Compose w Homelab: organizacja, profile i najlepsze praktyki

Budowa nowoczesnego laboratorium domowego z kontenerów transportowych stała się ulubionym hobby wielu osób zajmujących się technologią. Docker Compose jest prawie zawsze sercem tej konfiguracjiZdefiniuj swoje usługi w YAML, wersjonuj je za pomocą Git i uruchom całe środowisko za pomocą jednego polecenia.

Teraz, gdy zaczynasz rosnąć, dzieją się różne rzeczy: przechodzisz od posiadania dwóch lub trzech pojemników do Dziesiątki usług, sieci wewnętrznych, serwerów proxy odwrotnych, baz danych i programów uruchamiających CIWtedy pojawia się kluczowe pytanie: jeden gigantyczny Docker Compose czy wiele małych plików? Jak zorganizować profile, sieci, kopie zapasowe, zabezpieczenia i do tego ułatwić migrację?

Praktyczne podejście do konfiguracji Docker Compose w laboratorium domowym

W praktyce osoby korzystające z Homelabs od dłuższego czasu zazwyczaj funkcjonują w ramach trzech modeli organizacyjnych Compose, z których każdy ma swoje zalety i wady. Wybór odpowiedniego podejścia pozwoli Ci zaoszczędzić sporo czasu podczas rozbudowy lub migracji maszyn..

Po jednej stronie jest ten, który zaczął od Docker Run początkowo był nieformalny, następnie przeniósł się do Portainer, a na końcu do Docker Compose.To typowe: Portainer zapewnia świetną przejrzystość, przyjazny użytkownikowi interfejs, szablony itp., ale ostatecznie edycja złożonych parametrów lub migracja konfiguracji staje się uciążliwa, jeśli nie masz niczego w plikach.

Na przeciwległym biegunie znajdują się ci, którzy skonsolidował wszystko w jednym „mega” pliku docker-compose.yml zdolny do obsługi wszystkich usług homelab: odwrotnego proxy, multimediów, narzędzi, monitoringu, LLM, baz danych… Wszystko w jednym stosie.

Tymczasem wielu użytkowników decyduje się na podejście mieszane: kilka małych plików docker-compose.yml pogrupowanych według kontekstu (na przykład media, infrastruktura, produktywność, monitorowanie), wszystkie w tym samym repozytorium i zwykle współdzielą globalne zmienne środowiskowe.

Rozwiązanie łączące oba światy jest dość eleganckie: główny docker-compose zawierający inne pliki (każda w podfolderze aplikacji lub usług). W ten sposób zachowujesz globalny widok homelab, ale bez konieczności przechodzenia przez tysiącwierszowy plik YAML, którego nie da się odczytać.

Profile, grupowanie według funkcji i duże laboratoria domowe

Kiedy Twoje domowe laboratorium zaczyna zbliżać się do 30, 40 lub 50 usług (w tym usługi tworzenia kopii zapasowych, takie jak bazy danych, pamięci podręczne czy indeksatory) kluczowe jest uporządkowanie tego. To właśnie tutaj zarówno grupowanie według funkcji jak użycie Profile Docker Compose.

Bardzo powszechnym schematem jest grupowanie wszystkiego w jednym „projekcie” Compose, ale logicznie podzielonym według profili. Na przykład:

• Profil główny:rdzeń homelab z Traefikiem jako odwrotnym serwerem proxy i dostawcą tożsamości (np. OAuth lub Authentik) w celu uwierzytelniania wszystkich aplikacji w tej samej domenie za pomocą protokołu HTTPS.
• Profil medialnyUsługi takie jak Plex, Sonarr, Radarr, Ombi, SABnzbd czy qBittorrent, odpowiedzialne za selekcję, pobieranie i udostępnianie treści multimedialnych.
• Profil narzędziNarzędzia takie jak Portainer, Watchtower (jeśli używane), Diun, dockcheck lub podobne służące do zarządzania kontenerami i aktualizacjami oraz monitorowania ich.
• Profil infrastruktury/monitorowania: Traefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle i wszystko, co związane z monitorowaniem i rejestrowaniem.
• Profile eksperymentalne lub LLM:specyficzne stosy dla LLM lub ciekawych aplikacji (ChatGPT Next Web local, LibreOffice Online itp.), które są zazwyczaj domyślnie wyłączone.

Piękno profili polega na tym, że Można uruchomić tylko część infrastruktury W zależności od potrzeb. Na przykład, możesz uruchomić tylko profil „rdzeń + infrastruktura” na energooszczędnym minikomputerze, a profil „media” tylko na dużym serwerze z większą liczbą dysków i procesorów graficznych.

W dobrze zaprojektowanych repozytoriach zwykle występuje docker-compose.yml „master”, który pobiera dołączenia do poszczególnych plików w folderze apps/ lub services/Co więcej, niemal wszystkie usługi konfiguruje się za pomocą jednego pliku. .env global i kilka sekretów w katalogu secrets/, co znacznie upraszcza początkową konfigurację.

Zgodnie z tym schematem zarządzanie laboratorium domowym sprowadza się zasadniczo do Edytuj plik .env i sekrety, włącz lub wyłącz profile i zdecyduj, które usługi mają zostać uruchomione na każdym hoście.Idealne rozwiązanie, jeśli zamierzasz wdrożyć ten sam zestaw aplikacji na wielu komputerach.

Jeden gigantyczny plik docker-compose kontra kilka małych plików

Oto odwieczna debata: Pojedynczy plik docker-compose.yml zawierający wszystko czy wiele plików na usługę/stos? Prawdziwa odpowiedź zazwyczaj brzmi: „To zależy od tego, co chcesz priorytetowo traktować: prostotę migracji czy przejrzystość poszczególnych usług”.

Kto broni pojedynczy plik główny Zazwyczaj podkreśla kilka zalet:

• Migracja hostów jest superłatwaKlonujesz repozytorium, kopiujesz plik .env i sekrety, montujesz woluminy i uruchamiasz polecenie `docker compose up -d`. Nie ma potrzeby przechodzenia katalog po katalogu.
• Infrastruktura jako kodeks prawdy:cała topologia homelaba (usługi, sieci, woluminy, zależności) znajduje się w jednym miejscu.
• Centralne aktualizacje:zmieniasz wersję obrazu, zasady ponownego uruchamiania lub jakieś rejestrowanie i dokładnie wiesz, gdzie tego dokonać.

Ale ma też wyraźne wady: utrzymanie dużego pliku YAML jest trudniejsze, Konflikty scalania rosną Kiedy przychodzi czas na debugowanie konkretnego problemu, napotykasz monstrum setek wierszy. Nierzadko zdarza się, że odczuwasz lekki żal, gdy wszystko staje się zbyt duże.

Innym podejściem jest posiadanie jeden plik docker-compose.yml na aplikację lub na stos logiczny, w ramach struktury takiej jak:

docker/
├── bookstack/
│   └── docker-compose.yml
├── dashy/
│   └── docker-compose.yml
└── traefik/
    └── docker-compose.yml

Dzięki temu każdy pojemnik nazywa się czymś w tym rodzaju bookstack-app-1 o traefik-odwrotny-serwer-proxy-1co pomaga szybko zlokalizować problemy: jeśli kontener bookstack-app-1 ulegnie awarii, będziesz dokładnie wiedział, w którym folderze szukać.

Wizualnie jest o wiele czystszy i Umożliwia niezależne zarządzanie każdą usługą. (uruchamianie, zatrzymywanie lub aktualizowanie bez wpływu na resztę). Ponadto istnieją aplikacje takie jak Dozzle, które wykorzystują oddzielne stosy do lepszej organizacji logów.

Kompromis polega na tym, że Jeśli wszystko rozdzielisz za bardzo, koordynacja między wspólnymi usługami (takimi jak Traefik lub sieci współdzielone) będzie wymagała nieco więcej uwagi.:należy zadeklarować sieci zewnętrzne, użyć określonych etykiet Traefik i zapamiętać nomenklaturę sieci utworzonych przez innych użytkowników docker-compose.

Najlepsze praktyki dotyczące .env, nadpisywania i kontroli wersji

Jednym z najbardziej niedocenianych trików jest scentralizować konfigurację w plikach .envZamiast wypełniać plik docker-compose.yml zmiennymi środowiskowymi, możesz zdefiniować coś takiego:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

A następnie w YAML są one określane jako ${DB_USERNAME} o ${DB_PASSWORD}Dzięki temu tekst można przeczytać na pierwszy rzut oka, co pozwala na udostępniaj zmienne w wielu usługach A przede wszystkim przechowuj hasła w osobnym pliku (który możesz wykluczyć z Gita).

Jest bardzo przydatny w różnych środowiskach (produkcyjnym, testowym, programistycznym). skorzystaj z docker-compose.override.ymlPomysł polega na tym, aby mieć plik bazowy docker-compose.yml i podczas nadpisywania nadpisywać tylko te zmiany, które zaszły: porty, ścieżki, flagi debugowania…

Na przykład podczas rozwoju można załadować nadpisanie, gdzie Udostępniasz inny port, aktywujesz DEBUG i montujesz lokalny kod źródłowy.Nie ruszasz głównego pliku YAML, ale dostosowujesz stos do środowiska, w którym go uruchamiasz.

Oczywiście, Wersjonowanie wszystkiego za pomocą Gita jest obowiązkowe, jeśli chcesz, aby Twoje laboratorium domowe było choć trochę poważne.Zazwyczaj masz coś takiego:

homelab-docker/
├── docker-compose.yml
├── .env.example
├── services/
│   ├── media/
│   ├── infra/
│   └── ...
└── scripts/

Następnie inicjujesz repozytorium, zatwierdzasz zmiany w infrastrukturze i jeśli coś się zepsuje, W kilka sekund możesz powrócić do poprzedniej wersji aplikacji Compose.Dla ambitnych laboratoriów domowych nie jest to tylko opcja, to jedyny sposób, aby uniknąć szaleństwa.

Sieci, Traefik i bezpieczne udostępnianie usług

Ta sama kombinacja pojawia się w niemal wszystkich średnio zaawansowanych laboratoriach domowych: Traefik jako odwrotny serwer proxy i scentralizowany dostawca tożsamości (Auth lub Authentik)Dzięki temu możesz udostępniać wiele aplikacji w subdomenach z protokołem HTTPS i logowaniem jednokrotnym.

Klasycznym wzorcem jest na przykład utworzenie dedykowanej sieci Docker odwrotny_serwer_proxy lub podobne, gdzie Traefik i wszystkie usługi sieciowe, które będą świadczone zewnętrznie, są połączone. Reszta kontenerów (bazy danych, pamięci podręczne itp.) pozostaje w odizolowanych sieciach wewnętrznych.

Jeśli używasz Traefika i rozdzielasz swoje usługi do różnych docker-compose, musisz zdefiniuj współdzieloną sieć zewnętrznąCoś takiego:

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack
    networks:
      - traefik-net
    labels:
      - "traefik.docker.network=traefik_default"

networks:
  traefik-net:
    name: traefik_default
    external: true

W tym przypadku sieć traefik_default jest tworzona przez stos Traefik, a pozostałe usługi są do niej dodawane za pośrednictwem sieci zewnętrznej o nazwie traefik-net. Tagi informują Traefik... która sieć powinna być używana do kierowania ruchem.

Gdy pojedynczy stos obejmuje usługi zaplecza (na przykład kontener internetowy i jego bazę danych), można Podłącz je do współdzielonej sieci domyślnej i udziel kontenerowi internetowemu dostępu wyłącznie do sieci Traefik.Baza danych będzie miała etykietę traefik.enable=false, więc Traefik ją zignoruje.

Ten typ konfiguracji zapewnia dwie główne korzyści: izolacja między usługami i kontrolowana ekspozycjaDostęp z zewnątrz będą miały tylko te kontenery, które oznaczysz etykietami Traefik i które znajdują się w sieci proxy.

Trwałość danych, woluminy i struktura dysku

Domowe laboratorium bez trwałych danych nie jest zbyt użyteczne: bazy danych, konfiguracje, media, dokumenty... wszystko musi przetrwać awarię Dockera. Tomy i oprawy to Twoje ubezpieczenie na życie.

Wiele osób organizuje swoje przechowywanie, korzystając z następującej struktury:

/mnt/storage/
├── downloads/
│   ├── movies/
│   └── tv/
├── media/
│   ├── movies/
│   ├── tv/
│   └── music/
└── srv/
    └── 

Chodzi o to Programy do pobierania (qBittorrent, SABnzbd itp.) widzą tylko folder pobieraniaMenedżery takie jak Radarr/Sonarr mają dostęp zarówno do plików do pobrania, jak i multimediów (w celu przenoszenia/tworzenia twardych linków), a serwery takie jak Plex lub Jellyfin widzą tylko folder z multimediami.

W ten sposób stosujesz zasadę minimalne uprawnieniaKażdy kontener uzyskuje dostęp tylko do tego, czego faktycznie potrzebuje. Ten wyraźny podział pomaga również przy podejmowaniu decyzji, które woluminy lub ścieżki mają zostać zapisane w kopii zapasowej w chmurze lub na dyskach zewnętrznych.

Katalog srv jest zazwyczaj używany do przechowywania konfiguracji aplikacji (na przykład /srv/jellyfin/config, /srv/traefik, /srv/paperless itp.). Zazwyczaj jest on częściowo wersjonowany (szablony, Caddyfile itp.), z pominięciem elementów krytycznych lub wymagających dużej ilości zasobów.

W niektórych przypadkach ciekawe jest użycie twarde linki W łańcuchu pobierania: usługi takie jak Radarr czy Sonarr mogą łączyć pobrane pliki, aby utrzymać seeding bez duplikowania miejsca na dysku. Projekt katalogów proponowany przez przewodniki takie jak TRaSHGuides opiera się właśnie na tym.

Automatyzacja wdrożeń za pomocą GitHub Actions i lokalnych programów uruchamiających

Jeśli chcesz przenieść sprawy na wyższy poziom, możesz pójść o krok dalej i Zautomatyzuj aktualizacje homelabu za pomocą CI/CDWielu użytkowników zastąpiło Jenkinsa i podobne narzędzia przepływem pracy wykorzystującym GitHub Actions i samodzielnie hostowany moduł uruchamiający w ich własnym laboratorium domowym.

Mechanizm jest prosty: za każdym razem, gdy przesyłasz dane do głównej gałęzi swojego repozytorium Homelab, Uruchamiany jest przepływ pracy GitHub Actions, który uruchamia testy, lintery i, jeśli wszystko pójdzie dobrze, wdraża zmiany na serwerze..

Typowy przepływ pracy obejmuje następujące kroki:

• Tajny skaner typu Gitleaks:na wypadek gdybyś przypadkowo przesłał hasła lub tokeny do repozytorium.
• podszewka kodu YAML lub infrastruktury, aby zachować czytelny i spójny format.
• Aktualizacja repozytorium w samym laboratorium domowym: git pull na serwerze docelowym.
• Kontrolowana rekreacja kontenerów:zatrzymaj stare, uruchom nowe i sprawdź status.

Zalety: dodatkowe bezpieczeństwo (kontrolujesz wycieki sekretów), lepsza jakość kodu i powtarzalne wdrożenia za pomocą jednego naciśnięciaA ponieważ używasz lokalnego modułu uruchamiającego, obrazy i woluminy nie opuszczają Twojej sieci; po prostu korzystasz z interfejsu GitHub w celu wizualizacji potoków.

Dlaczego Docker Compose tak bardzo ułatwia życie w laboratorium domowym

Wiele osób przez lata polegało na Docker Run i Portainer Dopóki w wyniku incydentu lub migracji nie będzie zmuszona do ponownej oceny swojego podejścia. W przypadku utraty hosta lub konieczności przeniesienia usług na inną maszynę, Poleganie wyłącznie na izolowanych poleceniach lub konfiguracjach w Portainerze to pułapka.

Największą różnicą po przejściu na Compose jest to, że Cała definicja usługi staje się tekstem.Woluminy, porty, sieci, etykiety, zmienne… Wszystko w pliku YAML, który można kopiować, udostępniać, tworzyć wersje i ponownie wykorzystywać.

Edycja usługi nie polega już na „ręcznym przebudowywaniu kontenera”, lecz staje się zmodyfikuj linię w pliku, zapisz i uruchom docker compose up -dNie musisz pamiętać oryginalnego polecenia ani klikać przez wiele ekranów Portainera.

Co więcej, jeśli pracujesz z wieloma serwerami (mini PC, NAS, komputery stacjonarne), niezwykle wygodna jest możliwość Skopiuj ten sam plik do innego komputera, dostosuj cztery ścieżki i uruchom ten sam stos przy użyciu innego sprzętu.W rzeczywistości wiele osób przyznaje, że po strachu związanym z utratą danych lub chaotycznymi migracjami, Compose pozwoliło im zaoszczędzić mnóstwo czasu w późniejszych sytuacjach.

Dodatkowym atutem jest to, że tworzenie nowych usług na podstawie starych staje się banalnie proste: na przykład, sklonuj konfigurację Plex, aby zamontować Jellyfin Ponowne wykorzystanie tych samych ścieżek multimedialnych i urządzeń transkodujących zajmuje tylko kilka minut, jeżeli robisz to poprzez kopiowanie bloków YAML.

Optymalizacja: kontekst kompilacji, kompilacje wieloetapowe i zasoby

Chociaż wiele kontenerów Homelab pochodzi z publicznych obrazów, w niektórych przypadkach będziesz kompilować własne obrazy. W takich przypadkach należy zachować ostrożność. zbudować kontekst: Nie wysyłaj całego repozytorium bez filtrowania, ale ogranicz się do folderu projektu (z dobrym .dockerignore), aby kompilacje były szybkie i lekkie.

Inną bardzo przydatną techniką jest uciekanie się do kompilacje wieloetapowe W plikach Dockerfile: w pierwszej fazie instalujesz zależności i kompilujesz, a w drugiej fazie kopiujesz tylko niezbędne artefakty do małego obrazu bazowego. Rezultat: obrazy finalne znacznie mniejszy i bezpieczniejszyponieważ nie przenoszą łańcuchów narzędzi ani dodatkowych bibliotek.

Po stronie kompozycji masz możliwość zdefiniowania Ograniczenia procesora i pamięci RAM (szczególnie w środowiskach Swarm lub gdy Docker respektuje te parametry), aby zapobiec monopolizacji zasobów przez aplikacje intensywnie wykorzystujące zasoby. W Homelabs pomaga to zapobiec sparaliżowaniu reszty systemu przez błędnie skonfigurowaną usługę.

Nie zapomnij o zasady ponownego uruchamiania (restart: zawsze, chyba że zatrzymane, w przypadku awarii): dzięki temu masz pewność, że krytyczne usługi (odwrotny serwer proxy, VPN, kluczowe bazy danych) zostaną automatycznie ponownie uruchomione po ponownym uruchomieniu lub jednorazowej awarii.

Na koniec warto zaplanować regularne zadania związane ze sprzątaniem, korzystając z poleceń takich jak czyszczenie obrazu Dockera, czyszczenie kontenera Dockera i czyszczenie woluminu Dockera aby wyeliminować pozostałości starych kompilacji, zatrzymanych kontenerów lub porzuconych woluminów i w ten sposób odzyskać miejsce na dysku.

Usługi zdrowotne, rejestrowanie i monitorowanie

Aby mieć pewność, że Twoje domowe laboratorium nie stanie się czarną skrzynką, ważne jest, aby zadbać o trzy kluczowe aspekty: kontrole stanu zdrowia, kontrolowane rejestrowanie i monitorowanieDocker Compose umożliwia deklarowanie kontroli kondycji dla każdej usługi (za pomocą poleceń takich jak curl -f http://localhost lub określonych skryptów), które ustalają, czy kontener jest uważany za sprawny.

Dzięki temu możesz to zrobić tak, że Tylko „zdrowe” kontenery otrzymują ruch (na przykład za pośrednictwem Traefika) i że jeśli przestaną odpowiadać, zostaną ponownie uruchomione zgodnie ze skonfigurowaną polityką. To znacznie zwiększa odporność przy minimalnym wysiłku.

Jeśli chodzi o logi, dostosuj plik json sterownika, stosując ograniczenia maksymalny rozmiar i maksymalny plik Zapobiega zapełnieniu dysku gigabajtami zapomnianych logów. Narzędzia internetowe, takie jak Dozzle, pozwalają przeglądać logi wszystkich kontenerów z poziomu przeglądarki, co jest bardzo wygodne przy debugowaniu określonych usług.

Jeśli chodzi o metryki i ciągłe monitorowanie, klasycznym połączeniem jest cDoradca + Prometheus + GrafanacAdvisor udostępnia statystyki wykorzystania procesora, pamięci, dysku i sieci dla każdego kontenera; Prometheus zbiera je okresowo, a Grafana wyświetla je na atrakcyjnych pulpitach, wysyłając alerty w przypadku gwałtownych zmian.

Dobrze wyposażone laboratorium domowe zazwyczaj obejmuje również: Czas pracy Kuma w celu sprawdzenia dostępności (HTTP, ICMP, TCP…) oraz zautomatyzowany system tworzenia kopii zapasowych, taki jak Duplicati, umożliwiający kopiowanie krytycznych danych na inne dyski lub do chmury. Dzięki temu wiesz, co się dzieje i jeśli coś pójdzie nie tak, nie stracisz tego, co ważne.

Bezpieczeństwo i zdalny dostęp do laboratorium domowego

Niezależnie od tego, jak bardzo domowa jest instalacja, bezpieczeństwo nie jest opcjonalne. Wiele osób decyduje się na Nie udostępniaj bezpośrednio swojego serwera NAS ani jego usług światu zewnętrznemu.ograniczenie zdalnego dostępu poprzez VPN (WireGuard jest bardzo popularną opcją ze względu na swoją wydajność i prostotę).

W tym modelu router pełni funkcję bramy: dla serwera VPN otwierany jest tylko losowy port, a po nawiązaniu połączenia, Wszystkie żądania skierowane do usług wewnętrznych przechodzą przez szyfrowany tunel.Ani Traefik ani aplikacje nie są dostępne w Internecie bez wcześniejszego filtra.

Ci, którzy wolą nie zarządzać własną siecią VPN, czasami uciekają się do Tunel Cloudflare lub Tailscale aby uzyskać dostęp do homelab bez otwierania portów. To wygodne alternatywy, chociaż jeśli prywatność jest dla Ciebie priorytetem, musisz rozważyć, jakie metadane mogą gromadzić te podmioty zewnętrzne.

Kolejną dobrą praktyką jest Zaszyfruj serwer i dyski NASRegularnie stosuj poprawki i ograniczaj automatyczne aktualizacje (wiele osób unika Watchtower na rzecz kontrolowanych aktualizacji ręcznych). Lepiej być trochę w tyle, ale z kontrolą, niż zepsuć połowę Homelaba przez aktualizację, której nie sprawdziłeś.

Jak widać, nie musisz osiągnąć poziomu „przedsiębiorstwa”, ale Tak, wskazane jest ustalenie minimalnych standardów bezpieczeństwa i dyscypliny. aby Twoje domowe laboratorium nie było sitem i stałym źródłem strachu.

Ostatecznie skonfigurowanie poważnego laboratorium domowego z Docker Compose wymaga połączenia organizacji, zdrowego rozsądku i chęci eksperymentowania: jeśli zgrupujesz usługi, dobrze zdefiniujesz sieci, udokumentujesz w Git i trochę zautomatyzujesz, otrzymasz środowisko, które możesz uruchomić za pomocą jednego polecenia, łatwo przenieść na inną maszynę i stopniowo rozbudowywać, nie stając się przy tym niekontrolowaną dżunglą.