Docker Compose u Homelabu: organizacija, profili i najbolje prakse

Informatec Digital » Resursi » Docker Compose u Homelabu: organizacija, profili i najbolje prakse

Postavljanje modernog kućnog laboratorija s kontejnerima postalo je omiljeni hobi mnogih tehnoloških stručnjaka. Docker Compose je gotovo uvijek u središtu ovog podešavanja : definirajte svoje servise u YAML-u, verzionirajte ih pomoću Gita i pokrenite cijelo okruženje jednom naredbom.

Međutim, kada počnete rasti, stvari se mijenjaju: prelazite sa dva ili tri kontejnera na desetine servisa, internih mreža, obrnutih proxyja, baza podataka i CI runnera . Tada se postavlja veliko pitanje: jedna ogromna Docker Compose instanca ili mnogo malih datoteka? Kako da organizujem profile, mreže, sigurnosne kopije, sigurnost i, uz to, da olakšam migraciju?

Praktični pristupi postavljanju Docker Compose-a u kućnoj laboratoriji

U praksi, ljudi koji već neko vrijeme koriste Homelabs obično rade s tri različita Compose organizacijska modela, svaki sa svojim prednostima i nedostacima. Odabir pravog pristupa štedi vam mnogo problema prilikom skaliranja ili migracije na novi računar.

S jedne strane, postoje oni koji su počeli sa samostalnim Docker Run naredbama, zatim prešli na Portainer, i na kraju prešli na Docker Compose . To je tipičan scenario: Portainer nudi odličnu vidljivost, korisnički interfejs, predloške itd., ali u konačnici, uređivanje složenih parametara ili migracija konfiguracija postaje gnjavaža ako nemate ništa u datotekama.

Na suprotnoj krajnosti je onaj koji je sve konsolidovao u jedan "mega" docker-compose.yml sposoban da pokreće apsolutno sve homelab servise: obrnuti proxy, medije, uslužne programe, monitoring, LLM-ove, baze podataka... Sve u jednom steku.

Između toga, mnogi korisnici se drže mješovitog pristupa: nekoliko malih docker-compose.yml datoteka grupiranih po kontekstu (npr. mediji, infrastruktura, produktivnost, praćenje), sve unutar istog repozitorija i obično dijele globalne varijable okruženja.

Prilično elegantno rješenje spaja oba svijeta: "root" docker-compose koji uključuje i druge datoteke (svaka u podfolderu aplikacija ili usluga). Na ovaj način održavate globalni pregled kućne laboratorije, ali bez mučenja s YAML datotekom od hiljadu redova koju je nemoguće pročitati.

Profili, grupiranje po funkciji i veliki kućni laboratoriji

Kada vaša kućna laboratorija počne da se približava broju od 30, 40 ili 50 servisa (uključujući servise za pravljenje sigurnosnih kopija poput baza podataka, keš memorija ili indeksera), ključno je da ih sredite. Tu do izražaja dolaze i grupisanje po funkcijama i korištenje Docker Compose profila.

Vrlo uobičajen obrazac je grupiranje svega u jedan Compose "projekat", ali logički podijeljen po profilima. Na primjer:

• Osnovni profil: homelab jezgro, sa Traefik-om kao obrnutim proxyjem i provajderom identiteta (npr. OAuth ili Authentik) za autentifikaciju svih aplikacija pod istim domenom putem HTTPS-a.
• Medijski profilServisi poput Plexa, Sonarra, Radarra, Ombija, SABnzbda ili qBittorrenta, odgovorni su za prikupljanje, preuzimanje i posluživanje multimedijskog sadržaja.
• Profil komunalnih uslugaAlati kao što su Portainer, Watchtower (ako se koristi), Diun, dockcheck ili slični za upravljanje i praćenje kontejnera i ažuriranja.
• Profil infrastrukture/monitoringaTraefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle i sve što je vezano za praćenje i evidentiranje.
• Eksperimentalni profili ili LLM: specifični stekovi za LLM-ove ili neobične aplikacije (ChatGPT Next Web local, LibreOffice Online, itd.) koji su obično podrazumevano onemogućeni.

Ljepota profila je u tome što možete implementirati samo dio infrastrukture po potrebi. Na primjer, možete pokrenuti samo profil jezgre + infrastrukture na mini računaru niske snage, a medijski profil implementirati samo na velikom serveru s više diskova i GPU-a.

