„Docker Composite“ namų laboratorijoje: struktūra, profiliai ir geriausia praktika

Informatec Digital » Ištekliai » „Docker Composite“ namų laboratorijoje: struktūra, profiliai ir geriausia praktika

Šiuolaikinės namų laboratorijos kūrimas iš gabenimo konteinerių tapo mėgstamu daugelio technologijų specialistų hobiu. „Docker Compose“ beveik visada yra šios sąrankos pagrindasApibrėžkite savo paslaugas YAML, versuokite jas naudodami „Git“ ir galėsite paleisti visą aplinką viena komanda.

Dabar, kai pradedate augti, vyksta įvairūs dalykai: nuo dviejų ar trijų vazonų pereinate prie Dešimtys paslaugų, vidinių tinklų, atvirkštinių tarpinių serverių, duomenų bazių ir CI vykdytojųTada ir iškyla svarbiausias klausimas: vienas milžiniškas „Docker Compose“ failas ar daug mažų failų? Kaip sutvarkyti profilius, tinklus, atsargines kopijas, saugumą ir, svarbiausia, palengvinti migraciją?

Realūs „Docker Compose“ diegimo namų laboratorijoje metodai

Praktiškai žmonės, kurie jau kurį laiką naudojasi „Homelabs“, paprastai veikia pagal tris „Compose“ organizacinius modelius, kurių kiekvienas turi savų privalumų ir trūkumų. Pasirinkus tinkamą metodą, sutaupoma daug skausmo auginant ar perkeliant mašinas..

Vienoje pusėje yra tas, kuris pradėjo nuo „Docker Run“ pradėjo laisvai, tada perėjo prie „Portainer“ ir galiausiai peršoko prie „Docker Compose“.Tai tipiška: „Portainer“ siūlo puikų matomumą, patogią vartotojo sąsają, šablonus ir pan., tačiau galiausiai sudėtingų parametrų redagavimas ar konfigūracijų perkėlimas tampa vargu, jei failuose nieko nėra.

Priešingoje kraštutinumoje yra tie, kurie viską sujungė į vieną „mega“ „docker-compose.yml“ failą galintis paleisti absoliučiai visas namų laboratorijos paslaugas: atvirkštinį tarpinį serverį, mediją, komunalines paslaugas, stebėjimą, LLM, duomenų bazes… Visa tai viename steke.

Tuo tarpu daugelis vartotojų renkasi mišrų metodą: keli maži „docker-compose.yml“ failai, sugrupuoti pagal kontekstą (pavyzdžiui, žiniasklaida, infrastruktūra, produktyvumas, stebėjimas), visi toje pačioje saugykloje ir paprastai dalijasi globaliais aplinkos kintamaisiais.

Gana elegantiškas sprendimas sujungia abu pasaulius: šakninio doko komponavimo programa, kurioje yra ir kitų failų (kiekvienas programų arba paslaugų poaplankyje). Tokiu būdu galite matyti visą namų laboratorijos vaizdą, tačiau be tūkstančio eilučių YAML failo, kurio neįmanoma perskaityti.

Profiliai, grupavimas pagal funkciją ir didelės namų laboratorijos

Kai jūsų namų laboratorija pradeda artėti prie 30, 40 arba 50 paslaugų (įskaitant atsarginių kopijų kūrimo paslaugas, tokias kaip duomenų bazės, talpyklos ar indeksavimo priemonės), gyvybiškai svarbu įvesti tvarką. Būtent čia ir grupavimas pagal funkciją kaip ir naudojimas „Docker Composite“ profiliai.

Labai dažnas modelis yra sugrupuoti viską į vieną „Compose“ „projektą“, bet logiškai suskirstyti pagal profilius. Pavyzdžiui:

