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, izmantojot kuģniecības konteinerus, ir kļuvusi par iecienītu hobiju daudziem tehnoloģiju cilvēkiem. Docker Compose gandrīz vienmēr ir šīs iestatīšanas centrāDefinējiet savus pakalpojumus YAML valodā, versijas veidojiet, izmantojot Git, un jūs varat palaist visu savu vidi ar vienu komandu.

Tagad, kad sākat augt, lietas notiek: jums vairs nav divu vai trīs konteineru, bet gan Desmitiem pakalpojumu, iekšējo tīklu, reverso starpniekservera, datubāzu un CI skrējējuTieši tad rodas lielais jautājums: viens milzīgs Docker Compose fails 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 darbojas trīs Compose organizācijas modeļu ietvaros, katram no kuriem ir savas priekšrocības un trūkumi. Pareizās pieejas izvēle ietaupa daudz sāpju, audzējot vai migrējot iekārtas..

Vienā pusē ir tas, kurš sāka ar Docker Run sāka brīvi, tad pārgāja uz Portainer un visbeidzot pārgāja uz Docker Compose.Tas ir tipiski: 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 nav nekā.

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

Starp tiem daudzi lietotāji izvēlas jauktu pieeju: 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 (katra lietotņu vai pakalpojumu apakšmapē). Tādā veidā jūs saglabājat globālu skatījumu uz mājas laboratoriju, taču 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 pakalpojumi (tostarp dublēšanas pakalpojumiem, piemēram, datubāzēm, kešatmiņām vai indeksētājiem), ir svarīgi ieviest kārtību. Šeit ir gan grupēšana pēc funkcijas tāpat kā lietošana Docker Composite profili.

Ļ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 skaistums slēpjas tajā, ka Jūs varat palaist tikai daļu no infrastruktūras Atkarībā no jūsu vajadzībām. Piemēram, mazjaudas mini datorā varētu palaist tikai pamata un infrastruktūras profilu, bet lielajā serverī ar vairāk diskiem un grafiskajiem procesoriem — tikai multivides profilu.

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

Sekojot šim modelim, mājas laboratorijas pārvaldība būtībā tiek reducēta līdz Rediģējiet .env failu un slepenos kodus, iespējojiet vai atspējojiet profilus un izlemiet, kurus pakalpojumus startēt katrā resursdatorā.Ideāli piemērots, ja plānojat izvietot vienu un to pašu lietojumprogrammu komplektu vairākos datoros.

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

Šī ir mūžīgā diskusija: Viens docker-compose.yml fails, kurā ir viss, vai vairāki faili katram pakalpojumam/stekam? Patiesā 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".

Kas aizstāv, viena galvenā datne Parasti tas 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, Apvienošanās konfliktu pieaugums Runājot par konkrētas problēmas atkļūdošanu, jūs nonākat situācijā, kad jums ir jāorientējas simtiem rindu milzīgā. Nav nekas neparasts justies nedaudz nožēlotam, kad viss kļūst pārāk liels.

Otra pieeja ir tāda, ka viens docker-compose.yml katrai lietotnei vai loģiskajai stekam, tādā struktūrā kā:

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

Ar šo katru konteineru sauc par kaut ko līdzīgu bookstack-app-1 o traefik-reverse-proxy-1kas 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 Tas ļauj jums pārvaldīt katru pakalpojumu atsevišķi. (startēšana, apturēšana vai atjaunināšana, neietekmējot pārējo). Turklāt ir tādas lietojumprogrammas kā Dozzle, kas izmanto atsevišķu steku priekšrocības, lai labāk organizētu žurnālus.

Kompromiss ir tāds 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.: ir jādeklarē ārējie tīkli, jāizmanto ī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 centralizēt konfigurāciju .env failosTā 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_LIETOTĀJVĀRDS} o ${DB_PASSWORD}Tas padara sarakstīto tekstu viegli lasāmu, ļaujot jums koplietot mainīgos vairākos pakalpojumos Un pats galvenais, glabājiet paroles atsevišķā failā (kuru varat izslēgt no Git).

Tas ir ļoti noderīgi dažādās vidēs (ražošanā, testēšanā, izstrādē). izmantojiet docker-compose.override.yml priekšrocībasIdeja ir izveidot pamata failu docker-compose.yml un, ignorējot, pārrakstīt tikai to, kas mainās: porti, ceļi, atkļūdošanas karodziņi…

