Docker Compose mājas laboratorijā: organizācija, profili un labākā prakse

Informatec Digital » Resursi » Docker Compose mājas laboratorijā: organizācija, profili un labākā prakse

Mūsdienīgas mājas laboratorijas izveide ar konteineriem ir kļuvusi par iecienītu hobiju daudziem tehnoloģiju speciālistiem. Docker Compose gandrīz vienmēr ir šīs iestatīšanas pamatā : definējiet savus pakalpojumus YAML valodā, versijas veidojiet, izmantojot Git, un startējiet visu savu vidi ar vienu komandu.

Tomēr, kad sākat augt, lietas mainās: divu vai trīs konteineru vietā rodas desmitiem pakalpojumu, iekšējo tīklu, reverso starpniekservera, datubāzu un CI runneru . Tieši tad rodas lielais jautājums: viena milzīga Docker Compose instance vai daudzi mazi faili? Kā es varu organizēt profilus, tīklus, dublējumus, drošību un turklāt atvieglot migrāciju?

Reālās pasaules pieejas Docker Compose iestatīšanai mājas laboratorijā

Praksē cilvēki, kas kādu laiku izmanto mājas laboratorijas, parasti strādā ar trim dažādiem Compose organizācijas modeļiem, katram no tiem ir savas priekšrocības un trūkumi. Pareizās pieejas izvēle ietaupīs daudz nepatikšanas, palielinot apjomu vai migrējot uz jaunu datoru.

No vienas puses, ir tādi, kas sāka ar atsevišķām Docker Run komandām, pēc tam pārgāja uz Portainer un visbeidzot pārgāja uz Docker Compose . Tas ir tipisks scenārijs: Portainer piedāvā lielisku pārskatāmību, lietotājam draudzīgu saskarni, veidnes utt., taču galu galā sarežģītu parametru rediģēšana vai konfigurāciju migrēšana kļūst par apgrūtinājumu, ja failos nekā nav.

Pretējā galējībā ir tas, kurš visu ir apvienojis vienā "mega" docker-compose.yml failā, kas spēj darbināt absolūti visus mājas laboratorijas pakalpojumus: reverso starpniekserveri, multividi, utilītas, uzraudzību, LLM, datubāzes... Visu vienā kaudzē.

Pa vidu daudzi lietotāji pieturas pie jauktas pieejas: vairāki mazi docker-compose.yml faili, kas sagrupēti pēc konteksta (piemēram, multivide, infrastruktūra, produktivitāte, uzraudzība), visi vienā repozitorijā un parasti koplieto globālos vides mainīgos.

Diezgan elegants risinājums apvieno abas pasaules: "root" docker-compose, kas ietver citus failus (katrs lietotņu vai pakalpojumu apakšmapē). Tādā veidā jūs saglabājat globālu mājas laboratorijas skatu, bet neciešot no tūkstoš rindu gara YAML faila, kuru nav iespējams nolasīt.

Profili, grupēšana pēc funkcijas un lielas mājas laboratorijas

Kad jūsu mājas laboratorija sāk tuvoties 30, 40 vai 50 pakalpojumiem (tostarp dublēšanas pakalpojumiem, piemēram, datubāzēm, kešatmiņām vai indeksētājiem), ir svarīgi tos sakārtot. Šeit noder gan grupēšana pēc funkcijas , gan Docker Compose profilu izmantošana.

Ļoti izplatīta metode ir visu grupēt vienā Compose “projektā”, bet loģiski sadalīt pa profiliem. Piemēram:

• Kodola profilsmājas laboratorijas kodols ar Traefik kā apgriezto starpniekserveri un identitātes nodrošinātāju (piemēram, OAuth vai Authentik), lai autentificētu visas lietotnes vienā domēnā, izmantojot HTTPS.
• Mediju profilsPakalpojumi, piemēram, Plex, Sonarr, Radarr, Ombi, SABnzbd vai qBittorrent, kas ir atbildīgi par multivides satura veidošanu, lejupielādi un apkalpošanu.
• Komunālo pakalpojumu profilsRīki, piemēram, Portainer, Watchtower (ja tiek izmantots), Diun, dockcheck vai līdzīgi, lai pārvaldītu un uzraudzītu konteinerus un atjauninājumus.
• Infrastruktūras/monitoringa profilsTraefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle un viss, kas saistīts ar uzraudzību un reģistrēšanu.
• Eksperimentālie profili vai LLM: īpašas LLM vai interesantu lietotņu pakotnes (ChatGPT Next Web local, LibreOffice Online utt.), kas parasti pēc noklusējuma ir atspējotas.