• Šerdies profilis„homelab“ branduolys, kuriame „Traefik“ veikia kaip atvirkštinis tarpinis serveris ir tapatybės teikėjas (pvz., „OAuth“ arba „Authentik“), skirtas visų to paties domeno programų autentifikavimui naudojant HTTPS.
• Žiniasklaidos profilisTokios paslaugos kaip „Plex“, „Sonarr“, „Radarr“, „Ombi“, „SABnzbd“ arba „qBittorrent“, atsakingos už multimedijos turinio kuravimą, atsisiuntimą ir teikimą.
• Komunalinių paslaugų profilisTokios priemonės kaip „Portainer“, „Watchtower“ (jei naudojama), „Diun“, „dockcheck“ ar panašios, skirtos konteineriams ir atnaujinimams valdyti bei stebėti.
• Infrastruktūros / stebėsenos profilis„Traefik“, „cAdvisor“, „Prometheus“, „Grafana“, „Uptime Kuma“, „Dozzle“ ir viskas, kas susiję su stebėjimu ir registravimu.
• Eksperimentiniai profiliai arba LLM: specialūs LLM arba įdomių programėlių rinkiniai („ChatGPT Next Web local“, „LibreOffice Online“ ir kt.), kurie paprastai yra išjungti pagal numatytuosius nustatymus.

Profilių grožis yra tas, kad Galite paleisti tik dalį infrastruktūros Priklausomai nuo jūsų poreikių. Pavyzdžiui, mažai energijos naudojančiame mini kompiuteryje galite paleisti tik „core + infrastructure“ profilį, o dideliame serveryje su daugiau diskų ir GPU – tik medijos profilį.

Gerai suprojektuotose saugyklose paprastai yra docker-compose.yml „master“, kuris įtraukia įtraukimus į atskirus failus aplanke „apps“ / arba „services“ /Be to, beveik visos paslaugos konfigūruojamos naudojant vieną failą. .env global ir kelios paslaptys secrets/ kataloge, o tai labai supaprastina pradinį nustatymą.

Laikantis šio modelio, namų laboratorijos valdymas iš esmės sumažinamas iki Redaguokite .env failą ir slaptus raktus, įjunkite arba išjunkite profilius ir nuspręskite, kurias paslaugas paleisti kiekviename pagrindiniame kompiuteryje.Idealus variantas, jei ketinate diegti tas pačias programas keliuose kompiuteriuose.

Vienas milžiniškas „Docker“ komponavimo failas, palyginti su keliais mažais failais

Tai amžina diskusija: Vienas „docker-compose.yml“ failas, kuriame yra viskas, ar keli failai kiekvienai paslaugai / stekui? Tikrasis atsakymas paprastai yra „tai priklauso nuo to, kam norite teikti pirmenybę: perkėlimo paprastumui ar aiškumui kiekvienoje paslaugoje“.

Kas gina, vienas pagrindinis failas Paprastai jis pabrėžia keletą privalumų:

• Migruoti prieglobos serverius yra labai paprastaKlonuojate saugyklą, nukopijuojate .env failą ir slaptus raktus, prijungiate tomus ir vykdote komandą `docker compose up -d`. Nereikia ieškoti katalogų po katalogo.
• Infrastruktūra kaip tiesos kodasvisa namų laboratorijos topologija (paslaugos, tinklai, tomai, priklausomybės) yra vienoje vietoje.
• Centralizuoti atnaujinimai: pakeičiate vaizdo versiją, perkrovimo politiką arba tam tikrą žurnalavimą ir tiksliai žinote, kur liesti.

Tačiau jis taip pat turi aiškių trūkumų: didelį YAML failą sunkiau prižiūrėti, Sujungimo konfliktų padaugėjimas Kai reikia derinti konkrečią problemą, tenka susidurti su šimtų eilučių monstru. Neretai tenka šiek tiek apgailestauti, kai viskas tampa per daug sudėtinga.

Kitas požiūris yra turėti vienas „docker-compose.yml“ kiekvienai programai arba loginiam stekui, tokioje struktūroje kaip:

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

Šiuo atveju kiekvienas konteineris vadinamas kažkuo panašiu į bookstack-app-1 o traefik-atvirkštinis-proxy-1tai padeda greitai rasti problemas: jei „bookstack-app-1“ konteineris sugenda, tiksliai žinote, kuriame aplanke ieškoti.

Vizualiai jis daug švaresnis ir Tai leidžia valdyti kiekvieną paslaugą atskirai. (paleisti, sustabdyti arba atnaujinti nepaveikiant kitų). Be to, yra tokių programų kaip „Dozzle“, kurios pasinaudoja atskirų stekų pranašumu, kad geriau tvarkytų žurnalus.

