Docker Compose u Homelabu: organizacija, profili i najbolje prakse

Informatec Digital » Sredstva » 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 ove postavke : definirajte svoje usluge u YAML-u, verzionirajte ih pomoću Gita i pokrenite cijelo okruženje jednom naredbom.

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

Praktični pristupi postavljanju Docker Composea u kućnom laboratoriju

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

S jedne strane, postoje oni koji su započeli sa samostalnim Docker Run naredbama, zatim prešli na Portainer i na kraju skočili na Docker Compose . To je tipičan scenarij: Portainer nudi izvrsnu vidljivost, korisničko sučelje, 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 konsolidirao u jedan "mega" docker-compose.yml sposoban za pokretanje apsolutno svih homelab servisa: obrnuti proxy, medija, uslužnih programa, monitoringa, LLM-ova, baza podataka... Sve u jednom stogu.

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 druge datoteke (svaka u podmapi aplikacija ili usluga). Na taj način održavate globalni pregled homelaba, ali bez mučenja s YAML datotekom od tisuću redaka koju je nemoguće pročitati.

Profili, grupiranje po funkciji i veliki kućni laboratoriji

Kada vaš kućni laboratorij počne imati 30, 40 ili 50 servisa (uključujući servise za sigurnosno kopiranje poput baza podataka, predmemorija ili indeksera), ključno ih je urediti. Tu do izražaja dolaze i grupiranje po funkcijama i korištenje Docker Compose profila.

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

• Osnovni profil: jezgra homelaba, s Traefikom kao obrnutim proxyjem i pružateljem identiteta (npr. OAuth ili Authentik) za autentifikaciju svih aplikacija pod istom 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 poput Portainera, Watchtowera (ako se koristi), Diuna, dockchecka ili sličnih za upravljanje i praćenje kontejnera i ažuriranja.
• Profil infrastrukture/praćenjaTraefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle i sve vezano uz praćenje i bilježenje.
• Eksperimentalni profili ili LLM: specifični stogovi za LLM-ove ili neobične aplikacije (ChatGPT Next Web local, LibreOffice Online itd.) koji su obično onemogućeni prema zadanim postavkama.

Ljepota profila je u tome što možete implementirati samo dio infrastrukture po potrebi. Na primjer, na mini računalu niske snage možete pokrenuti samo profil jezgre + infrastrukture, a na velikom poslužitelju s više diskova i grafičkih procesora implementirati samo profil medija.

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 konfigurirane su putem jedne globalne .env datoteke, a neke tajne vrijednosti pohranjene su u direktoriju secrets/ , što uvelike pojednostavljuje početno postavljanje.

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

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

Ovo je vječna rasprava: jedna docker-compose.yml datoteka koja sadrži sve ili više datoteka po servisu/sloggu? Pravi odgovor je obično "ovisi o tome što želite prioritetizirati: jednostavnost migracije ili jasnoću po servisu."

Oni koji zagovaraju jednu glavnu datoteku obično ističu nekoliko prednosti:

• Migracija hostova je super jednostavnaKlonirate repozitorij, kopirate .env datoteku i tajne datoteke, montirate volumene i pokrenete `docker compose up -d`. Nema potrebe ići direktorij po direktorij.
• Infrastruktura kao kodeks istine: cijela topologija kućnog laboratorija (usluge, mreže, volumeni, ovisnosti) je na jednom mjestu.
• Centralizirana ažuriranjaPromijenite verziju slike, pravila ponovnog pokretanja ili neke zapise i točno znate gdje trebate dodirnuti.

Ali ima i jasne nedostatke: ogromnu YAML datoteku je teže održavati, konflikti spajanja se povećavaju, a prilikom otklanjanja pogrešaka određenog problema, nađete se u situaciji da se snalazite u čudovištu od stotina redaka. Nije neuobičajeno osjećati se pomalo žaleći kada sve postane preveliko.

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

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

S time se svaki kontejner naziva 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, točno znate u kojoj mapi trebate tražiti.

Vizualno je puno čišće i omogućuje vam neovisno upravljanje svakom uslugom (pokretanje, zaustavljanje ili ažuriranje bez utjecaja na ostale). Nadalje, aplikacije poput Dozzlea koriste prednost odvojenih slojeva 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 stvorili drugi docker-compose alati.

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