Profilu priekšrocība ir tā, ka pēc nepieciešamības var izvietot tikai daļu infrastruktūras . Piemēram, mazjaudas mini datorā var palaist tikai pamata un infrastruktūras profilu, bet lielajā serverī ar vairāk diskiem un grafiskajiem procesoriem izvietot tikai multivides profilu.

Labi izstrādātās krātuvēs saknes direktorijā parasti ir "master" fails docker-compose.yml, kas izmanto "include", lai ievietotu atsevišķus failus mapē apps/ vai services/ . Turklāt gandrīz visi pakalpojumi tiek konfigurēti, izmantojot vienu globālu .env failu, un daži noslēpumi tiek glabāti direktorijā secrets/ , kas ievērojami vienkāršo sākotnējo iestatīšanu.

Ievērojot šo modeli, mājas laboratorijas pārvaldība būtībā nozīmē .env faila un noslēpumu rediģēšanu, profilu iespējošanu vai atspējošanu un lēmumu pieņemšanu par to, kurus pakalpojumus palaist katrā resursdatorā . Tas ir ideāli, ja plānojat izvietot vienu un to pašu lietojumprogrammu komplektu vairākās ierīcēs.

Viens milzīgs Docker-Compose fails salīdzinājumā ar vairākiem maziem failiem

Šī ir mūžīgā diskusija: viens docker-compose.yml fails, kas satur visu, vai vairāki faili katram pakalpojumam/stekam? Īstā atbilde parasti ir: "tas atkarīgs no tā, kam vēlaties piešķirt prioritāti: migrācijas vienkāršībai vai skaidrībai katram pakalpojumam."

Tie, kas atbalsta vienotu galveno failu, parasti izceļ vairākas priekšrocības:

• Migrēt mitinātājus ir ļoti vienkāršiJūs klonējat repozitoriju, kopējat .env failu un noslēpumus, pievienojat sējumus un palaižat `docker compose up -d`. Nav nepieciešams iet pa direktorijiem.
• Infrastruktūra kā patiesības kods: visa mājas laboratorijas topoloģija (pakalpojumi, tīkli, sējumi, atkarības) atrodas vienuviet.
• Centralizēti atjauninājumiJūs maināt attēla versiju, pārstartēšanas politiku vai kādu reģistrēšanas procesu un precīzi zināt, kur pieskarties.

Taču tam ir arī skaidri trūkumi: milzīgu YAML failu ir grūtāk uzturēt, palielinās apvienošanas konfliktu skaits, un, atkļūdojot konkrētu problēmu, nākas orientēties simtiem rindu milzīgā. Nav nekas neparasts justies nedaudz nožēlotam, kad viss kļūst pārāk liels.

Otra pieeja ir izveidot failu docker-compose.yml katrai lietotnei vai loģiskajai stekam , šādā struktūrā:

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

Tādējādi katram konteineram tiek piešķirts kaut kas līdzīgs bookstack-app-1 vai traefik-reverse-proxy-1 , kas palīdz ātri atrast problēmas: ja bookstack-app-1 konteiners avarē, jūs precīzi zināt, kurā mapē meklēt.

Vizuāli tas ir daudz tīrāks un ļauj pārvaldīt katru pakalpojumu atsevišķi (startēt, apturēt vai atjaunināt to, neietekmējot citus). Turklāt tādas lietojumprogrammas kā Dozzle izmanto atsevišķu steku priekšrocības, lai labāk organizētu žurnālus.

