Docker Compose v Homelabe: organizácia, profily a osvedčené postupy

Informatec Digital » Zdroje » Docker Compose v Homelabe: organizácia, profily a osvedčené postupy

Vytvorenie moderného domáceho laboratória s kontajnermi sa stalo obľúbeným koníčkom mnohých technikov. Docker Compose je takmer vždy srdcom tohto nastavenia : definujte svoje služby v YAML, verzujte ich pomocou Gitu a spustite celé prostredie jediným príkazom.

Keď však začnete rásť, veci sa zmenia: z dvoch alebo troch kontajnerov prejdete na desiatky služieb, interných sietí, reverzných proxy, databáz a CI runnerov . Vtedy vyvstáva veľká otázka: jedna obrovská inštancia Docker Compose alebo veľa malých súborov? Ako usporiadam profily, siete, zálohy, zabezpečenie a navyše uľahčím migráciu?

Reálne prístupy k nastaveniu Docker Compose v domácom laboratóriu

V praxi ľudia, ktorí už nejaký čas používajú Homelabs, zvyčajne pracujú s tromi rôznymi organizačnými modelmi Compose, pričom každý má svoje výhody a nevýhody. Výber správneho prístupu vám ušetrí veľa problémov pri škálovaní alebo migrácii na nový počítač.

Na jednej strane sú tí, ktorí začali so samostatnými príkazmi Docker Run, potom prešli na Portainer a nakoniec na Docker Compose . Je to typický scenár: Portainer ponúka skvelý prehľad, užívateľsky prívetivé rozhranie, šablóny atď., ale v konečnom dôsledku sa úprava zložitých parametrov alebo migrácia konfigurácií stáva problémom, ak nemáte nič v súboroch.

Na opačnom extréme je ten, kto všetko zlúčil do jedného „mega“ docker-compose.yml, ktorý je schopný spúšťať úplne všetky služby homelabu: reverznú proxy, médiá, utility, monitorovanie, LLM, databázy... Všetko v jednom stacku.

Mnoho používateľov sa drží zmiešaného prístupu: niekoľko malých súborov docker-compose.yml zoskupených podľa kontextu (napr. médiá, infraštruktúra, produktivita, monitorovanie), všetky v tom istom repozitári a zvyčajne zdieľajú globálne premenné prostredia.

Pomerne elegantné riešenie spája oba svety: „koreňový“ docker-compose, ktorý obsahuje ďalšie súbory (každý v podpriečinku aplikácií alebo služieb). Týmto spôsobom si zachováte globálny pohľad na homelab, ale bez toho, aby ste trpeli tisícriadkovým YAML súborom, ktorý sa nedá prečítať.

Profily, zoskupovanie podľa funkcie a rozsiahle domáce laboratóriá

Keď váš domáci lab začne dosahovať 30, 40 alebo 50 služieb (vrátane zálohovacích služieb, ako sú databázy, vyrovnávacie pamäte alebo indexátory), je nevyhnutné v nich zaviesť poriadok. Tu prichádza do úvahy zoskupovanie podľa funkcie aj používanie profilov Docker Compose.

Veľmi bežným vzorom je zoskupiť všetko do jedného „projektu“ v nástroji Compose, ale logicky rozdeleného podľa profilov. Napríklad:

• Základný profil: jadro homelabu s Traefikom ako reverzným proxy a poskytovateľom identity (napr. OAuth alebo Authentik) na autentifikáciu všetkých aplikácií v rámci rovnakej domény pomocou HTTPS.
• Mediálny profilSlužby ako Plex, Sonarr, Radarr, Ombi, SABnzbd alebo qBittorrent, zodpovedné za kurátorstvo, sťahovanie a poskytovanie multimediálneho obsahu.
• Profil verejných služiebNástroje ako Portainer, Watchtower (ak sa používa), Diun, dockcheck alebo podobné na správu a monitorovanie kontajnerov a aktualizácií.
• Profil infraštruktúry/monitorovaniaTraefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle a všetko, čo súvisí s monitorovaním a logovaním.
• Experimentálne profily alebo LLMšpecifické balíky pre LLM alebo kuriózne aplikácie (ChatGPT Next Web local, LibreOffice Online atď.), ktoré sú zvyčajne štandardne vypnuté.

Krása profilov spočíva v tom, že môžete podľa potreby nasadiť iba časť infraštruktúry . Napríklad na mini PC s nízkou spotrebou energie môžete spustiť iba profil jadra + infraštruktúry a na veľkom serveri s väčším počtom diskov a grafických kariet nasadiť iba profil médií.