Kompromisas yra tas Jei viską per daug atskirsite, bendrų paslaugų (pvz., „Traefik“ ar bendrų tinklų) koordinavimas pareikalaus šiek tiek daugiau dėmesio.: reikia deklaruoti išorinius tinklus, naudoti konkrečias „Traefik“ žymas ir atsiminti kitų „Docker-Compose“ sukurtų tinklų nomenklatūrą.

Geriausia .env, perrašymų ir versijų valdymo praktika

Vienas iš labiausiai neįvertintų triukų yra centralizuoti konfigūraciją .env failuoseUžuot užtvindę „docker-compose.yml“ aplinkos kintamaisiais, apibrėžiate kažką panašaus į tai:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

Ir tada YAML jie nurodomi kaip ${DB_USERNAME} o ${DB_PASSWORD}Tai leidžia rašyti tekstą lengvai įskaityti iš pirmo žvilgsnio, bendrinti kintamuosius keliose paslaugose Ir svarbiausia, saugokite slaptažodžius atskirame faile (kurį galite neįtraukti į „Git“).

Tai labai naudinga įvairiose aplinkose (gamybai, testavimui, kūrimui). pasinaudokite „docker-compose.override.yml“ privalumaisIdėja yra turėti bazinį „docker-compose.yml“ failą ir, keičiant nustatymus, perrašyti tik tai, kas pasikeičia: prievadus, kelius, derinimo žymas...

Pavyzdžiui, kūrimo metu galite įkelti perrašymą, kur Atidarote kitą prievadą, aktyvuojate DEBUG ir prijungiate vietinį šaltinio kodą.Jūs neliečiate pagrindinio YAML, bet pritaikote steko aplinką, kurioje jį paleidžiate.

Akivaizdu Versijų kūrimas naudojant „Git“ yra būtinas, jei norite, kad jūsų namų laboratorija būtų bent kiek rimta.Paprastai turite kažką panašaus:

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

Tada inicijuojate saugyklą, įvykdote infrastruktūros pakeitimus ir, jei kas nors sugenda, Galite grįžti prie ankstesnės „Compose“ versijos per kelias sekundes.Šiek tiek ambicingoms namų laboratorijoms tai ne tik išeitis, bet ir vienintelis būdas išvengti išprotėjimo.

Tinklai, „Traefik“ ir saugių paslaugų poveikis

Tas pats derinys pasitaiko beveik visose vidutinio pažangumo namų laboratorijose: „Traefik“ kaip atvirkštinis tarpinis serveris ir centralizuotas tapatybės teikėjas („Auth“ arba „Authentik“)Tai leidžia jums rodyti daug programų subdomenuose naudojant HTTPS ir SSO.

Klasikinis modelis yra, pavyzdžiui, sukurti specialų „Docker“ tinklą. atvirkštinis_proxy arba panašiai, kur „Traefik“ ir visos išoriškai teikiamos žiniatinklio paslaugos yra sujungtos. Likę konteineriai (duomenų bazės, talpyklos ir kt.) lieka izoliuotuose vidiniuose tinkluose.

Jei naudojate „Traefik“ ir atskiriate savo paslaugas į skirtingus „Docker-Compose“ elementus, jums reikia apibrėžti bendrą išorinį tinkląKažkas panašaus:

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

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

Čia „traefik_default“ tinklą sukuria „Traefik“ paketas, o kitos paslaugos prie jo pridedamos per išorinį tinklą, vadinamą „traefik-net“. Žymės nurodo „Traefik“... kuris tinklas turėtų būti naudojamas srautui nukreipti.

Kai viename steke yra vidinės paslaugos (pavyzdžiui, žiniatinklio konteineris ir jo duomenų bazė), galite Prijunkite juos prie bendro numatytojo tinklo ir suteikite žiniatinklio konteineriui prieigą tik prie „Traefik“ tinklo.Duomenų bazėje bus žyma „traefik.enable=false“, todėl „Traefik“ ją ignoruos.

Šio tipo sąranka suteikia du pagrindinius privalumus: izoliacija tarp paslaugų ir kontroliuojamo poveikioIš išorės pasiekiami tampa tik tie konteineriai, kuriuos pažymite „Traefik“ etiketėmis ir kurie yra tarpinio serverio tinkle.