Negatīvā puse ir tāda, ka , ja visu pārāk atdala, koordinācija starp kopīgiem pakalpojumiem (piemēram, Traefik vai koplietotiem tīkliem) prasa nedaudz lielāku rūpību : jums ir jādeklarē ārējie tīkli, īpašas Traefik etiķetes un jāatceras citu Docker-Compose izveidoto tīklu nomenklatūra.

Labākā prakse ar .env, ignorēšanu un versiju kontroli

Viens no visvairāk nenovērtētajiem trikiem ir konfigurācijas centralizēšana .env failos . Tā vietā, lai pārpludinātu savu docker-compose.yml ar vides mainīgajiem, jūs definējat kaut ko līdzīgu šim:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

Un tad YAML uz tiem atsaucas kā ${DB_USERNAME} vai ${DB_PASSWORD} . Tas padara Compose ātri lasāmu, ļauj koplietot mainīgos starp vairākiem pakalpojumiem un, pats galvenais, saglabā paroles atsevišķā failā (kuru var izslēgt no Git).

Dažādās vidēs (ražošanas, testēšanas, izstrādes) ir ļoti noderīgi izmantot docker-compose.override.yml . Ideja ir izveidot pamata failu docker-compose.yml un ignorēt tikai to, kas mainās: porti, ceļi, atkļūdošanas karodziņi utt.

Piemēram, izstrādes procesā var ielādēt ignorēšanu, kurā tiek atvērts cits ports, iespējota atkļūdošana un pievienots lokālais pirmkods . Galvenajam YAML netiek pieskarts, bet tiek pielāgots steks videi, kurā tas tiek darbināts.

Acīmredzot, visu versiju veidošana ar Git ir obligāta, ja vēlaties, lai jūsu mājas laboratorija būtu kaut attāli profesionāla . Parasti jums būs kaut kas līdzīgs šim:

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

Pēc tam jūs inicializējat repozitoriju, veicat infrastruktūras izmaiņas un, ja kaut kas neizdodas, dažu sekunžu laikā varat atgriezties pie iepriekšējās Compose versijas . Ambiciozām mājas laboratorijām šī nav tikai iespēja; tas ir vienīgais veids, kā izvairīties no pārspīlējuma.

Tīkli, Traefik un drošu pakalpojumu iedarbība

Gandrīz visās vidēji attīstītajās mājas laboratorijās parādās viena un tā pati kombinācija: Traefik kā apgrieztais starpniekserveris un centralizēts identitātes nodrošinātājs (Auth vai Authentik) . Tas ļauj piekļūt daudzām lietotnēm apakšdomēnos, izmantojot HTTPS un SSO.

Klasiska pieeja ir izveidot īpašu Docker tīklu, piemēram, reverse_proxy vai līdzīgu, kur ir savienots Traefik un visi tīmekļa pakalpojumi, kurus apkalposiet ārēji. Pārējie konteineri (datubāzes, kešatmiņas utt.) paliek izolētos iekšējos tīklos.

Ja izmantojat Traefik un atdalat savus pakalpojumus dažādās Docker Compose instancēs, jums jādefinē koplietots ārējais tīkls . Kaut kas līdzīgs šim:

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

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

Šeit tīklu traefik_default izveido Traefik steks, un pārējie pakalpojumi tam tiek pievienoti, izmantojot ārēju tīklu ar nosaukumu traefik-net. Etiķetes norāda Traefik, kuru tīklu izmantot datplūsmas maršrutēšanai.

Ja vienā kaudzē ir iekļauti aizmugursistēmas pakalpojumi (piemēram, tīmekļa konteiners un tā datubāze), varat tos savienot ar koplietojamu noklusējuma tīklu un piešķirt tīmekļa konteineram piekļuvi tikai Traefik tīklam . Datubāzei būs etiķete `traefik.enable=false`, lai Traefik to ignorētu.

Šāda veida iestatīšana piedāvā divas galvenās priekšrocības: pakalpojumu izolāciju un kontrolētu iedarbību . No ārpuses kļūst pieejami tikai tie konteineri, kurus marķējat ar Traefik etiķetēm un kas atrodas starpniekservera tīklā.