V dobre navrhnutých repozitároch sa v koreňovom adresári zvyčajne nachádza „hlavný“ súbor docker-compose.yml, ktorý pomocou metódy include vkladá jednotlivé súbory do priečinka apps/ alebo services/ . Okrem toho sú takmer všetky služby konfigurované prostredníctvom jedného globálneho súboru .env a niektoré tajné identifikátory sú uložené v adresári secrets/ , čo výrazne zjednodušuje počiatočné nastavenie.

Podľa tohto vzoru sa správa domáceho laboratória v podstate redukuje na úpravu súboru .env a tajných kódov, povolenie alebo zakázanie profilov a rozhodnutie, ktoré služby sa majú spustiť na každom hostiteľovi . Toto je ideálne, ak chcete nasadiť rovnakú sadu aplikácií na viacero počítačov.

Jeden obrovský súbor Docker-Compose oproti niekoľkým malým súborom

Toto je večná debata: jeden súbor docker-compose.yml obsahujúci všetko alebo viacero súborov na službu/stack? Skutočná odpoveď zvyčajne znie „záleží na tom, čo chcete uprednostniť: jednoduchosť migrácie alebo prehľadnosť pre každú službu“.

Tí, ktorí zástancovia jedného hlavného súboru, zvyčajne zdôrazňujú niekoľko výhod:

• Migrácia hostiteľov je super jednoducháNaklonujete repozitár, skopírujete súbor .env a tajné kódy, pripojíte zväzky a spustíte príkaz `docker compose up -d`. Nie je potrebné prechádzať adresár po adresári.
• Infraštruktúra ako kód pravdyCelá topológia domáceho laboratória (služby, siete, zväzky, závislosti) je na jednom mieste.
• Centralizované aktualizácie: zmeníte verziu obrazu, politiku reštartu alebo nejaké protokolovanie a presne viete, kde sa dotknúť.

Má to však aj jasné nevýhody: obrovský YAML súbor sa ťažšie udržiava, zvyšuje sa počet konfliktov pri zlúčení a pri ladení konkrétneho problému sa ocitnete v situácii, keď sa musíte pohybovať v obrovskom množstve stoviek riadkov. Nie je nezvyčajné cítiť trochu ľútosti, keď sa všetko príliš zväčší.

Druhým prístupom je mať súbor docker-compose.yml pre každú aplikáciu alebo každý logický zásobník v rámci štruktúry podobnej tejto:

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

Vďaka tomu je každý kontajner pomenovaný niečo ako bookstack-app-1 alebo traefik-reverse-proxy-1 , čo vám pomôže rýchlo lokalizovať problémy: ak kontajner bookstack-app-1 zlyhá, presne viete, v ktorom priečinku máte hľadať.

Vizuálne je to oveľa prehľadnejšie a umožňuje vám spravovať každú službu nezávisle (spúšťať, zastavovať alebo aktualizovať ju bez ovplyvnenia ostatných). Okrem toho aplikácie ako Dozzle využívajú samostatné zásobníky na lepšiu organizáciu protokolov.

Nevýhodou je, že ak všetko príliš oddelíte, koordinácia medzi spoločnými službami (ako napríklad Traefik alebo zdieľané siete) si vyžaduje trochu viac starostlivosti : musíte deklarovať externé siete, špecifické označenia Traefik a pamätať si nomenklatúru sietí vytvorených inými nástrojmi Docker-Compose.

Najlepšie postupy s .env, prepísaniami a správou verzií

Jedným z najviac podceňovaných trikov je centralizácia konfigurácie v súboroch .env . Namiesto zahltenia súboru docker-compose.yml premennými prostredia definujete niečo takéto:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

A potom sa v YAML odkazujú ako ${DB_USERNAME} alebo ${DB_PASSWORD} . Vďaka tomu je Compose čitateľný na prvý pohľad, umožňuje zdieľať premenné medzi viacerými službami a, čo je najdôležitejšie, ukladá heslá do samostatného súboru (ktorý môžete vylúčiť z Gitu).

Pre rôzne prostredia (produkčné, testovacie, vývojové) je veľmi užitočné využiť docker-compose.override.yml . Cieľom je mať základný súbor docker-compose.yml a pri prepísaní prepísať iba to, čo sa zmení: porty, cesty, ladiace príznaky atď.

Napríklad, vo vývoji môžete načítať prepísanie, kde sprístupníte iný port, povolíte ladenie a pripojíte lokálny zdrojový kód . Nedotýkate sa hlavného YAML súboru, ale prispôsobujete zásobník prostrediu, v ktorom ho spúšťate.