Duomenų patikimumas, apimtys ir disko struktūra

Namų laboratorija be nuolatinių duomenų nėra labai naudinga: duomenų bazės, konfigūracijos, medija, dokumentai... viskas turi atlaikyti „Docker“ komponavimo pabaigą. Apimtys ir įrišimo dydžiai yra jūsų gyvybės draudimas.

Daugelis žmonių savo saugyklas tvarko naudodami tokią struktūrą:

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

Idėja yra ta Atsisiuntimo programos („qBittorrent“, „SABnzbd“ ir kt.) mato tik atsisiuntimų aplankąTokie valdytojai kaip „Radarr“ / „Sonarr“ turi prieigą prie atsisiuntimų ir medijos (norėdami perkelti / kurti kietąsias nuorodas), o serveriai, tokie kaip „Plex“ ar „Jellyfin“, mato tik medijos aplanką.

Tokiu būdu pritaikysite principą minimali privilegijaKiekvienas konteineris pasiekia tik tai, ko jam iš tikrųjų reikia. Šis aiškus atskyrimas taip pat padeda sprendžiant, kuriuos tomus ar kelius kurti atsargines kopijas debesyje ar išoriniuose diskuose.

Katalogas „srv“ paprastai naudojamas programų konfigūracijoms saugoti (pvz., „/srv/jellyfin/config“, „/srv/traefik“, „/srv/paperless“ ir kt.). Paprastai jis yra iš dalies versuojamas (šablonai, „Caddyfile“ ir kt.), praleidžiant viską, kas svarbu ar reikalauja daug išteklių.

Kai kuriais atvejais įdomu naudoti kietosios nuorodos Atsisiuntimo grandinėje: tokios paslaugos kaip „Radarr“ ar „Sonarr“ gali susieti atsisiųstus failus, kad būtų išlaikytas siuntimas nedubliuojant vietos diske. Būtent tuo paremtas tokių gidų kaip „TRaSHGuides“ siūlomas katalogų dizainas.

Diegimų automatizavimas naudojant „GitHub Actions“ ir vietinius vykdytojus

Jei norite pakelti reikalus į kitą lygį, galite žengti dar vieną žingsnį ir Automatizuokite namų laboratorijos atnaujinimus naudodami CI/CDKeletas naudotojų pakeitė „Jenkins“ ir panašius įrankius darbo eiga, naudodami „GitHub Actions“ ir savarankiškai talpinamą vykdiklį savo namų laboratorijoje.

Mechanizmas paprastas: kiekvieną kartą, kai pereinate į pagrindinę savo „Homelab“ saugyklos šaką, Paleidžiamas „GitHub Actions“ darbo eiga, kuri atlieka testus, linterius ir, jei viskas gerai, įdiegia pakeitimus serveryje..

Įprasta darbo eiga apima tokius veiksmus kaip:

• „Gitleaks“ tipo slaptas skaitytuvas: jei netyčia į saugyklą įkėlėte slaptažodžius ar prieigos raktus.
• Pūkuotumas YAML arba infrastruktūros kodo, kad būtų išlaikytas skaitomas ir nuoseklus formatas.
• Atnaujinant saugyklą pačioje namų laboratorijoje: git pull tiksliniame serveryje.
• Kontroliuojamas konteinerių atkūrimas: sustabdykite senus, paleiskite naujus ir patikrinkite būseną.

Privalumai: papildomas saugumas (kontroliuojate paslapčių nutekėjimą), geresnė kodo kokybė ir kartojamus diegimus vienu paspaudimuKadangi naudojate vietinį bėgiklį, vaizdai ir tomai nepalieka jūsų tinklo; jūs tiesiog naudojate „GitHub“ sąsają, kad vizualizuotumėte vamzdynus.

Kodėl „Docker Compose“ labai palengvina gyvenimą namų laboratorijoje

Daugelis žmonių metų metus pasikliovė Docker Run ir Portainer kol dėl incidento ar migracijos jis bus priverstas iš naujo įvertinti savo požiūrį. Kai prarandate pagrindinį kompiuterį arba turite perkelti paslaugas į kitą kompiuterį, Pasikliauti tik izoliuotomis komandomis ar konfigūracijomis Portainer sistemoje yra spąstai.