Datu noturība, apjomi un diska struktūra

Mājas laboratorija bez pastāvīgiem datiem nav īpaši noderīga: datubāzēm, konfigurācijām, multivides failiem, dokumentiem… visam ir jāiztur Docker Compose Down. Apjomi un saistīšanas pieslēgumi ir jūsu glābšanas riņķis.

Daudzi cilvēki organizē savu krātuvi, izmantojot šādu struktūru:

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

Ideja ir tāda, ka lejupielādētāji (qBittorrent, SABnzbd utt.) redz tikai lejupielāžu mapi , pārvaldnieki, piemēram, Radarr/Sonarr, var piekļūt gan lejupielādēm, gan multividei (lai pārvietotu/izveidotu cietās saites), un serveri, piemēram, Plex vai Jellyfin, redz tikai multivides mapi.

Tādā veidā tiek piemērots mazāko privilēģiju princips : katrs konteiners piekļūst tikai tam, kas tam faktiski nepieciešams. Skaidra atdalīšana arī palīdz, lemjot, kurus sējumus vai ceļus dublēt mākonī vai ārējos diskos.

Srv direktorijs parasti tiek izmantots lietotņu konfigurāciju glabāšanai (piemēram, /srv/jellyfin/config, /srv/traefik, /srv/paperless utt.). Tas parasti ir daļēji versiju veidots (veidnes, Caddyfile utt.), izlaižot visu kritisko vai resursu ietilpīgo.

Dažos gadījumos lejupielādes ķēdē ir lietderīgi izmantot cietās saites : tādi pakalpojumi kā Radarr vai Sonarr var sasaistīt lejupielādētos failus, lai saglabātu sēšanu, nedublējot diska vietu. Tādu ceļvežu kā TRaSHGuides piedāvātā direktoriju struktūra ir balstīta tieši uz šo principu.

Izvietošanas automatizācija, izmantojot GitHub darbības un lokālos izpildītājus

Ja vēlaties spert soli tālāk, varat automatizēt mājas laboratorijas atjauninājumus, izmantojot CI/CD . Vairāki lietotāji ir aizstājuši Jenkins un līdzīgus rīkus ar darbplūsmu, izmantojot GitHub Actions un mājas laboratorijā pašhostētu palaistni.

Mehānisms ir vienkāršs: katru reizi, kad veicat nosūtīšanu uz savas mājas laboratorijas repozitorija galveno atzaru, tiek palaista GitHub Actions darbplūsma, kas veic testus, linterus un, ja viss norit labi, izvieto izmaiņas serverī.

Tipiska darbplūsma ietver šādas darbības:

• Gitleaks tipa slepenais skeneris: gadījumā, ja nejauši esat augšupielādējis paroles vai žetonus repozitorijā.
• Griešana YAML vai infrastruktūras koda, lai saglabātu lasāmu un konsekventu formātu.
• Repozitorija atjaunināšana pašā mājas laboratorijā: git pull mērķa serverī.
• Kontrolēta konteineru atjaunošana: apturēt vecos, palaist jaunos un pārbaudīt statusu.

Priekšrocības: papildu drošība (jūs kontrolējat noslēpumu noplūdes), labāka koda kvalitāte un atkārtojamas izvietošanas ar vienu klikšķi . Un, tā kā jūs izmantojat lokālu izpildītāju, attēli un sējumi nepamet jūsu tīklu; jūs vienkārši izmantojat GitHub saskarni, lai vizualizētu cauruļvadus.

Kāpēc Docker Compose padara dzīvi mājas laboratorijā tik daudz vienkāršāku

Daudzi cilvēki gadiem ilgi paļaujas uz Docker Run un Portainer, līdz pēc incidenta vai migrācijas viņi ir spiesti pārskatīt savu pieeju. Zaudējot resursdatoru vai pārvietojot pakalpojumus uz citu datoru, paļaušanās uz atsevišķām komandām vai konfigurācijām tikai Portainer ietvaros ir slazds.