Samozrejme, ak chcete, aby bol váš domáci laboratórium čo i len trochu profesionálny, je verzovanie všetkého pomocou Gitu nevyhnutné . Zvyčajne budete mať niečo takéto:

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

Odtiaľ inicializujete repozitár, zadáte zmeny infraštruktúry a ak sa niečo pokazí, môžete sa v priebehu niekoľkých sekúnd vrátiť k predchádzajúcej verzii vášho Compose . Pre ambiciózne domáce laby to nie je len možnosť; je to jediný spôsob, ako sa vyhnúť prehnanému náporu.

Siete, Traefik a bezpečné vystavenie službám

Takmer vo všetkých mierne pokročilých domácich laboch sa objavuje rovnaká kombinácia: Traefik ako reverzná proxy a centralizovaný poskytovateľ identity (Auth alebo Authentik) . To umožňuje sprístupniť mnoho aplikácií v subdoménach s HTTPS a SSO.

Klasickým prístupom je nastavenie vyhradenej siete Docker, ako napríklad reverse_proxy alebo podobnej, kde sú pripojené Traefik a všetky webové služby, ktoré budete externe poskytovať. Zvyšné kontajnery (databázy, vyrovnávacie pamäte atď.) zostávajú v izolovaných interných sieťach.

Ak používate Traefik a oddeľujete svoje služby do rôznych inštancií Docker Compose, musíte definovať zdieľanú externú sieť . Niečo ako toto:

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

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

V tomto prípade je sieť traefik_default vytvorená zásobníkom Traefik a ostatné služby sú do nej pridané prostredníctvom externej siete s názvom traefik-net. Návestia hovoria Traefiku, ktorú sieť má použiť na smerovanie prevádzky.

Keď jeden zásobník obsahuje backendové služby (napríklad webový kontajner a jeho databázu), môžete ich pripojiť k zdieľanej predvolenej sieti a udeliť webovému kontajneru prístup iba k sieti Traefik . Databáza bude mať označenie nastavené na `traefik.enable=false`, takže Traefik ho bude ignorovať.

Tento typ nastavenia ponúka dve kľúčové výhody: izoláciu medzi službami a kontrolovanú expozíciu . Zvonku budú prístupné iba kontajnery, ktoré označíte štítkami Traefik a ktoré sa nachádzajú v proxy sieti.

Perzistencia dát, zväzky a štruktúra disku

Domáce laboratórium bez perzistentných dát nie je veľmi užitočné: databázy, konfigurácie, médiá, dokumenty… všetko musí prežiť Docker Compose Down. Zväzky a viazané pripojenia sú vašou záchranou.

Mnoho ľudí si organizuje úložný priestor pomocou tejto štruktúry:

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

Myšlienka je taká, že sťahovacie programy (qBittorrent, SABnzbd atď.) vidia iba priečinok so stiahnutými súbormi , správcovia ako Radarr/Sonarr majú prístup k stiahnutým súborom aj médiám (na presun/vytvorenie pevných odkazov) a servery ako Plex alebo Jellyfin vidia iba priečinok s médiami.

Týmto spôsobom uplatňujete princíp najmenších privilégií : každý kontajner pristupuje iba k tomu, čo skutočne potrebuje. Jasné oddelenie tiež pomáha pri rozhodovaní o tom, ktoré zväzky alebo cesty zálohovať do cloudu alebo na externé disky.

Adresár srv sa zvyčajne používa na ukladanie konfigurácií aplikácií (napríklad /srv/jellyfin/config, /srv/traefik, /srv/paperless atď.). Zvyčajne je čiastočne verzovaný (šablóny, Caddyfile atď.), čím sa vynechá všetko kritické alebo náročné na zdroje.

V niektorých prípadoch je užitočné použiť v reťazci sťahovania pevné odkazy : služby ako Radarr alebo Sonarr dokážu prepojiť stiahnuté súbory, aby zachovali nasýtenie bez duplikovania miesta na disku. Štruktúra adresárov navrhnutá sprievodcami ako TRaSHGuides je založená práve na tomto princípe.

Automatizácia nasadení pomocou akcií GitHub a lokálnych runnerov

Ak chcete zájsť ešte o krok ďalej, môžete automatizovať aktualizácie domáceho laboratória pomocou CI/CD . Niekoľko používateľov nahradilo Jenkins a podobné nástroje pracovným postupom pomocou akcií GitHub a runnera hostovaného priamo v samotnom domácom labe.