U dobro dizajniranim repozitorijima, obično postoji "glavna" datoteka docker-compose.yml u korijenu koja koristi include za pohranjivanje pojedinačnih datoteka u mapu apps/ ili services/ . Osim toga, gotovo sve usluge su konfigurirane putem jedne globalne .env datoteke, a neke tajne vrijednosti su pohranjene u direktoriju secrets/ , što znatno pojednostavljuje početno podešavanje.

Slijedeći ovaj obrazac, upravljanje kućnom laboratorijom se u osnovi svodi na uređivanje .env datoteke i tajni, omogućavanje ili onemogućavanje profila i odlučivanje koje servise pokrenuti na svakom hostu . Ovo je idealno ako ćete implementirati isti skup aplikacija na više mašina.

Jedna ogromna docker-compose datoteka u odnosu na nekoliko malih datoteka

Ovo je vječna debata: jedna docker-compose.yml datoteka koja sadrži sve ili više datoteka po servisu/steku? Pravi odgovor je obično "zavisi od toga šta želite da prioritetizirate: jednostavnost migracije ili jasnoću po servisu."

Oni koji se zalažu za jednu glavnu datoteku obično ističu nekoliko prednosti:

• Migracija hostova je super jednostavnaKlonirate repozitorij, kopirate .env datoteku i tajne, montirate volumene i pokrenete `docker compose up -d`. Nema potrebe za pregledavanjem direktorija.
• Infrastruktura kao kodeks istine: cijela topologija kućne laboratorije (servisi, mreže, volumeni, zavisnosti) je na jednom mjestu.
• Centralizirana ažuriranjaPromijenite verziju slike, politiku ponovnog pokretanja ili neko evidentiranje i tačno znate gdje trebate dodirnuti.

Ali ima i očite nedostatke: ogromnu YAML datoteku je teže održavati, konflikti spajanja se povećavaju, a prilikom otklanjanja grešaka određenog problema, nađete se u situaciji da se krećete kroz čudovište od stotina redova. Nije neuobičajeno da osjetite malo žaljenja kada sve postane preveliko.

Drugi pristup je imati docker-compose.yml datoteku po aplikaciji ili po logičkom steku , unutar strukture poput ove:

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

Na ovaj način, svaki kontejner se zove nešto poput bookstack-app-1 ili traefik-reverse-proxy-1 , što vam pomaže da brzo pronađete probleme: ako se kontejner bookstack-app-1 sruši, tačno znate u kojoj mapi da tražite.

Vizualno je mnogo čistije i omogućava vam da upravljate svakom uslugom nezavisno (pokretanje, zaustavljanje ili ažuriranje bez utjecaja na ostale). Nadalje, aplikacije poput Dozzlea koriste prednost odvojenih stekova za bolju organizaciju logova.

Nedostatak je što, ako previše odvojite sve, koordinacija između zajedničkih servisa (kao što su Traefik ili dijeljene mreže) zahtijeva malo više pažnje : morate deklarirati vanjske mreže, specifične Traefik oznake i zapamtiti nomenklaturu mreža koje su kreirali drugi docker-compose alati.

Najbolje prakse s .env datotekama, nadjačavanjima i kontrolom verzija

Jedan od najpotcijenjenijih trikova je centralizacija konfiguracije u .env datotekama . Umjesto pretrpavanja vašeg docker-compose.yml fajla varijablama okruženja, definirate nešto poput ovoga:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

A zatim se u YAML-u referenciraju kao ${DB_USERNAME} ili ${DB_PASSWORD} . Ovo čini Compose čitljivim na prvi pogled, omogućava vam dijeljenje varijabli između više servisa i, što je najvažnije, pohranjuje lozinke u zasebnu datoteku (koju možete isključiti iz Gita).

Za različita okruženja (produkcija, testiranje, razvoj), vrlo je korisno koristiti docker-compose.override.yml . Ideja je imati osnovnu datoteku docker-compose.yml i, prilikom prepisivanja, prepisivati ​​samo ono što se mijenja: portove, putanje, debug zastavice itd.

Na primjer, u razvoju možete učitati prepisivanje gdje izlažete drugi port, omogućavate otklanjanje grešaka i montirate lokalni izvorni kod . Ne dirate glavni YAML, ali prilagođavate stek okruženju u kojem ga pokrećete.

