Docker Compose v Homelabu: organizace, profily a osvědčené postupy

Informatec Digital » Zdroje » Docker Compose v Homelabu: Organizace, profily a osvědčené postupy

Vytvoření moderního domácího laboratoře s kontejnery se stalo oblíbeným koníčkem mnoha techniků. Docker Compose je téměř vždy jádrem tohoto nastavení : definujte své služby v YAML, verzujte je pomocí Gitu a spusťte celé prostředí jediným příkazem.

Když ale začnete růst, věci se změní: od dvou nebo tří kontejnerů se dostanete k desítkám služeb, interních sítí, reverzních proxy, databází a CI runnerů . Tehdy vyvstává velká otázka: jedna obří instance Docker Compose nebo mnoho malých souborů? Jak uspořádat profily, sítě, zálohy, zabezpečení a navíc usnadnit migraci?

Reálné přístupy k nastavení Docker Compose v domácí laboratoři

V praxi lidé, kteří Homelabs používají již nějakou dobu, obvykle pracují se třemi různými organizačními modely Compose, z nichž každý má své výhody a nevýhody. Volba správného přístupu vám ušetří spoustu problémů při škálování nebo migraci na nový počítač.

Na jedné straně existují ti, kteří začínali se samostatnými příkazy Docker Run, poté přešli na Portainer a nakonec na Docker Compose . Je to typický scénář: Portainer nabízí skvělou přehlednost, uživatelsky přívětivé rozhraní, šablony atd., ale nakonec se úprava složitých parametrů nebo migrace konfigurací stává obtížnou, pokud nemáte nic v souborech.

Na opačném extrému je ten, kdo všechno sloučil do jednoho „mega“ docker-compose.yml, který je schopen spustit absolutně všechny služby homelabu: reverzní proxy, média, utility, monitoring, LLM, databáze... Vše v jednom stacku.

Mezitím se mnoho uživatelů drží smíšeného přístupu: několik malých souborů docker-compose.yml seskupených podle kontextu (např. média, infrastruktura, produktivita, monitorování), všechny ve stejném repozitáři a obvykle sdílející globální proměnné prostředí.

Poměrně elegantní řešení kombinuje oba světy: „kořenový“ docker-compose, který obsahuje další soubory (každý v podsložce aplikací nebo služeb). Tímto způsobem si udržíte globální pohled na domácí lab, ale bez nutnosti trápit se tisíciřádkovým YAML souborem, který je nečitelný.

Profily, seskupování podle funkce a velké domácí laboratoře

Když se vaše domácí laboratoř blíží počtu 30, 40 nebo 50 služeb (včetně zálohovacích služeb, jako jsou databáze, mezipaměti nebo indexery), je nezbytné v nich zavést řád. Zde přichází na řadu jak seskupování podle funkcí , tak používání profilů Docker Compose.

Velmi běžným vzorem je seskupení všeho do jednoho „projektu“ v nástroji Compose, ale logicky rozděleného podle profilů. Například:

• Jádrový profil: jádro homelabu s Traefikem jako reverzní proxy a poskytovatelem identity (např. OAuth nebo Authentik) pro ověření všech aplikací ve stejné doméně pomocí HTTPS.
• Mediální profilSlužby jako Plex, Sonarr, Radarr, Ombi, SABnzbd nebo qBittorrent, které jsou zodpovědné za správu, stahování a poskytování multimediálního obsahu.
• Profil inženýrských sítíNástroje jako Portainer, Watchtower (pokud se používá), Diun, dockcheck nebo podobné pro správu a monitorování kontejnerů a aktualizací.
• Profil infrastruktury/monitorováníTraefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle a vše, co souvisí s monitorováním a logováním.
• Experimentální profily nebo LLMspecifické balíčky pro LLM nebo kuriózní aplikace (ChatGPT Next Web local, LibreOffice Online atd.), které jsou obvykle ve výchozím nastavení zakázány.

Krása profilů spočívá v tom, že můžete podle potřeby nasadit pouze část infrastruktury . Například na mini PC s nízkou spotřebou energie můžete spustit pouze profil jádra + infrastruktury a na velkém serveru s větším počtem disků a grafických karet nasadit pouze profil médií.