Jedan od najpodcijenjenijih trikova je centralizacija konfiguracije u .env datotekama . Umjesto pretrpavanja docker-compose.yml datoteke 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} . To čini Compose čitljivim na prvi pogled, omogućuje 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, u nadjačavanju, nadjačati samo ono što se mijenja: portove, putanje, zastavice za otklanjanje pogrešaka itd.

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

Očito je da je verzija svega pomoću Gita obavezna ako želite da vaš kućni laboratorij bude iole profesionalan . Obično ćete imati nešto poput ovoga:

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

Odatle inicijalizirate repozitorij, potvrdujete promjene infrastrukture i ako nešto pokvari, možete se vratiti na prethodnu verziju svog Composea u sekundama . 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 laboratorijima pojavljuje se ista kombinacija: Traefik kao obrnuti proxy i centralizirani pružatelj identiteta (Auth ili Authentik) . To omogućuje izlaganje mnogih aplikacija pod poddomenama s HTTPS-om i SSO-om.

Klasičan pristup je postavljanje namjenske Docker mreže, kao što je reverse_proxy ili slična, gdje su Traefik i sve web usluge koje ćete eksterno posluživati ​​povezani. Preostali kontejneri (baze podataka, predmemorije itd.) ostaju na izoliranim internim mrežama.

Ako koristite Traefik i odvajate svoje servise u različite Docker Compose instance, morate definirati dijeljenu vanjsku 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 Traefik stog stvara mrežu traefik_default, a ostale usluge joj se dodaju putem vanjske mreže pod nazivom traefik-net. Oznake govore Traefiku koju mrežu treba koristiti za usmjeravanje prometa.

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

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

Trajnost podataka, volumeni i struktura diska

Kućni laboratorij bez trajnih podataka nije baš koristan: baze podataka, konfiguracije, mediji, dokumenti… sve mora preživjeti Docker Compose Down. Volumeni i bind mountovi su vam spas.

Mnogi ljudi organiziraju svoju pohranu 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 , upravitelji poput Radarra/Sonarra imaju pristup i preuzimanjima i medijima (za premještanje/stvaranje tvrdih poveznica), a poslužitelji poput Plexa ili Jellyfina vide samo mapu medija.

Na ovaj način primjenjujete načelo najmanjih privilegija : svaki kontejner pristupa samo onome što mu je stvarno potrebno. Jasna podjela također pomaže pri odlučivanju koje volumene ili putove 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 verziran (predlošci, Caddyfile, itd.), izostavljajući sve što je kritično ili zahtijeva puno resursa.

U nekim slučajevima korisno je koristiti tvrde veze u lancu preuzimanja: usluge poput Radarra ili Sonarra mogu povezati preuzete datoteke kako bi održale zasićenost bez dupliciranja prostora na disku. Struktura direktorija koju predlažu vodiči poput TRaSHGuides temelji se upravo na tom principu.

Automatizacija implementacija s GitHub akcijama i lokalnim runnerima

Ako želite ići korak dalje, možete automatizirati ažuriranja kućnog laboratorija pomoću CI/CD-a . Nekoliko korisnika je zamijenilo Jenkins i slične alate radnim tijekom koji koristi GitHub Actions i runner koji se samostalno hostira unutar samog kućnog laboratorija.

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

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

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

Prednosti: dodatna sigurnost (kontrolirate curenje tajni), bolja kvaliteta koda i ponovljive implementacije jednim pritiskom . A budući da koristite lokalni runner, slike i volumeni ne napuštaju vašu mrežu; jednostavno koristite GitHub sučelje za vizualizaciju cjevovoda.

Zašto Docker Compose toliko olakšava život u kućnom laboratoriju

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 usluge na drugo računalo, oslanjanje na izolirane naredbe ili konfiguracije isključivo unutar Portainera je zamka.

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

Uređivanje servisa više nije "ručna ponovna izgradnja kontejnera"; sada se radi o mijenjanju retka u datoteci, spremanju i pokretanju `docker compose up -d` . Ne morate pamtiti izvornu naredbu ili klikati kroz više Portainer zaslona.

Nadalje, ako radite s više poslužitelja (mini računala, NAS, stolna računala), izuzetno je praktično moći kopirati istu Compose datoteku na drugo računalo, prilagoditi četiri putanje i pokrenuti isti stog na različitom hardveru . Zapravo, mnogi ljudi priznaju da im je Compose, nakon straha od gubitka podataka ili kaotičnih migracija, uštedio puno vremena u kasnijim događajima.