Lielākā atšķirība, pārslēdzoties uz Compose, ir tā, ka visa pakalpojuma definīcija kļūst par tekstu : sējumi, porti, tīkli, etiķetes, mainīgie… Viss vienā YAML failā, ko var kopēt, koplietot, versijas veidot un atkārtoti izmantot.

Pakalpojuma rediģēšana vairs nav par "konteinera manuālu pārbūvi"; tagad tā ir par rindas modificēšanu failā, saglabāšanu un `docker compose up -d` palaišanu . Jums nav jāatceras sākotnējā komanda vai jāpārskata vairāki Portainer ekrāni.

Turklāt, ja strādājat ar vairākiem serveriem (mini datoriem, NAS, galddatoriem), ir ārkārtīgi ērti, ja varat kopēt vienu un to pašu Compose failu uz citu datoru, pielāgot četrus ceļus un palaist to pašu steku uz dažādām aparatūrām . Patiesībā daudzi cilvēki atzīst, ka pēc bailēm, kas saistītas ar datu zudumu vai haotisku migrāciju, Compose viņiem ir ietaupījis daudz laika turpmākajos gadījumos.

Kā papildu bonuss jaunu pakalpojumu veidošana no veciem kļūst vienkārša: piemēram, Plex konfigurācijas klonēšana, lai iestatītu Jellyfin, atkārtoti izmantojot tos pašus multivides ceļus un transkodēšanas ierīces, aizņem tikai dažas minūtes, ja to darāt, kopējot YAML blokus.

Optimizācija: būvēšanas konteksts, daudzpakāpju būvēšana un resursi

Lai gan daudzi Homelab konteineri ir veidoti no publiski pieejamiem attēliem, dažos gadījumos jūs kompilēsiet paši. Šādos gadījumos ir svarīgi pārvaldīt būvēšanas kontekstu : neaugšupielādējiet visu repozitoriju nefiltrētu, bet gan ierobežojiet sevi ar projekta mapi (izmantojot spēcīgu `.dockerignore` direktīvu), lai nodrošinātu ātru un vieglu būvēšanu.

Vēl viena ļoti noderīga metode ir izmantot vairākpakāpju būvējumus Dockerfiles failos: pirmajā posmā jūs instalējat atkarības un kompilējat, bet otrajā posmā jūs kopējat tikai nepieciešamos artefaktus uz nelielu bāzes attēlu. Rezultāts: daudz mazāki un drošāki gala attēli , jo tie nepārnes nevajadzīgas rīku ķēdes vai bibliotēkas.

Rakstīšanas pusē ir iespēja definēt centrālā procesora un operatīvās atmiņas ierobežojumus (īpaši Swarm vidēs vai tad, ja Docker ievēro šos parametrus), lai novērstu resursu ietilpīgu lietotņu resursu pārslodzi. Homelabs vidē tas palīdz novērst nepareizi konfigurēta pakalpojuma radītu pārējās sistēmas darbības traucējumus.

Neaizmirstiet par restartēšanas politikām (restartēšana: vienmēr, ja vien nav apturēta, kļūmes gadījumā): ar tām jūs nodrošināt, ka kritiski svarīgi pakalpojumi (reversais starpniekserveris, VPN, galveno datubāzu datubāzes) tiek automātiski restartēti pēc restartēšanas vai vienreizējas kļūmes.

Visbeidzot, ieteicams periodiski ieplānot tīrīšanas uzdevumus ar tādām komandām kā docker image prune, docker container prune un docker volume prune, lai noņemtu veco versiju, apturētu konteineru vai bāreņu sējumu paliekas un tādējādi atgūtu vietu diskā.

Veselības aprūpes pakalpojumi, reģistrēšana un uzraudzība

Lai jūsu mājas laboratorija nekļūtu par melno kasti, ir svarīgi strādāt pie trim galvenajiem aspektiem: veselības pārbaudēm, kontrolētas reģistrēšanas un uzraudzības . Docker Compose ļauj deklarēt veselības pārbaudes katram pakalpojumam (izmantojot tādas komandas kā `curl -f http://localhost` vai īpašus skriptus), kas nosaka, vai konteiners ir veselīgs.