Očigledno je da je ažuriranje verzija svega pomoću Gita obavezno ako želite da vaša kućna laboratorija bude iole profesionalna . Obično ćete imati nešto poput ovoga:

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

Odatle inicijalizirate repozitorij, potvrđujete promjene infrastrukture i ako nešto pokvari, možete se vratiti na prethodnu verziju svog Compose-a za nekoliko sekundi . Za ambiciozne kućne laboratorije, ovo nije samo opcija; to je jedini način da se izbjegne pretjerano korištenje.

Mreže, Traefik i izloženost sigurnim uslugama

U gotovo svim umjereno naprednim kućnim laboratorijama pojavljuje se ista kombinacija: Traefik kao obrnuti proxy i centralizirani pružatelj identiteta (Auth ili Authentik) . Ovo omogućava izlaganje mnogih aplikacija pod poddomenama putem HTTPS-a i SSO-a.

Klasičan pristup je postavljanje namjenske Docker mreže, kao što je reverse_proxy ili slična, gdje su Traefik i svi web servisi koje ćete eksterno pružati povezani. Preostali kontejneri (baze podataka, keš memorije itd.) ostaju na izolovanim internim mrežama.

Ako koristite Traefik i odvajate svoje servise u različite Docker Compose instance, potrebno je da definišete zajedničku eksternu mrežu . Nešto poput ovoga:

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

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

Ovdje je mreža traefik_default kreirana od strane Traefik steka, a ostali servisi se dodaju na nju putem eksterne mreže pod nazivom traefik-net. Oznake govore Traefiku koju mrežu treba koristiti za usmjeravanje prometa.

Kada jedan stek uključuje backend servise (na primjer, web kontejner i njegovu bazu podataka), možete ih povezati na dijeljenu zadanu mrežu i odobriti web kontejneru pristup samo Traefik mreži . Baza podataka će imati oznaku postavljenu na `traefik.enable=false` tako da je Traefik ignorira.

Ova vrsta podešavanja nudi dvije ključne prednosti: izolaciju između servisa i kontroliranu izloženost . Samo kontejneri koje označite Traefik oznakama i koji se nalaze na proxy mreži postaju dostupni izvana.

Perzistentnost podataka, volumeni i struktura diska

Kućna laboratorija bez trajnih podataka nije baš korisna: baze podataka, konfiguracije, mediji, dokumenti... sve mora preživjeti Docker Compose Down. Volumeni i bind mountovi su vaš spas.

Mnogi ljudi organiziraju svoje skladištenje koristeći strukturu poput ove:

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

Ideja je da programi za preuzimanje (qBittorrent, SABnzbd, itd.) vide samo mapu preuzimanja , menadžeri poput Radarr/Sonarr imaju pristup i preuzimanjima i medijima (za premještanje/kreiranje tvrdih linkova), a serveri poput Plexa ili Jellyfina vide samo mapu medija.

Na ovaj način primjenjujete princip najmanjih privilegija : svaki kontejner pristupa samo onome što mu je zaista potrebno. Jasna podjela također pomaže pri odlučivanju koje volumene ili putanje sigurnosno kopirati u oblak ili na vanjske diskove.

Direktorij srv se obično koristi za pohranjivanje konfiguracija aplikacija (na primjer, /srv/jellyfin/config, /srv/traefik, /srv/paperless, itd.). Obično je djelomično verzioniran (predlošci, Caddyfile, itd.), izostavljajući sve što je kritično ili zahtijeva puno resursa.

U nekim slučajevima, korisno je koristiti hardlinkove u lancu preuzimanja: servisi poput Radarra ili Sonarra mogu povezati preuzete datoteke kako bi održali početni kod bez dupliranja prostora na disku. Struktura direktorija koju predlažu vodiči poput TRaSHGuides zasniva se upravo na ovom principu.

Automatizacija implementacija pomoću GitHub Actions i lokalnih runnera

Ako želite ići korak dalje, možete automatizirati ažuriranja kućne laboratorije pomoću CI/CD-a . Nekoliko korisnika je zamijenilo Jenkins i slične alate radnim tokom koristeći GitHub Actions i runner koji se samostalno hostuje unutar same kućne laboratorije.