V dobře navržených repozitářích se obvykle v kořenovém adresáři nachází „hlavní“ soubor docker-compose.yml, který pomocí metody include vkládá jednotlivé soubory do složky apps/ nebo services/ . Navíc jsou téměř všechny služby konfigurovány pomocí jednoho globálního souboru .env a některé tajné identifikátory jsou uloženy v adresáři secrets/ , což výrazně zjednodušuje počáteční nastavení.

Podle tohoto vzoru se správa domácí laboratoře v podstatě redukuje na úpravu souboru .env a tajných kódů, povolení nebo zakázání profilů a rozhodnutí, které služby se mají spustit na každém hostiteli . To je ideální, pokud chcete nasadit stejnou sadu aplikací na více počítačů.

Jeden obrovský soubor Docker-Compose vs. několik malých souborů

Tohle je věčná debata: jeden soubor docker-compose.yml obsahující všechno, nebo více souborů na službu/stack? Skutečná odpověď obvykle zní: „záleží na tom, co chcete upřednostnit: jednoduchost migrace nebo přehlednost pro každou službu.“

Ti, kteří prosazují jeden hlavní soubor, obvykle zdůrazňují několik výhod:

• Migrace hostitelů je super snadnáNaklonujete repozitář, zkopírujete soubor .env a tajné kódy, připojíte svazky a spustíte příkaz `docker compose up -d`. Není třeba procházet adresář po adresáři.
• Infrastruktura jako kód pravdy: celá topologie domácí laboratoře (služby, sítě, svazky, závislosti) je na jednom místě.
• Centralizované aktualizaceZměníte verzi image, zásady restartu nebo nějaké protokolování a přesně víte, kam se máte dotknout.

Má to ale i zjevné nevýhody: obrovský YAML soubor se hůře udržuje, zvyšuje se počet konfliktů při sloučení a při ladění konkrétního problému se ocitnete v situaci, kdy se musíte pohybovat v obrovské většině stovek řádků. Není neobvyklé, že se vám to trochu vymstí, když se všechno příliš zvětší.

Druhým přístupem je mít soubor docker-compose.yml pro každou aplikaci nebo pro každý logický stack , a to v rámci struktury podobné této:

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

Díky tomu je každý kontejner pojmenován něčím jako bookstack-app-1 nebo traefik-reverse-proxy-1 , což vám pomůže rychle najít problémy: pokud kontejner bookstack-app-1 zhroutí, budete přesně vědět, ve které složce hledat.

Vizuálně je to mnohem přehlednější a umožňuje spravovat každou službu nezávisle (spouštět, zastavovat nebo aktualizovat ji bez ovlivnění ostatních). Aplikace jako Dozzle navíc využívají oddělené zásobníky pro lepší organizaci protokolů.

Nevýhodou je, že pokud všechno příliš oddělíte, koordinace mezi společnými službami (jako je Traefik nebo sdílené sítě) vyžaduje trochu více péče : musíte deklarovat externí sítě, specifické popisky Traefiku a pamatovat si nomenklaturu sítí vytvořených jinými docker-compose.

Nejlepší postupy pro .env, přepsání a správu verzí

Jedním z nejvíce podceňovaných triků je centralizace konfigurace v souborech .env . Místo zahlcení souboru docker-compose.yml proměnnými prostředí definujete něco jako toto:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

A pak se na ně v YAML odkazuje jako na ${DB_USERNAME} nebo ${DB_PASSWORD} . Díky tomu je Compose na první pohled čitelný, umožňuje sdílet proměnné mezi více službami a co je nejdůležitější, ukládá hesla do samostatného souboru (který můžete z Gitu vyloučit).

Pro různá prostředí (produkční, testovací, vývojové) je velmi užitečné využít docker-compose.override.yml . Cílem je mít základní soubor docker-compose.yml a v přepsání přepsat pouze to, co se změní: porty, cesty, ladicí příznaky atd.

Například ve vývoji můžete načíst přepsání, kde zpřístupníte jiný port, povolíte ladění a připojíte lokální zdrojový kód . Nedotýkáte se hlavního YAML, ale přizpůsobujete zásobník prostředí, ve kterém jej spouštíte.