Didžiausias skirtumas, kai perjungiate į „Compose“, yra tas, kad Visas paslaugos apibrėžimas tampa tekstu.Tomai, prievadai, tinklai, žymos, kintamieji… Visa tai YAML formate, kurį galite kopijuoti, bendrinti, versuoti ir pakartotinai naudoti.

Paslaugos redagavimas nebėra susijęs su „konteinerio atkūrimu rankiniu būdu“ ir tampa Pakeiskite failo eilutę, išsaugokite ir paleiskite komandą „docker compose up -d“Jums nereikia prisiminti originalios komandos ar spustelėti kelių „Portainer“ ekranų.

Be to, jei dirbate su keliais serveriais (mini kompiuteriais, NAS, staliniais kompiuteriais), labai patogu turėti galimybę Nukopijuokite tą patį kūrimo failą į kitą kompiuterį, pakoreguokite keturis kelius ir paleiskite tą patį steko paketą su skirtinga įranga.Iš tiesų, daugelis žmonių pripažįsta, kad po duomenų praradimo ar chaotiško perkėlimo problemų „Compose“ sutaupė jiems daug laiko vėlesniuose įvykiuose.

Papildomas privalumas yra tai, kad naujų paslaugų kūrimas iš senų tampa trivialus: pavyzdžiui, klonuoti „Plex“ konfigūraciją, kad būtų galima prijungti „Jellyfin“ Pakartotinis tų pačių medijos kelių ir transkodavimo įrenginių naudojimas užtrunka tik kelias minutes, jei tai darote kopijuodami YAML blokus.

Optimizavimas: kūrimo kontekstas, kelių etapų kūrimas ir ištekliai

Nors daugelis „Homelab“ konteinerių yra sukurti iš viešų atvaizdų, kai kuriais atvejais galite susikurti savo atvaizdus. Tokiais atvejais svarbu būti atsargiems. kurti kontekstąNesiųskite visos saugyklos nefiltruotos, o apsiribokite projekto aplanku (su tinkamu .dockerignore failu), kad kompiliavimas būtų greitas ir lengvas.

Dar vienas labai naudingas būdas – pasinaudoti kelių etapų statyba „Dockerfiles“ faile: pirmame etape įdiegiate priklausomybes ir kompiliuojate, o antrame etape į nedidelį bazinį atvaizdą kopijuojate tik būtinus artefaktus. Rezultatas: galutiniai atvaizdai. daug mažesnis ir saugesnisnes jie neperkelia įrankių grandinių ar papildomų bibliotekų.

Sukūrimo pusėje galite apibrėžti CPU ir RAM apribojimai (ypač „Swarm“ aplinkose arba kai „Docker“ atsižvelgia į šiuos parametrus), kad daug išteklių naudojanti programa negalėtų monopolizuoti išteklių. „Homelabs“ aplinkoje tai padeda išvengti, kad netinkamai sukonfigūruota paslauga sutrikdytų likusios sistemos veikimą.

Nepamirškite apie paleisti iš naujo politiką (paleisti iš naujo: visada, nebent sustabdyta, gedimo atveju): naudodami šiuos parametrus užtikrinate, kad svarbiausios paslaugos (atvirkštinis tarpinis serveris, VPN, pagrindinės duomenų bazės) būtų automatiškai paleistos iš naujo po perkrovimo arba vienkartinio gedimo.

Galiausiai, gera idėja suplanuoti reguliarias valymo užduotis naudojant tokias komandas kaip „Docker“ atvaizdas „prune“, „Docker“ konteineris „prune“ ir „Docker“ tūris „prune“ pašalinti senų kompiliacijų, sustabdytų konteinerių arba našlaičių tomų likučius ir taip atlaisvinti vietos diske.

Sveikatos priežiūros paslaugos, registravimas ir stebėsena