Mehanizam je jednostavan: svaki put kada pošaljete promjene na glavnu granu vašeg homelab repozitorija, pokreće se GitHub Actions workflow koji izvršava testove, lintere i, ako sve prođe dobro, implementira promjene na server.

Tipičan tok rada uključuje korake kao što su:

• Tajni skener tipa Gitleaks: u slučaju da ste slučajno prenijeli lozinke ili tokene u repozitorij.
• podstava YAML ili infrastrukturnog koda, kako bi se održao čitljiv i konzistentan format.
• Ažuriranje repozitorija unutar samog homelaba:git pull na ciljnom serveru.
• Kontrolisana rekreacija kontejneraZaustavite stare, pokrenite nove i provjerite status.

Prednosti: dodatna sigurnost (kontrolišete curenje tajni), bolji kvalitet koda i ponovljiva implementacija jednim pritiskom . A budući da koristite lokalni runner, slike i volumeni ne napuštaju vašu mrežu; jednostavno koristite GitHub interfejs za vizualizaciju cjevovoda.

Zašto Docker Compose znatno olakšava život u kućnoj laboratoriji

Mnogi ljudi su godinama oslanjali na Docker Run i Portainer sve dok, nakon incidenta ili migracije, nisu bili prisiljeni preispitati svoj pristup. Kada izgubite host ili morate premjestiti servise na drugu mašinu, oslanjanje na izolirane naredbe ili konfiguracije isključivo unutar Portainera je zamka.

Velika razlika kada pređete na Compose je u tome što cijela definicija servisa postaje tekst : volumeni, portovi, mreže, oznake, varijable… Sve u YAML datoteci koju možete kopirati, dijeliti, verzionirati i ponovo koristiti.

Uređivanje servisa više nije "ručno ponovno izgrađivanje kontejnera"; sada se radi o modificiranju linije u datoteci, spremanju i pokretanju `docker compose up -d` . Ne morate pamtiti originalnu naredbu ili klikati kroz više Portainer ekrana.

Nadalje, ako radite s više servera (mini PC-ji, NAS-ovi, desktop računari), izuzetno je praktično moći kopirati istu Compose datoteku na drugu mašinu, prilagoditi četiri putanje i pokrenuti isti stek na različitom hardveru . U stvari, mnogi ljudi priznaju da im je, nakon straha od gubitka podataka ili haotičnih migracija, Compose uštedio mnogo vremena u kasnijim događajima.

Kao dodatni bonus, izgradnja novih servisa iz starih postaje trivijalna: na primjer, kloniranje Plex konfiguracije za postavljanje Jellyfina ponovnim korištenjem istih medijskih putanja i uređaja za transkodiranje traje samo nekoliko minuta ako to učinite kopiranjem YAML blokova.

Optimizacija: kontekst izgradnje, višefazne izgradnje i resursi

Iako mnogi Homelab kontejneri potiču iz javnih slika, u nekim slučajevima ćete ih sami kompajlirati. U tim slučajevima, važno je upravljati kontekstom izgradnje : nemojte prenositi cijeli repozitorij nefiltriran, već se ograničite na mapu projekta (koristeći snažnu direktivu `.dockerignore`) kako biste osigurali brze i lagane izgradnje.

Još jedna vrlo korisna tehnika je korištenje višefaznih izrada u vašim Docker datotekama: u prvoj fazi instalirate zavisnosti i kompajlirate, a u drugoj fazi kopirate samo potrebne artefakte na malu osnovnu sliku. Rezultat: mnogo manje i sigurnije konačne slike , jer ne prenose nepotrebne alate ili biblioteke.

Na strani Compose-a, imate mogućnost definiranja ograničenja CPU-a i RAM-a (posebno u Swarm okruženjima ili kada Docker poštuje te parametre) kako biste spriječili da aplikacije koje intenzivno koriste resurse zauzmu resurse. U Homelabs-u, ovo pomaže u sprječavanju da pogrešno konfigurirana usluga paralizira ostatak sistema.

Ne zaboravite politike ponovnog pokretanja (restart: always, unless-stopped, on-failure): s njima osiguravate da se kritične usluge (obrnuti proxy, VPN, ključne baze podataka) automatski ponovo pokrenu nakon ponovnog pokretanja ili jednokratnog kvara.