Je zřejmé, že verzování všeho pomocí Gitu je povinné, pokud chcete, aby vaše domácí laboratoř byla alespoň trochu profesionální . Obvykle budete mít něco jako toto:

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

Odtud inicializujete repozitář, provedete commit změn infrastruktury a pokud se něco pokazí, můžete se během několika sekund vrátit k předchozí verzi svého Compose . Pro ambiciózní domácí laboratoře to není jen možnost; je to jediný způsob, jak se vyhnout přetížení.

Sítě, Traefik a bezpečné vystavení službám

V téměř všech středně pokročilých domácích labech se objevuje stejná kombinace: Traefik jako reverzní proxy a centralizovaný poskytovatel identity (Auth nebo Authentik) . To umožňuje zpřístupnit mnoho aplikací v subdoménách s HTTPS a SSO.

Klasickým přístupem je nastavení dedikované sítě Docker, například reverse_proxy nebo podobné, kde je propojen Traefik a všechny webové služby, které budete externě poskytovat. Zbývající kontejnery (databáze, mezipaměti atd.) zůstávají na izolovaných interních sítích.

Pokud používáte Traefik a oddělujete své služby do různých instancí Docker Compose, musíte definovat sdílenou externí síť . Něco jako 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

Zde je síť traefik_default vytvořena zásobníkem Traefik a ostatní služby jsou do ní přidány prostřednictvím externí sítě s názvem traefik-net. Štítky sdělují Traefiku, kterou síť má použít pro směrování provozu.

Pokud jeden zásobník obsahuje backendové služby (například webový kontejner a jeho databázi), můžete je připojit ke sdílené výchozí síti a webovému kontejneru udělit přístup pouze k síti Traefik . Databáze bude mít popisek nastavený na `traefik.enable=false`, takže ji Traefik bude ignorovat.

Tento typ nastavení nabízí dvě klíčové výhody: izolaci mezi službami a kontrolovanou expozici . Zvenčí budou přístupné pouze kontejnery, které označíte štítky Traefik a které se nacházejí v proxy síti.

Perzistence dat, svazky a struktura disků

Domácí laboratoř bez perzistentních dat není moc užitečná: databáze, konfigurace, média, dokumenty… všechno musí přežít Docker Compose Down. Svazky a připojení vazeb jsou vaší záchranou.

Mnoho lidí si organizuje úložný prostor pomocí této struktury:

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

Myšlenka je taková, že stahovací programy (qBittorrent, SABnzbd atd.) vidí pouze složku se staženými soubory , správci jako Radarr/Sonarr mají přístup ke staženým souborům i médiím (pro přesun/vytváření pevných odkazů) a servery jako Plex nebo Jellyfin vidí pouze složku s médii.

Tímto způsobem uplatníte princip nejnižších oprávnění : každý kontejner přistupuje pouze k tomu, co skutečně potřebuje. Jasné oddělení také pomáhá při rozhodování o tom, které svazky nebo cesty zálohovat do cloudu nebo na externí disky.

Adresář srv se obvykle používá k ukládání konfigurací aplikací (například /srv/jellyfin/config, /srv/traefik, /srv/paperless atd.). Obvykle je částečně verzovaný (šablony, Caddyfile atd.), čímž se vynechá cokoli kritického nebo náročného na zdroje.

V některých případech je užitečné použít v řetězci stahování pevné odkazy : služby jako Radarr nebo Sonarr mohou propojovat stažené soubory a zachovat tak „seeding“ bez duplikování místa na disku. Adresářová struktura navržená průvodci jako TRaSHGuides je založena právě na tomto principu.

Automatizace nasazení pomocí akcí GitHubu a lokálních runnerů

Pokud chcete jít ještě o krok dál, můžete automatizovat aktualizace domácího laboratoře pomocí CI/CD . Několik uživatelů nahradilo Jenkins a podobné nástroje pracovním postupem využívajícím akce GitHubu a běžcem hostovaným přímo v domácí laboratoři.