Kad jūsų namų laboratorija netaptų juodąja dėže, svarbu dirbti ties trimis pagrindiniais aspektais: sveikatos patikrinimai, kontroliuojamas registravimas ir stebėjimas„Docker Compose“ leidžia deklaruoti kiekvienos paslaugos sveikatos patikrinimus (naudojant tokias komandas kaip curl -f http://localhost arba konkrečius scenarijus), kurie nustato, ar konteineris laikomas sveiku.

Su tuo galite tai padaryti taip, kad Tik „sveiki“ konteineriai gauna srautą (pavyzdžiui, per „Traefik“) ir kad, jei jie nustoja reaguoti, jie paleidžiami iš naujo pagal sukonfigūruotą politiką. Tai žymiai padidina atsparumą minimaliomis pastangomis.

Kalbant apie žurnalus, pakoreguokite tvarkyklės JSON failą su apribojimais maksimalus dydis ir maksimalus failo dydis Tai apsaugo jūsų diską nuo gigabaitų pamirštų žurnalų. Žiniatinklio įrankiai, tokie kaip „Dozzle“, padeda naršyti visų konteinerių žurnalus naršyklėje, o tai labai patogu derinant konkrečias paslaugas.

Kalbant apie metriką ir nuolatinį stebėjimą, klasikinis derinys yra cAdvisor + Prometėjas + Grafana„cAdvisor“ pateikia procesoriaus, atminties, disko ir tinklo naudojimo statistiką kiekvienam konteineriui; „Prometheus“ ją periodiškai renka, o „Grafana“ rodo patraukliose ataskaitų suvestinėse su įspėjimais, jei kas nors padidėja.

Gerai įrengta namų laboratorija paprastai taip pat apima „Kuma“ veikimo laikas prieinamumo patikrinimams (HTTP, ICMP, TCP…) ir automatinę atsarginių kopijų kūrimo sistemą, pvz., „Duplicati“, skirtą svarbiems duomenims kopijuoti į kitus diskus arba debesį. Tokiu būdu žinosite, kas vyksta, ir, jei kas nors nutiks, neprarasite to, kas svarbu.

Saugumas ir nuotolinė prieiga prie namų laboratorijos

Kad ir kokia savadarbė būtų įranga, saugumas nėra būtinas dalykas. Daugelis žmonių renkasi ją. Neleiskite savo NAS ar jo paslaugų tiesiogiai patekti į išorinį pasaulį.nuotolinės prieigos per VPN ribojimas („WireGuard“ yra labai populiarus pasirinkimas dėl savo našumo ir paprastumo).

Šiame modelyje maršrutizatorius veikia kaip šliuzas: VPN serveriui atidaromas tik atsitiktinis prievadas, o prisijungus, Visos užklausos vidinėms paslaugoms praeina per užšifruotą tunelį.Nei „Traefik“, nei programėlės nėra veikiamos interneto be šio išankstinio filtro.

Tie, kurie nenori tvarkyti savo VPN, kartais griebiasi „Cloudflare“ tunelis arba uodegos skalė norint pasiekti namų laboratoriją neatidarant prievadų. Tai patogios alternatyvos, tačiau jei jūsų absoliutus prioritetas yra privatumas, turėsite apsvarstyti, kokius metaduomenis šios trečiosios šalys gali rinkti.

Kita gera praktika yra Užšifruokite serverį ir NAS diskusReguliariai diegkite pataisymus ir apribokite automatinius atnaujinimus (daugelis vengia „Watchtower“ ir pirmenybę teikia kontroliuojamiems rankiniams atnaujinimams). Geriau šiek tiek atsilikti, bet su kontrole, nei sugadinti pusę „Homelab“ dėl nepatikrinto atnaujinimo.

Kaip matote, jums nereikia pasiekti „įmonės“ lygio, bet Taip, patartina nustatyti minimalius saugos ir drausmės standartus. kad jūsų namų laboratorija netaptų sietu ar nuolatiniu gąsdinimų šaltiniu.

Galiausiai, rimtos namų laboratorijos sukūrimas naudojant „Docker Compose“ yra organizuotumo, sveiko proto ir noro eksperimentuoti derinys: jei sugrupuosite paslaugas, gerai apibrėšite tinklus, dokumentuosite „Git“ ir šiek tiek automatizuosite, gausite aplinką, kurią galėsite pradėti nuo vienos komandos, lengvai perkelti į kitą kompiuterį ir po truputį plėsti, netapdami nekontroliuojama džiunglėmis.