Mechanizmus je jednoduchý: vždy, keď odošlete zmeny do hlavnej vetvy vášho repozitára homelab, spustí sa pracovný postup GitHub Actions, ktorý vykoná testy, lintery a ak všetko pôjde dobre, nasadí zmeny na server.

Typický pracovný postup zahŕňa kroky ako:

• Tajný skener typu Gitleaks: v prípade, že ste omylom nahrali heslá alebo tokeny do repozitára.
• Podšívka YAML alebo infraštruktúrneho kódu, aby sa zachoval čitateľný a konzistentný formát.
• Aktualizácia repozitára v samotnom homelabe:git pull na cieľovom serveri.
• Riadená rekonštrukcia kontajnerovzastavte staré, spustite nové a skontrolujte ich stav.

Výhody: zvýšené zabezpečenie (kontrolujete úniky tajomstiev), lepšia kvalita kódu a opakovateľné nasadenia jediným stlačením tlačidla . A keďže používate lokálny runner, obrazy a zväzky neopúšťajú vašu sieť; jednoducho využívate rozhranie GitHub na vizualizáciu procesov.

Prečo Docker Compose výrazne uľahčuje život v domácom laboratóriu

Mnoho ľudí strávilo roky spoliehaním sa na Docker Run a Portainer, až kým po incidente alebo migrácii neboli nútení prehodnotiť svoj prístup. Keď stratíte hostiteľa alebo musíte presunúť služby na iný počítač, spoliehanie sa výlučne na izolované príkazy alebo konfigurácie v rámci Portaineru je pasca.

Veľký rozdiel pri prechode na Compose spočíva v tom, že celá definícia služby sa zmení na text : zväzky, porty, siete, štítky, premenné… Všetko v súbore YAML, ktorý môžete kopírovať, zdieľať, upravovať verzie a znova používať.

Úprava služby už nie je o „ručnom prebudovaní kontajnera“; teraz ide o úpravu riadku v súbore, uloženie a spustenie príkazu `docker compose up -d` . Nemusíte si pamätať pôvodný príkaz ani preklikávať viacero obrazoviek Portaineru.

Okrem toho, ak pracujete s viacerými servermi (mini PC, NAS, stolové počítače), je mimoriadne pohodlné mať možnosť skopírovať ten istý súbor Compose na iný počítač, upraviť štyri cesty a spustiť ten istý zásobník na inom hardvéri . V skutočnosti mnohí ľudia uznávajú, že po strachu zo straty údajov alebo chaotických migrácií im Compose v neskorších udalostiach ušetril veľa času.

Ako bonus navyše sa vytváranie nových služieb zo starých stáva triviálnym: napríklad klonovanie konfigurácie Plexu na nastavenie Jellyfinu opätovným použitím rovnakých mediálnych ciest a transkódovacích zariadení trvá len niekoľko minút, ak to urobíte kopírovaním blokov YAML.

Optimalizácia: kontext zostavenia, viacstupňové zostavenia a zdroje

Hoci mnohé kontajnery Homelab pochádzajú z verejných obrazov, v niektorých prípadoch si ich budete musieť skompilovať sami. V týchto prípadoch je dôležité spravovať kontext zostavenia : nenahrávajte celý repozitár bez filtrov, ale obmedzte sa na priečinok projektu (pomocou silnej direktívy `.dockerignore`), aby ste zabezpečili rýchle a ľahké zostavenia.

Ďalšou veľmi užitočnou technikou je použitie viacstupňových zostavení vo vašich Dockerfiles: v prvej fáze nainštalujete závislosti a skompilujete ich a v druhej fáze skopírujete iba potrebné artefakty do malého základného obrazu. Výsledkom sú oveľa menšie a bezpečnejšie finálne obrazy , pretože neprenášajú nepotrebné reťazce nástrojov ani knižnice.

Na strane Compose máte možnosť definovať limity CPU a RAM (najmä v prostrediach Swarm alebo keď Docker rešpektuje tieto parametre), aby ste zabránili aplikáciám náročným na zdroje v ich nadmernom využívaní. V Homelabs to pomáha zabrániť tomu, aby nesprávne nakonfigurovaná služba ochromila zvyšok systému.

Nezabudnite na pravidlá reštartu (restart: always, unless-stopped, on-failure): pomocou nich zabezpečíte, aby sa kritické služby (reverzná proxy, VPN, kľúčové databázy) automaticky reštartovali po reštarte alebo jednorazovom zlyhaní.