Piemēram, izstrādes procesā var ielādēt ignorēšanu, kur Jūs atverat citu portu, aktivizējat DEBUG un pievienojat lokālo pirmkodu.Jūs nepieskaraties galvenajam YAML, bet pielāgojat steku videi, kurā to palaižat.

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

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, Jūs varat atgriezties pie iepriekšējās rakstīšanas versijas dažu sekunžu laikā.Nedaudz ambiciozām mājas laboratorijām šī nav tikai iespēja, bet gan vienīgais veids, kā izvairīties no sajukšanas prātā.

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

Tā pati kombinācija parādās gandrīz visās vidēji progresīvajās mājas laboratorijās: Traefik kā apgrieztais starpniekserveris un centralizēts identitātes nodrošinātājs (Auth vai Authentik)Tas ļauj jums pakļaut daudzas lietotnes apakšdomēnos, izmantojot HTTPS un SSO.

Klasisks modelis ir, piemēram, izveidot īpašu Docker tīklu. reversais_proxy vai līdzīgi, kur ir savienoti Traefik un visi tīmekļa pakalpojumi, kurus plānojat apkalpot ārēji. Pārējie konteineri (datubāzes, kešatmiņas utt.) paliek izolētos iekšējos tīklos.

Ja izmantojat Traefik un sadalāt savus pakalpojumus dažādās docker-composing sistēmās, jums ir nepieciešams definēt koplietotu ārējo tīkluKaut kas tamlīdzīgs:

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, ko sauc par traefik-net. Tagi norāda Traefik... Kuru tīklu vajadzētu 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 Pievienojiet tos koplietojamam noklusējuma tīklam un piešķiriet 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 sniedz divas galvenās priekšrocības: izolācija starp pakalpojumiem un kontrolēta iedarbībaNo ārpuses kļūst pieejami tikai tie konteineri, kurus atzīmē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ījumu stiprinājumi ir jūsu dzīvības apdrošināšana.

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 Lejupielādētāji (qBittorrent, SABnzbd u. c.) redz tikai lejupielāžu mapi.Pārvaldniekiem, piemēram, Radarr/Sonarr, ir piekļuve 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ā jūs pielietojat principu, minimālā privilēģijaKatrs konteiners piekļūst tikai tam, kas tam faktiski nepieciešams. Šī skaidrā 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 ir interesanti to izmantot cietās saites Lejupielādes ķēdē: tādi pakalpojumi kā Radarr vai Sonarr var sasaistīt lejupielādētos failus, lai saglabātu sēšanu, nedublējot diska vietu. Tieši uz to balstās direktoriju dizains, ko piedāvā tādas rokasgrāmatas kā TRaSHGuides.

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

Ja vēlaties pacelt lietas nākamajā līmenī, varat spert soli tālāk un Automatizējiet mājas laboratorijas atjauninājumus, izmantojot CI/CDVairāki lietotāji ir aizstājuši Jenkins un līdzīgus rīkus ar darbplūsmu, kas izmanto GitHub Actions un pašizvietotu palaistu programmu savā mājas laboratorijā.

Mehānisms ir vienkāršs: katru reizi, kad jūs dodaties uz sava Homelab repozitorija galveno filiāli, 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 spiedienuUn, tā kā jūs izmantojat lokālu skrējēju, attēli un apjomi 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 ir paļāvušies uz Docker Run un Portainer līdz brīdim, kad incidenta vai migrācijas rezultātā tas ir spiests pārskatīt savu pieeju. Kad zaudējat resursdatoru vai pakalpojumi ir jāpārvieto uz citu datoru, Paļaušanās tikai uz atsevišķām komandām vai konfigurācijām Portainer vidē ir slazds..

Lielākā atšķirība, pārslēdzoties uz Compose, ir tā, ka Visa pakalpojuma definīcija kļūst par tekstu.Apjomi, porti, tīkli, etiķetes, mainīgie… Tas viss ir YAML formātā, ko var kopēt, kopīgot, versijas veidot un atkārtoti izmantot.

Pakalpojuma rediģēšana vairs nav saistīta ar "konteinera manuālu pārbūvi", bet gan ar modificējiet rindu failā, saglabājiet un palaidiet docker compose up -dJums nav jāatceras sākotnējā komanda vai jānoklikšķina uz vairākiem Portainer ekrāniem.