Kao dodatni bonus, izgradnja novih usluga iz starih postaje trivijalna: na primjer, kloniranje Plex konfiguracije za postavljanje Jellyfina ponovnim korištenjem istih medijskih putova 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 dolaze 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 ovisnosti i kompajlirate, a u drugoj fazi kopirate samo potrebne artefakte na malu osnovnu sliku. Rezultat: puno manje i sigurnije konačne slike , jer ne prenose nepotrebne alate ili biblioteke.

Na strani Composea 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 aplikacije koje intenzivno koriste resurse da zauzmu resurse. U Homelabsu to pomaže u sprječavanju da pogrešno konfigurirana usluga ošteti ostatak sustava.

Ne zaboravite pravila ponovnog pokretanja (ponovno pokretanje: uvijek, osim ako nije zaustavljeno, prilikom kvara): njima osiguravate da se kritične usluge (obrnuti proxy, VPN, ključne baze podataka) automatski ponovno pokrenu nakon ponovnog pokretanja ili jednokratnog kvara.

Konačno, preporučljivo je zakazati periodične zadatke čišćenja naredbama 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 time oslobodio prostor na disku.

Zdravstvene usluge, bilježenje i praćenje

Kako biste spriječili da vaš kućni laboratorij postane crna kutija, važno je poraditi na tri ključna aspekta: provjerama ispravnosti, kontroliranom zapisivanju i praćenju . Docker Compose vam omogućuje deklariranje provjera ispravnosti po servisu (pomoću naredbi poput `curl -f http://localhost` ili određenih skripti) koje određuju je li kontejner ispravan.

To vam omogućuje da osigurate da samo "zdravi" kontejneri primaju promet (na primjer putem Traefika) i da se, ako prestanu reagirati, ponovno pokrenu prema konfiguriranoj politici. To značajno povećava otpornost uz minimalan napor.

Što se tiče logova, podešavanje upravljačkog programa json-file s ograničenjima za maksimalnu veličinu i maksimalnu veličinu datoteke sprječava punjenje diska gigabajtima zaboravljenih logova. Web alati poput Dozzlea pomažu vam u pregledavanju logova svih spremnika iz preglednika, što je vrlo praktično za otklanjanje pogrešaka određenih usluga.

Za metrike i kontinuirano praćenje, klasična kombinacija je cAdvisor + Prometheus + Grafana . cAdvisor izlaže statistiku korištenja CPU-a, memorije, diska i mreže po kontejneru; Prometheus ih periodički prikuplja, a Grafana ih prikazuje na atraktivnim nadzornim 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 sustav sigurnosne kopije poput Duplicatija za kopiranje kritičnih podataka na druge diskove ili u oblak. Na taj način znate što se događa i ako nešto pođe po zlu, ne gubite ono što je važno.

Sigurnost i udaljeni pristup kućnom laboratoriju

Međutim, s obzirom na to da sami postavljate, sigurnost nije opcionalna. Mnogi ljudi odlučuju se ne izlagati svoj NAS ili njegove usluge izravno vanjskom svijetu , ograničavajući udaljeni pristup putem VPN-a (WireGuard je vrlo popularna opcija zbog svojih performansi i jednostavnosti).

U ovom modelu, usmjerivač djeluje kao pristupnik: samo se nasumični port otvara prema VPN poslužitelju, a nakon povezivanja, svi zahtjevi prema internim uslugama 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 svom kućnom laboratoriju bez otvaranja portova. To 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 , redovito primjenjivanje zakrpa i ograničavanje automatskih ažuriranja (mnogi izbjegavaju Watchtower u korist kontroliranih ručnih ažuriranja). Bolje je malo kasniti, ali imati kontrolu, nego slomiti pola Homelaba zbog ažuriranja koje niste provjerili.

Kao što vidite, ne morate dosegnuti "poduzeće" razinu, ali je preporučljivo uspostaviti minimalnu razinu sigurnosti i discipline kako vaš kućni laboratorij ne bi bio 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 u Gitu i malo automatizirate, dobit ćete okruženje koje možete započeti jednom naredbom, lako migrirati na drugo računalo i malo po malo proširiti bez da postane nekontrolirana džungla.