Konačno, preporučljivo je zakazati periodične zadatke čišćenja pomoću naredbi kao što su docker image prune, docker container prune i docker volume prune kako bi se uklonili ostaci starih verzija, zaustavljeni kontejneri ili osiroćeni volumeni i na taj način oslobodio prostor na disku.

Zdravstvene usluge, evidentiranje i praćenje

Da biste spriječili da vaša kućna laboratorija postane crna kutija, važno je poraditi na tri ključna aspekta: provjerama ispravnosti, kontroliranom evidentiranju i praćenju . Docker Compose vam omogućava da deklarirate provjere ispravnosti po servisu (koristeći naredbe poput `curl -f http://localhost` ili specifične skripte) koje određuju da li je kontejner ispravan.

Ovo vam omogućava da osigurate da samo "zdravi" kontejneri primaju promet (na primjer, putem Traefik-a) i da se, ako prestanu reagirati, ponovo pokrenu u skladu s konfiguriranom politikom. Ovo značajno povećava otpornost uz minimalan napor.

Što se tiče logova, podešavanje drajvera json-file-a sa ograničenjima za maksimalnu veličinu i maksimalnu veličinu datoteke sprečava da se disk napuni gigabajtima zaboravljenih logova. Web alati poput Dozzle-a pomažu vam da pregledate logove svih kontejnera iz pretraživača, što je veoma praktično za otklanjanje grešaka u određenim servisima.

Za metriku i kontinuirano praćenje, klasična kombinacija je cAdvisor + Prometheus + Grafana . cAdvisor prikazuje statistiku korištenja CPU-a, memorije, diska i mreže po kontejneru; Prometheus ih periodično prikuplja, a Grafana ih prikazuje na atraktivnim kontrolnim pločama, s upozorenjima ako dođe do naglih porasta.

Dobro postavljen kućni laboratorij obično uključuje Uptime Kuma za provjere dostupnosti (HTTP, ICMP, TCP, itd.) i automatizirani sistem za sigurnosno kopiranje poput Duplicatija za kopiranje kritičnih podataka na druge diskove ili u oblak. Na taj način znate šta se dešava i ako nešto pođe po zlu, ne gubite ono što je važno.

Sigurnost i udaljeni pristup kućnoj laboratoriji

Međutim, čak i ako sami instalirate sistem, sigurnost nije opcionalna. Mnogi ljudi odlučuju se da ne izlažu svoj NAS ili njegove usluge direktno vanjskom svijetu , ograničavajući udaljeni pristup putem VPN-a (WireGuard je vrlo popularna opcija zbog svojih performansi i jednostavnosti).

U ovom modelu, ruter djeluje kao gateway: samo se nasumični port otvara prema VPN serveru, a nakon povezivanja, svi zahtjevi prema internim servisima prolaze kroz šifrirani tunel . Ni Traefik ni aplikacije nisu izložene internetu bez ovog prethodnog filtriranja.

Oni koji ne žele sami upravljati svojim VPN-om ponekad se okreću Cloudflare Tunnelu ili Tailscaleu kako bi pristupili svojoj kućnoj laboratoriji bez otvaranja portova. Ovo su praktične alternative, iako ako vam je privatnost glavni prioritet, morat ćete uzeti u obzir koje metapodatke te treće strane mogu prikupljati.

Još jedna dobra praksa je šifriranje servera i NAS diskova , redovno primjenjivanje zakrpa i ograničavanje automatskih ažuriranja (mnogi izbjegavaju Watchtower u korist kontroliranih ručnih ažuriranja). Bolje je biti malo u zaostatku, ali s kontrolom, nego slomiti pola Homelaba zbog ažuriranja koje niste provjerili.

Kao što vidite, ne morate dostići "preduzeće" nivo, ali je preporučljivo uspostaviti minimalni nivo sigurnosti i discipline kako vaša kućna laboratorija ne bi bila sito ili stalni izvor straha.

U konačnici, postavljanje ozbiljnog kućnog laboratorija s Docker Composeom je mješavina organizacije, zdravog razuma i spremnosti na eksperimentiranje: ako grupirate servise, dobro definirate mreže, dokumentirate ih u Gitu i malo automatizirate, dobit ćete okruženje koje možete započeti jednom naredbom, lako migrirati na drugu mašinu i malo po malo proširiti, a da se ne pretvori u nekontroliranu džunglu.