Turklāt, ja strādājat ar vairākiem serveriem (mini datoriem, NAS, galddatoriem), ir ārkārtīgi ērti, ja varat Kopējiet to pašu rakstīšanas failu uz citu ierīci, pielāgojiet četrus ceļus un palaidiet to pašu steku ar citu aparatūru.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 izveide no veciem kļūst triviāla: piemēram, klonēt Plex konfigurāciju, lai uzstādītu Jellyfin To pašu multivides ceļu un transkodēšanas ierīču atkārtota izmantošana 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 mājas laboratorijas konteineri ir veidoti no publiski pieejamiem attēliem, dažos gadījumos jūs kompilēsiet savus attēlus. Šādos gadījumos ir svarīgi būt uzmanīgiem. veidot kontekstuNesūtiet visu repozitoriju nefiltrētu, bet gan ierobežojiet sevi ar projekta mapi (ar labu .dockerignore failu), lai būvēšana būtu ātra un viegla.

Vēl viena ļoti noderīga metode ir izmantot daudzpakāpju konstrukcijas Jūsu Dockerfiles failā: pirmajā fāzē jūs instalējat atkarības un kompilējat, bet otrajā fāzē jūs kopējat tikai nepieciešamos artefaktus uz nelielu bāzes attēlu. Rezultāts: galīgie attēli. daudz mazāks un drošāksjo tie nepārnes rīku ķēdes vai papildu bibliotēkas.

Rakstīšanas pusē jums ir iespēja definēt CPU un RAM ierobežojumi (īpaši Swarm vidēs vai tad, ja Docker ievēro šos parametrus), lai novērstu resursu ietilpīgas lietotnes resursu monopolizāciju. 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 politikas (restartēt: vienmēr, ja vien nav apturēts, kļūmes gadījumā): ar šiem parametriem jūs nodrošināt, ka kritiski svarīgi pakalpojumi (reversais starpniekserveris, VPN, galveno datubāzu dati) tiek automātiski restartēti pēc atkārtotas palaišanas vai vienreizējas kļūmes.

Visbeidzot, ieteicams ieplānot regulārus tīrīšanas uzdevumus, izmantojot tādas komandas kā docker attēls plūme, docker konteiners plūme un docker sējums plūme lai likvidētu veco būvējumu, 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 nodrošinātu, ka jūsu mājas laboratorija nav melnā kaste, ir svarīgi strādāt pie trim galvenajiem aspektiem: veselības pārbaudes, kontrolēta reģistrēšana un uzraudzībaDocker 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 tiek uzskatīts par veselīgu.

Ar šo jūs varat panākt, lai Tikai "veselīgi" konteineri saņem datplūsmu (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āgojiet draivera JSON failu ar ierobežojumiem maksimālais izmērs un maksimālais faila lielums Tas novērš diska piepildīšanos ar gigabaitiem aizmirstu žurnālu. 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.

Attiecībā uz rādītājiem un nepārtrauktu uzraudzību, klasiskā kombinācija ir cAdvisor + Prometejs + GrafanacAdvisor parāda centrālā procesora, atmiņas, diska un tīkla lietojuma statistiku katram konteineram; Prometheus to periodiski apkopo, un Grafana to attēlo pievilcīgos informācijas paneļos ar brīdinājumiem, ja kaut kas palielinās.

Labi iekārtotā mājas laboratorijā parasti ietilpst arī Kuma darbības laiks pieejamības pārbaudēm (HTTP, ICMP, TCP…) 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 paštaisīts būtu iestatījums, drošība nav obligāta prasība, daudzi cilvēki to izvēlas. Nepakļaujiet savu NAS vai tā pakalpojumus tieši ārējai pasaulei.attālās piekļuves ierobežošana, 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ērts tikai nejaušs ports, un pēc savienojuma izveides Visi pieprasījumi iekšējiem pakalpojumiem tiek nosūtīti caur šifrētu tuneli.Ne Traefik, ne lietotnes nav pakļautas internetam bez šī iepriekšējā filtra.

Tie, kas nevēlas pārvaldīt savu VPN, dažreiz izmanto Mākoņu uzliesmojuma tunelis vai astes skala lai piekļūtu mājas laboratorijai, neatverot portus. Šīs ir ērtas alternatīvas, lai gan, ja jūsu absolūtā prioritāte ir privātums, jums būs jāapsver, kādus metadatus šīs trešās puses varētu apkopot.

Vēl viena laba prakse ir Šifrējiet serveri un NAS diskusRegulāri lietojiet ielāpus un ierobežojiet 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 atjauninājuma dēļ, kuru neesat pārbaudījis.

Kā redzat, jums nav jāsasniedz "uzņēmuma" līmenis, bet Jā, ieteicams noteikt minimālos drošības un disciplīnas standartus. lai jūsu mājas laboratorija nekļūtu par sietiņu 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.