Mechanismus je jednoduchý: pokaždé, když odešlete změnu do hlavní větve vašeho repozitáře homelab, spustí se pracovní postup akcí GitHubu, který spouští testy, lintery a pokud vše půjde dobře, nasadí změny na server.

Typický pracovní postup zahrnuje kroky jako například:

• Tajný skener typu Gitleaks: pro případ, že byste do repozitáře omylem nahráli hesla nebo tokeny.
• Podšívka YAML nebo kódu infrastruktury, aby byl zachován čitelný a konzistentní formát.
• Aktualizace repozitáře v samotném homelabu: git pull na cílovém serveru.
• Řízená rekreace kontejnerůZastavte staré, spusťte nové a zkontrolujte jejich stav.

Výhody: zvýšené zabezpečení (kontrolujete úniky tajných dat), lepší kvalita kódu a opakovatelné nasazení jediným stisknutím tlačítka . A protože používáte lokální běžec, obrazy a svazky neopouštějí vaši síť; jednoduše využijete rozhraní GitHub k vizualizaci procesů.

Proč Docker Compose tolik usnadňuje život v domácí laboratoři

Mnoho lidí strávilo roky spoléháním na Docker Run a Portainer, dokud po incidentu nebo migraci nebyli nuceni svůj přístup přehodnotit. Když ztratíte hostitele nebo musíte přesunout služby na jiný počítač, spoléhání se pouze na izolované příkazy nebo konfigurace v rámci Portaineru je past.

Velký rozdíl při přechodu na Compose spočívá v tom, že celá definice služby se stane textem : svazky, porty, sítě, popisky, proměnné… Vše v souboru YAML, který můžete kopírovat, sdílet, upravovat verze a znovu používat.

Úprava služby už není o „ručním přestavování kontejneru“; nyní jde o úpravu řádku v souboru, uložení a spuštění příkazu `docker compose up -d` . Nemusíte si pamatovat původní příkaz ani proklikávat více obrazovek Portaineru.

Navíc, pokud pracujete s více servery (mini PC, NAS, stolní počítače), je extrémně pohodlné mít možnost zkopírovat stejný soubor Compose na jiný počítač, upravit čtyři cesty a spustit stejný stack na jiném hardwaru . Mnoho lidí dokonce uznává, že po ztrátě dat nebo chaotických migracích jim Compose v následných událostech ušetřil spoustu času.

Jako bonus navíc se vytváření nových služeb ze starých stává triviálním: například klonování konfigurace Plexu pro nastavení Jellyfinu opětovným použitím stejných mediálních cest a překódovacích zařízení trvá jen několik minut, pokud to provedete kopírováním bloků YAML.

Optimalizace: kontext sestavení, vícestupňové sestavení a zdroje

Ačkoli mnoho kontejnerů Homelab pochází z veřejných obrazů, v některých případech si je budete muset zkompilovat sami. V těchto případech je důležité spravovat kontext sestavení : nenahrávejte celý repozitář bez filtrů, ale omezte se na složku projektu (pomocí silné direktivy `.dockerignore`), abyste zajistili rychlé a lehké sestavení.

Další velmi užitečnou technikou je použití vícestupňového sestavení v Dockerfiles: v první fázi instalujete závislosti a kompilujete a ve druhé fázi zkopírujete pouze potřebné artefakty do malého základního obrazu. Výsledkem jsou mnohem menší a bezpečnější finální obrazy , protože nepřenášejí zbytečné sady nástrojů ani knihovny.

Na straně Compose máte možnost definovat limity CPU a RAM (zejména v prostředí Swarm nebo když Docker tyto parametry respektuje), abyste zabránili aplikacím náročným na zdroje v jejich spotřebovávání. V Homelabs to pomáhá zabránit tomu, aby nesprávně nakonfigurovaná služba ochromila zbytek systému.

Nezapomeňte na zásady restartu (restart: always, unless-stopped, on-failure): s nimi zajistíte, že se kritické služby (reverzní proxy, VPN, databáze klíčů) automaticky restartují po restartu nebo jednorázovém selhání.