Tas ļauj nodrošināt, ka datplūsmu saņem tikai "veselīgi" konteineri (piemēram, izmantojot Traefik) un ka, ja tie pārstāj reaģēt, tie tiek restartēti saskaņā ar konfigurēto politiku. Tas ievērojami palielina noturību ar minimālu piepūli.

Attiecībā uz žurnāliem, pielāgojot JSON faila draiveri ar maksimālā izmēra un maksimālā failu skaita ierobežojumiem , disks netiek piepildīts ar aizmirstu žurnālu gigabaitiem. Tīmekļa rīki, piemēram, Dozzle, palīdz pārlūkprogrammā pārlūkot visu konteineru žurnālus, kas ir ļoti ērti konkrētu pakalpojumu atkļūdošanai.

Metriku un nepārtrauktas uzraudzības nodrošināšanai klasiskā kombinācija ir cAdvisor + Prometheus + Grafana . cAdvisor parāda centrālā procesora, atmiņas, diska un tīkla izmantošanas statistiku katram konteineram; Prometheus to periodiski apkopo, un Grafana to attēlo pievilcīgos informācijas paneļos ar brīdinājumiem, ja rodas palielinājumi.

Labi iekārtota mājas laboratorija parasti ietver Uptime Kuma pieejamības pārbaudēm (HTTP, ICMP, TCP utt.) un automatizētu dublēšanas sistēmu, piemēram, Duplicati, lai kopētu kritiskos datus uz citiem diskiem vai mākoni. Tādā veidā jūs zināt, kas notiek, un, ja kaut kas noiet greizi, jūs nezaudējat svarīgo.

Drošība un attālināta piekļuve mājas laboratorijai

Lai arī cik daudz drošības iestatījumu veiktu pats, drošība nav izvēles iespēja. Daudzi cilvēki izvēlas tieši nepakļaut savu NAS vai tā pakalpojumus ārējai pasaulei , ierobežojot attālo piekļuvi, izmantojot VPN (WireGuard ir ļoti populāra opcija, pateicoties tās veiktspējai un vienkāršībai).

Šajā modelī maršrutētājs darbojas kā vārteja: VPN serverim tiek atvērta tikai nejauša pieslēgvieta, un pēc savienojuma izveides visi pieprasījumi iekšējiem pakalpojumiem iet caur šifrētu tuneli . Ne Traefik, ne lietotnes netiek pakļautas internetam bez šīs iepriekšējas filtrēšanas.

Tie, kas nevēlas pārvaldīt savu VPN, dažreiz izmanto Cloudflare Tunnel vai Tailscale , lai piekļūtu savai mājas laboratorijai, neatverot portus. Tās ir ērtas alternatīvas, lai gan, ja privātums ir jūsu galvenā prioritāte, jums jāapsver, kādus metadatus šīs trešās puses varētu apkopot.

Vēl viena laba prakse ir šifrēt serveri un NAS diskus , regulāri lietot ielāpus un ierobežot automātiskos atjauninājumus (daudzi izvairās no Watchtower, dodot priekšroku kontrolētiem manuāliem atjauninājumiem). Labāk ir nedaudz atpalikt, bet kontrolēti, nekā sabojāt pusi Homelab nepārbaudīta atjauninājuma dēļ.

Kā redzat, jums nav jāsasniedz "uzņēmuma" līmenis, taču ieteicams noteikt minimālu drošības un disciplīnas līmeni , lai jūsu mājas laboratorija nekļūtu par sietu vai pastāvīgu biedēšanas avotu.

Galu galā nopietnas mājas laboratorijas izveide, izmantojot Docker Compose, ir organizētības, veselā saprāta un vēlmes eksperimentēt apvienojums: ja grupējat pakalpojumus, labi definējat tīklus, dokumentējat Git un nedaudz automatizējat, jūs iegūstat vidi, kuru varat sākt ar vienu komandu, viegli migrēt uz citu datoru un pakāpeniski paplašināt, nekļūstot par nekontrolējamiem džungļiem.