Nakoniec je vhodné naplánovať pravidelné úlohy čistenia pomocou príkazov ako docker image prune, docker container prune a docker volume prune, aby sa odstránili zvyšky starých zostavení, zastavené kontajnery alebo osirelé zväzky a tým sa obnovil priestor na disku.

Zdravotnícke služby, logovanie a monitorovanie

Aby ste predišli tomu, že sa váš domáci lab stane čiernou skrinkou, je dôležité pracovať na troch kľúčových aspektoch: kontroly stavu, kontrolované protokolovanie a monitorovanie . Docker Compose vám umožňuje deklarovať kontroly stavu pre každú službu (pomocou príkazov ako `curl -f http://localhost` alebo špecifických skriptov), ​​ktoré určujú, či je kontajner v poriadku.

Vďaka tomu môžete zabezpečiť, aby prevádzku prijímali iba „zdravé“ kontajnery (napríklad cez Traefik) a aby sa v prípade, že prestanú reagovať, reštartovali podľa nakonfigurovanej politiky. To výrazne zvyšuje odolnosť s minimálnym úsilím.

Pokiaľ ide o protokoly, úprava ovládača JSON-file s limitmi maximálnej veľkosti a maximálneho počtu súborov zabraňuje zaplneniu disku gigabajtmi zabudnutých protokolov. Webové nástroje ako Dozzle vám pomôžu prehliadať protokoly všetkých kontajnerov z prehliadača, čo je veľmi pohodlné na ladenie špecifických služieb.

Pre metriky a nepretržité monitorovanie je klasickou kombináciou cAdvisor + Prometheus + Grafana . cAdvisor zobrazuje štatistiky využitia CPU, pamäte, disku a siete pre každý kontajner; Prometheus ich pravidelne zhromažďuje a Grafana ich zobrazuje v atraktívnych dashboardoch s upozorneniami v prípade akýchkoľvek nárastov.

Dobre nastavené domáce laboratórium zvyčajne zahŕňa Uptime Kuma na kontroly dostupnosti (HTTP, ICMP, TCP atď.) a automatizovaný zálohovací systém, ako je Duplicati, na kopírovanie dôležitých údajov na iné disky alebo do cloudu. Takto viete, čo sa deje, a ak sa niečo pokazí, nestratíte to dôležité.

Zabezpečenie a vzdialený prístup k domácemu laboratóriu

Napriek tomu, že nastavenie si môžete urobiť sami, zabezpečenie nie je voliteľné. Mnoho ľudí sa rozhodne nevystavovať svoj NAS alebo jeho služby vonkajšiemu svetu priamo , čím obmedzujú vzdialený prístup cez VPN (WireGuard je veľmi obľúbená možnosť vďaka svojmu výkonu a jednoduchosti).

V tomto modeli router funguje ako brána: k VPN serveru sa otvorí iba náhodný port a po pripojení všetky požiadavky na interné služby prechádzajú šifrovaným tunelom . Ani Traefik, ani aplikácie nie sú vystavené internetu bez tohto predchádzajúceho filtrovania.

Tí, ktorí si radšej nespravujú vlastnú VPN, sa niekedy obracajú na Cloudflare Tunnel alebo Tailscale, aby získali prístup k svojmu domácemu laboratóriu bez otvárania portov. Sú to pohodlné alternatívy, ak je však vašou najvyššou prioritou súkromie, budete musieť zvážiť, aké metadáta môžu tieto tretie strany zhromažďovať.

Ďalším dobrým postupom je šifrovanie servera a NAS diskov , pravidelná aplikácia záplat a obmedzenie automatických aktualizácií (mnohí sa vyhýbajú Watchtower v prospech kontrolovaných manuálnych aktualizácií). Je lepšie byť trochu pozadu, ale s kontrolou, ako rozbiť polovicu Homelabu kvôli aktualizácii, ktorú ste neskontrolovali.

Ako vidíte, nemusíte dosiahnuť „podnikovú“ úroveň, ale je vhodné zaviesť minimálnu úroveň bezpečnosti a disciplíny , aby vaše domáce laboratórium nebolo sitom alebo neustálym zdrojom strachu.

V konečnom dôsledku je vytvorenie seriózneho domáceho laboratória s Docker Compose kombináciou organizácie, zdravého rozumu a ochoty experimentovať: ak zoskupíte služby, dobre definujete siete, zdokumentujete ich v Gite a trochu automatizujete, získate prostredie, ktoré môžete začať jedným príkazom, jednoducho migrovať na iný počítač a postupne ho rozširovať bez toho, aby sa z neho stala nekontrolovateľná džungľa.