Nakonec je vhodné naplánovat pravidelné úlohy čištění pomocí příkazů jako docker image prune, docker container prune a docker volume prune, aby se odstranily zbytky starých sestavení, zastavené kontejnery nebo osiřelé svazky a tím se uvolnilo místo na disku.

Zdravotnické služby, protokolování a monitorování

Aby se vaše domácí laboratoř nestala černou skříňkou, je důležité pracovat na třech klíčových aspektech: kontrolách stavu, řízeném protokolování a monitorování . Docker Compose umožňuje deklarovat kontroly stavu pro každou službu (pomocí příkazů jako `curl -f http://localhost` nebo specifických skriptů), které určují, zda je kontejner v pořádku.

Díky tomu zajistíte, že provoz (například přes Traefik) budou přijímat pouze „zdravé“ kontejnery a že pokud přestanou reagovat, budou restartovány podle nakonfigurovaných zásad. To výrazně zvyšuje odolnost s minimálním úsilím.

Pokud jde o protokoly, úprava ovladače JSON-file s limity pro maximální velikost a maximální počet souborů zabraňuje zaplnění disku gigabajty zapomenutých protokolů. Webové nástroje jako Dozzle vám pomohou procházet protokoly všech kontejnerů z prohlížeče, což je velmi výhodné pro ladění specifických služeb.

Pro metriky a průběžné monitorování je klasickou kombinací cAdvisor + Prometheus + Grafana . cAdvisor zpřístupňuje statistiky využití CPU, paměti, disku a sítě pro každý kontejner; Prometheus je pravidelně shromažďuje a Grafana je zobrazuje v atraktivních dashboardech s upozorněními na případné výkyvy.

Dobře nastavená domácí laboratoř obvykle zahrnuje Uptime Kuma pro kontroly dostupnosti (HTTP, ICMP, TCP atd.) a automatizovaný zálohovací systém, jako je Duplicati, pro kopírování důležitých dat na jiné disky nebo do cloudu. Tímto způsobem víte, co se děje, a pokud se něco pokazí, nepřijdete o to důležité.

Zabezpečení a vzdálený přístup k domácí laboratoři

I když si nastavení můžete provést sami, zabezpečení není volitelné. Mnoho lidí se rozhodne svůj NAS nebo jeho služby přímo nevystavovat vnějšímu světu , což omezuje vzdálený přístup přes VPN (WireGuard je velmi oblíbenou možností díky svému výkonu a jednoduchosti).

V tomto modelu router funguje jako brána: k VPN serveru se otevírá pouze náhodný port a po připojení procházejí všechny požadavky na interní služby šifrovaným tunelem . Ani Traefik, ani aplikace nejsou vystaveny internetu bez tohoto předchozího filtrování.

Ti, kteří nechtějí spravovat svou vlastní VPN, se někdy obracejí na Cloudflare Tunnel nebo Tailscale, aby získali přístup ke své domácí laboratoři bez otevírání portů. Jedná se o pohodlné alternativy, ale pokud je pro vás soukromí nejvyšší prioritou, budete muset zvážit, jaká metadata by tyto třetí strany mohly shromažďovat.

Dalším dobrým postupem je šifrování serveru a NAS disků , pravidelná instalace záplat a omezení automatických aktualizací (mnozí se vyhýbají Watchtower a dávají přednost kontrolovaným manuálním aktualizacím). Je lepší být trochu pozadu, ale s kontrolou, než rozbít polovinu Homelabu kvůli aktualizaci, kterou jste nezkontrolovali.

Jak vidíte, nemusíte dosáhnout „podnikové“ úrovně, ale je vhodné zavést minimální úroveň zabezpečení a disciplíny , aby vaše domácí laboratoř nebyla sítem nebo neustálým zdrojem strachu.

V konečném důsledku je vytvoření seriózního domácího laboratoře s Docker Compose kombinací organizace, selského rozumu a ochoty experimentovat: pokud seskupíte služby, dobře definujete sítě, zdokumentujete je v Gitu a trochu automatizujete, skončíte s prostředím, které můžete začít jediným příkazem, snadno migrovat na jiný počítač a krůček po krůčku rozšiřovat, aniž by se z něj stala nekontrolovatelná džungle.