Docker Compose në Homelab: organizimi, profilet dhe praktikat më të mira

Informatec Digital » Burime » Docker Compose në Homelab: organizimi, profilet dhe praktikat më të mira

Ngritja e një laboratori modern shtëpiak me kontejnerë është bërë një hobi i preferuar për shumë teknikë. Docker Compose është pothuajse gjithmonë në zemër të këtij konfigurimi : përcaktoni shërbimet tuaja në YAML, versiononi ato me Git dhe nisni të gjithë mjedisin tuaj me një komandë të vetme.

Megjithatë, kur fillon të rritesh, gjërat ndryshojnë: kalon nga dy ose tre kontejnerë në dhjetëra shërbime, rrjete të brendshme, proksi të kundërt, baza të dhënash dhe ekzekutues CI . Atëherë lind pyetja e madhe: një instancë e vetme gjigante Docker Compose apo shumë skedarë të vegjël? Si t'i organizoj profilet, rrjetet, kopjet rezervë, sigurinë dhe, për më tepër, ta bëj të lehtë migrimin?

Qasje të botës reale për konfigurimin e Docker Compose në një laborator shtëpiak

Në praktikë, njerëzit që kanë përdorur Homelabs për njëfarë kohe zakonisht punojnë me tre modele të ndryshme organizative të Compose, secili me avantazhet dhe disavantazhet e veta. Zgjedhja e qasjes së duhur ju kursen shumë telashe kur zgjeroheni ose migroni në një makinë të re.

Nga njëra anë, ka nga ata që filluan me komanda të pavarura Docker Run, pastaj kaluan te Portainer dhe më në fund kaluan te Docker Compose . Është një skenar tipik: Portainer ofron dukshmëri të shkëlqyer, një ndërfaqe miqësore për përdoruesit, shabllone etj., por në fund të fundit, redaktimi i parametrave kompleksë ose migrimi i konfigurimeve bëhet një bezdi nëse nuk keni asgjë në skedarë.

Në ekstremin e kundërt është ai që ka konsoliduar gjithçka në një "mega" docker-compose.yml të vetëm , të aftë të ekzekutojë absolutisht të gjitha shërbimet e homelab: reverse proxy, media, shërbime, monitorim, LLM, baza të dhënash... Të gjitha në një pirg të vetëm.

Ndërkohë, shumë përdorues ndjekin një qasje të përzier: disa skedarë të vegjël docker-compose.yml të grupuar sipas kontekstit (p.sh., media, infrastruktura, produktiviteti, monitorimi), të gjithë nën të njëjtën depo dhe zakonisht ndajnë variabla globale të mjedisit.

Një zgjidhje mjaft elegante përzien të dyja botët: një docker-compose "root" që përfshin skedarë të tjerë (secili në një nën-dosje të aplikacioneve ose shërbimeve). Në këtë mënyrë ju ruani një pamje globale të homelab, por pa vuajtur nga një skedar YAML me një mijë rreshta që është i pamundur të lexohet.

Profilet, grupimi sipas funksionit dhe laboratorët e mëdhenj në shtëpi

Kur homelab-i juaj fillon t'i afrohet 30, 40 ose 50 shërbimeve (duke përfshirë shërbimet e rezervimit si bazat e të dhënave, memorjet e përkohshme ose indeksuesit), është thelbësore t'u vendosni rregull atyre. Këtu hyjnë në lojë si grupimi sipas funksionit ashtu edhe përdorimi i profileve Docker Compose.

Një model shumë i zakonshëm është grupimi i gjithçkaje në një “projekt” të vetëm të Compose, por të ndarë logjikisht sipas profileve. Për shembull:

• Profili kryesor: core homelab, me Traefik si një proxy të kundërt dhe një ofrues identiteti (p.sh., OAuth ose Authentik) për të autentifikuar të gjitha aplikacionet nën të njëjtin domen me HTTPS.
• Profili i mediasShërbime si Plex, Sonarr, Radarr, Ombi, SABnzbd ose qBittorrent, përgjegjëse për kurimin, shkarkimin dhe shërbimin e përmbajtjes multimediale.
• Profili i ShërbimeveMjete të tilla si Portainer, Watchtower (nëse përdoren), Diun, dockcheck ose të ngjashme për të menaxhuar dhe monitoruar kontejnerët dhe përditësimet.
• Profili i infrastrukturës/monitorimitTraefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle dhe gjithçka që lidhet me monitorimin dhe regjistrimin.
• Profile eksperimentale ose LLM: grumbuj specifikë për LLM ose aplikacione kurioze (ChatGPT Next Web local, LibreOffice Online, etj.) që zakonisht janë të çaktivizuara si parazgjedhje.

Bukuria e profileve qëndron në faktin se mund të vendosni vetëm një pjesë të infrastrukturës sipas nevojës. Për shembull, mund të ekzekutoni vetëm profilin bërthamë + infrastrukturë në një mini PC me fuqi të ulët dhe të vendosni profilin media vetëm në serverin e madh me më shumë disqe dhe GPU.

Në depot e dizajnuara mirë, zakonisht ekziston një skedar "master" docker-compose.yml në rrënjë që përdor include për të shtyrë skedarë individualë në një dosje apps/ ose services/ . Për më tepër, pothuajse të gjitha shërbimet konfigurohen nëpërmjet një skedari të vetëm global .env, dhe disa sekrete ruhen në një direktori secrets/ , gjë që thjeshton shumë konfigurimin fillestar.

Duke ndjekur këtë model, menaxhimi i homelab në thelb përfshin redaktimin e skedarit .env dhe sekreteve, aktivizimin ose çaktivizimin e profileve dhe vendosjen se cilat shërbime do të fillojnë në secilin host . Kjo është ideale nëse do të vendosni të njëjtin grup aplikacionesh në shumë makina.

Një skedar i vetëm gjigant docker-compose kundrejt disa skedarëve të vegjël

Ky është debati i përjetshëm: një skedar i vetëm docker-compose.yml që përmban gjithçka, apo skedarë të shumtë për shërbim/stack? Përgjigja e vërtetë është zakonisht "varet nga ajo që doni të përparësoni: thjeshtësinë e migrimit apo qartësinë për shërbim".

Ata që mbështesin një skedar të vetëm kryesor zakonisht nxjerrin në pah disa përparësi:

• Migrimi i hosteve është shumë i lehtëJu klononi depon, kopjoni skedarin .env dhe sekretet, montoni vëllimet dhe ekzekutoni `docker compose up -d`. Nuk ka nevojë të shkoni direktori pas direktori.
• Infrastruktura si një kod i së vërtetësE gjithë topologjia e homelab (shërbimet, rrjetet, vëllimet, varësitë) është në një vend.
• Përditësime të centralizuaraJu ndryshoni një version të imazhit, një politikë rinisjeje ose ndonjë regjistrim, dhe e dini saktësisht se ku duhet të prekni.

Por ka edhe disavantazhe të qarta: një skedar i madh YAML është më i vështirë për t'u mirëmbajtur, konfliktet e bashkimit rriten dhe, kur debugoni një problem specifik, e gjeni veten duke lundruar në një përbindësh me qindra rreshta. Nuk është e pazakontë të ndihesh pak keq kur gjithçka bëhet shumë e madhe.

Qasja tjetër është të kesh një skedar docker-compose.yml për çdo aplikacion ose për çdo pirg logjik , brenda një strukture si kjo:

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

Me këtë, çdo kontejner emërtohet diçka si bookstack-app-1 ose traefik-reverse-proxy-1 , gjë që ju ndihmon të gjeni problemet shpejt: nëse kontejneri bookstack-app-1 rrëzohet, ju e dini saktësisht se në cilën dosje duhet të kërkoni.

Vizualisht, është shumë më i pastër dhe ju lejon të menaxhoni çdo shërbim në mënyrë të pavarur (duke e nisur, ndaluar ose përditësuar atë pa ndikuar te të tjerët). Për më tepër, aplikacione si Dozzle përfitojnë nga fakti që kanë grumbuj të veçantë për të organizuar më mirë regjistrat.

Disavantazhi është se nëse i ndani shumë të gjitha, koordinimi midis shërbimeve të përbashkëta (si Traefik ose rrjetet e përbashkëta) kërkon pak më shumë kujdes : duhet të deklaroni rrjete të jashtme, etiketa specifike Traefik dhe të mbani mend nomenklaturën e rrjeteve të krijuara nga docker-compose të tjera.

Praktikat më të mira me .env, mbivendosjet dhe kontrollin e versioneve

Një nga truket më të nënvlerësuara është centralizimi i konfigurimit në skedarët .env . Në vend që ta përmbytni docker-compose.yml tuaj me variabla mjedisi, ju përcaktoni diçka si kjo:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

Dhe pastaj në YAML ato referohen si ${DB_USERNAME} ose ${DB_PASSWORD} . Kjo e bën Compose të lexueshëm me një shikim, ju lejon të ndani variablat midis shërbimeve të shumta dhe, më e rëndësishmja, ruan fjalëkalimet në një skedar të veçantë (të cilin mund ta përjashtoni nga Git).

Për mjedise të ndryshme (prodhim, testim, zhvillim), është shumë e dobishme të shfrytëzohet docker-compose.override.yml . Ideja është që të keni një skedar bazë docker-compose.yml dhe, në mbishkrim, të mbishkruhen vetëm ndryshimet: portet, shtigjet, flamujt e debugimit, etj.

Për shembull, gjatë zhvillimit mund të ngarkoni një mbishkrim ku ekspozoni një port të ndryshëm, aktivizoni debugging dhe montoni kodin burimor lokal . Ju nuk e prekni YAML-in kryesor, por e përshtatni pirgun me mjedisin ku po e ekzekutoni.

Natyrisht, versionimi i gjithçkaje me Git është i detyrueshëm nëse doni që laboratori juaj i shtëpisë të jetë sadopak profesional . Zakonisht do të keni diçka të tillë:

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

Nga aty, ju inicializoni depozitën, kryeni ndryshimet në infrastrukturë dhe nëse diçka prishet, mund të ktheheni në një version të mëparshëm të Compose tuaj brenda sekondash . Për laboratorët ambiciozë në shtëpi, kjo nuk është thjesht një mundësi; është e vetmja mënyrë për të shmangur çmendurinë.

Rrjetet, Traefik dhe ekspozimi ndaj shërbimit të sigurt

Në pothuajse të gjitha laboratorët e shtëpisë me përparim të moderuar, shfaqet i njëjti kombinim: Traefik si një proxy i kundërt dhe një ofrues identiteti i centralizuar (Auth ose Authentik) . Kjo lejon ekspozimin e shumë aplikacioneve nën nën-domene me HTTPS dhe SSO.

Një qasje klasike është të krijoni një rrjet të dedikuar Docker, siç është reverse_proxy ose i ngjashëm, ku Traefik dhe të gjitha shërbimet web që do të ofroni nga jashtë janë të lidhura. Kontejnerët e mbetur (bazat e të dhënave, memorjet e fshehta, etj.) qëndrojnë në rrjete të brendshme të izoluara.

Nëse përdorni Traefik dhe i ndani shërbimet tuaja në instanca të ndryshme të Docker Compose, duhet të përcaktoni një rrjet të jashtëm të përbashkët . Diçka si kjo:

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

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

Këtu, rrjeti traefik_default krijohet nga grumbulli Traefik, dhe shërbimet e tjera i shtohen atij nëpërmjet një rrjeti të jashtëm të quajtur traefik-net. Etiketat i tregojnë Traefik se cilin rrjet të përdorë për drejtimin e trafikut.

Kur një pirg i vetëm përfshin shërbime backend (për shembull, një kontejner web dhe bazën e të dhënave të tij), ju mund t'i lidhni ato me një rrjet të paracaktuar të përbashkët dhe t'i jepni kontejnerit web qasje vetëm në rrjetin Traefik . Baza e të dhënave do të ketë një etiketë të vendosur në `traefik.enable=false` në mënyrë që Traefik ta injoroj atë.

Ky lloj konfigurimi ofron dy përfitime kryesore: izolimin midis shërbimeve dhe ekspozimin e kontrolluar . Vetëm kontejnerët që etiketoni me etiketat Traefik dhe që janë në rrjetin proxy bëhen të arritshëm nga jashtë.

Qëndrueshmëria e të dhënave, vëllimet dhe struktura e diskut

Një laborator shtëpiak pa të dhëna të përhershme nuk është shumë i dobishëm: bazat e të dhënave, konfigurimet, mediat, dokumentet… gjithçka duhet t'i mbijetojë një Docker Compose Down. Vëllimet dhe montimet e lidhjeve janë shpëtimi juaj.

Shumë njerëz organizojnë ruajtjen e tyre duke përdorur një strukturë si kjo:

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

Ideja është që shkarkuesit (qBittorrent, SABnzbd, etj.) shohin vetëm dosjen e shkarkimeve , menaxherët si Radarr/Sonarr kanë qasje si në shkarkime ashtu edhe në media (për të zhvendosur/krijuar lidhje të forta), dhe serverët si Plex ose Jellyfin shohin vetëm dosjen e mediave.

Në këtë mënyrë ju zbatoni parimin e privilegjit më të vogël : çdo kontejner qaset vetëm në atë që i nevojitet në të vërtetë. Dhe ndarja e qartë ndihmon gjithashtu kur vendosni se cilat vëllime ose shtigje duhet të ruhen në renë kompjuterike ose në disqet e jashtme.

Drejtoria srv përdoret zakonisht për të ruajtur konfigurimet e aplikacioneve (për shembull, /srv/jellyfin/config, /srv/traefik, /srv/paperless, etj.). Kjo zakonisht është pjesërisht e versionuar (shablone, Caddyfile, etj.), duke lënë jashtë çdo gjë kritike ose që kërkon shumë burime.

Në disa raste, është e dobishme të përdoren lidhje të forta në zinxhirin e shkarkimit: shërbime si Radarr ose Sonarr mund të lidhin skedarët e shkarkuar për të ruajtur mbjelljen pa dublikuar hapësirën e diskut. Struktura e direktorive e propozuar nga udhëzues si TRASHGuides bazohet pikërisht në këtë parim.

Automatizimi i vendosjeve me GitHub Actions dhe ekzekutues lokalë

Nëse ju pëlqen t’i çoni gjërat një hap më tej, mund të automatizoni përditësimet e homelab me CI/CD . Disa përdorues kanë zëvendësuar Jenkins dhe mjete të ngjashme me një rrjedhë pune duke përdorur GitHub Actions dhe një program ekzekutimi të vetë-strehuar brenda vetë homelab.

Mekanizmi është i thjeshtë: sa herë që klikoni në degën kryesore të depos suaj homelab, nis një rrjedhë pune GitHub Actions që ekzekuton teste, linters dhe, nëse gjithçka shkon mirë, vendos ndryshimet në server.

Një rrjedhë tipike pune përfshin hapa të tillë si:

• Skaner sekret i tipit Gitleaks: në rast se keni ngarkuar aksidentalisht fjalëkalime ose tokena në depo.
• Veshje të YAML ose kodit të infrastrukturës, për të ruajtur një format të lexueshëm dhe të qëndrueshëm.
• Përditësimi i depos brenda vetë homelab: git pull në serverin e synuar.
• Rikrijim i kontrolluar i kontejnerëvendaloni të vjetrat, hapni të rejat dhe kontrolloni statusin.

Avantazhet: siguri e shtuar (ju kontrolloni rrjedhjet e sekreteve), cilësi më e mirë e kodit dhe vendosje të përsëritshme me një shtypje të vetme . Dhe meqenëse përdorni një ekzekutues lokal, imazhet dhe vëllimet nuk dalin nga rrjeti juaj; ju thjesht shfrytëzoni ndërfaqen GitHub për të vizualizuar kanalet.

Pse Docker Compose e bën jetën shumë më të lehtë në një laborator shtëpiak

Shumë njerëz kanë kaluar vite duke u mbështetur te Docker Run dhe Portainer derisa, pas një incidenti ose migrimi, janë detyruar të rivlerësojnë qasjen e tyre. Kur humbni një host ose duhet të zhvendosni shërbimet në një makinë tjetër, mbështetja vetëm te komandat ose konfigurimet e izoluara brenda Portainer është një kurth.

Dallimi i madh kur kaloni te Compose është se i gjithë përkufizimi i shërbimit bëhet tekst : vëllime, porta, rrjete, etiketa, variabla… Të gjitha në një skedar YAML që mund ta kopjoni, ndani, versiononi dhe ripërdorni.

Redaktimi i një shërbimi nuk ka më të bëjë me "rindërtimin e një kontejneri me dorë"; tani ka të bëjë me modifikimin e një rreshti në një skedar, ruajtjen dhe ekzekutimin e `docker compose up -d` . Nuk keni nevojë të mbani mend komandën origjinale ose të klikoni nëpër ekrane të shumta të Portainer.

Për më tepër, nëse punoni me servera të shumtë (mini PC, NAS, desktopë), është jashtëzakonisht e përshtatshme të jeni në gjendje të kopjoni të njëjtin skedar Compose në një makinë tjetër, të rregulloni katër shtigje dhe të ekzekutoni të njëjtin pirg në pajisje të ndryshme . Në fakt, shumë njerëz e pranojnë se, pas një frike që përfshin humbje të të dhënave ose migrime kaotike, Compose u ka kursyer shumë kohë në ngjarjet pasuese.

Si një bonus shtesë, ndërtimi i shërbimeve të reja nga ato të vjetrat bëhet i thjeshtë: për shembull, klonimi i konfigurimit Plex për të konfiguruar Jellyfin duke ripërdorur të njëjtat shtigje mediatike dhe pajisje transkodimi zgjat vetëm disa minuta nëse e bëni duke kopjuar blloqe YAML.

Optimizimi: ndërtimi i kontekstit, ndërtimet dhe burimet shumëfazore

Edhe pse shumë kontejnerë të Homelab vijnë nga imazhe publike, në disa raste ju do të kompiloni tuajin. Në këto raste, është e rëndësishme të menaxhoni kontekstin e ndërtimit tuaj : mos e ngarkoni të gjithë depozitën pa filtruar, por kufizohuni në dosjen e projektit tuaj (duke përdorur një direktivë të fortë `.dockerignore`) për të siguruar ndërtime të shpejta dhe të lehta.

Një teknikë tjetër shumë e dobishme është përdorimi i ndërtimeve shumëfazore në Dockerfiles tuaj: në fazën e parë instaloni varësitë dhe kompiloni, dhe në fazën e dytë kopjoni vetëm artefaktet e nevojshme në një imazh bazë të vogël. Rezultati: imazhe përfundimtare shumë më të vogla dhe më të sigurta , sepse ato nuk mbartin zinxhirë mjetesh ose librari të panevojshme.

Nga ana e Kompozimit, ju keni mundësinë të përcaktoni kufijtë e CPU-së dhe RAM-it (veçanërisht në mjediset Swarm ose kur Docker i respekton këto parametra) për të parandaluar që aplikacionet që kërkojnë shumë burime të konsumojnë burimet. Në Homelabs, kjo ndihmon në parandalimin e një shërbimi të konfiguruar gabimisht që dëmton pjesën tjetër të sistemit.

Mos harroni politikat e rinisjes (ristart: always, unless-stopped, on-failure): me anë të tyre ju siguroni që shërbimet kritike (reverse proxy, VPN, bazat e të dhënave kyçe) të rinisin automatikisht pas një rinisjeje ose një dështimi të vetëm.

Së fundmi, këshillohet të planifikoni detyra periodike pastrimi me komanda të tilla si docker image prune, docker container prune dhe docker volume prune për të hequr mbetjet e ndërtimeve të vjetra, kontejnerëve të ndaluar ose vëllimeve jetimë dhe kështu të rikuperoni hapësirën e diskut.

Shërbime shëndetësore, regjistrim dhe monitorim

Për të parandaluar që homelab-i juaj të shndërrohet në një kuti të zezë, është e rëndësishme të punoni në tre aspekte kryesore: kontrollet shëndetësore, regjistrimin e kontrolluar dhe monitorimin . Docker Compose ju lejon të deklaroni kontrolle shëndetësore për shërbim (duke përdorur komanda si `curl -f http://localhost` ose skripte specifike) që përcaktojnë nëse një kontejner është i shëndetshëm.

Kjo ju lejon të siguroheni që vetëm kontejnerët "e shëndetshëm" marrin trafik (për shembull, nëpërmjet Traefik) dhe që nëse ndalojnë së përgjigjuri, ato rinisen sipas politikës së konfiguruar. Kjo rrit ndjeshëm qëndrueshmërinë me përpjekje minimale.

Lidhur me regjistrat, rregullimi i drajverit të skedarit json me limitet e madhësisë maksimale dhe limiteve të skedarit maksimal parandalon mbushjen e diskut me gigabajt regjistra të harruar. Mjetet e uebit si Dozzle ju ndihmojnë të shfletoni regjistrat e të gjithë kontejnerëve nga një shfletues, gjë që është shumë e përshtatshme për debugging shërbimesh specifike.

Për metrika dhe monitorim të vazhdueshëm, kombinimi klasik është cAdvisor + Prometheus + Grafana . cAdvisor ekspozon statistikat e përdorimit të CPU-së, memories, diskut dhe rrjetit për çdo kontejner; Prometheus i mbledh ato periodikisht dhe Grafana i shfaq ato në panele tërheqëse, me alarme nëse ka ndonjë ndryshim të papritur.

Një homelab i konfiguruar mirë zakonisht përfshin Uptime Kuma për kontrollet e disponueshmërisë (HTTP, ICMP, TCP, etj.) dhe një sistem të automatizuar rezervimi si Duplicati për të kopjuar të dhëna kritike në disqe të tjera ose në cloud. Në këtë mënyrë, ju e dini se çfarë po ndodh dhe nëse diçka shkon keq, nuk humbni atë që është e rëndësishme.

Siguria dhe qasja në distancë në laboratorin shtëpiak

Pavarësisht se si ta konfiguroni vetë, siguria nuk është opsionale. Shumë njerëz zgjedhin të mos e ekspozojnë drejtpërdrejt NAS-in e tyre ose shërbimet e tij ndaj botës së jashtme , duke kufizuar aksesin në distancë përmes një VPN (WireGuard është një opsion shumë i popullarizuar për shkak të performancës dhe thjeshtësisë së tij).

Në këtë model, ruteri vepron si një portë hyrëse: vetëm një port i rastësishëm hapet për serverin VPN dhe, pasi të lidhet, të gjitha kërkesat për shërbimet e brendshme kalojnë nëpër një tunel të enkriptuar . As Traefik dhe as aplikacionet nuk ekspozohen ndaj internetit pa këtë filtrim paraprak.

Ata që preferojnë të mos e menaxhojnë vetë VPN-në e tyre, ndonjëherë i drejtohen Cloudflare Tunnel ose Tailscale për të aksesuar laboratorin e tyre në shtëpi pa hapur porta. Këto janë alternativa të përshtatshme, megjithëse nëse privatësia është përparësia juaj kryesore, do t'ju duhet të merrni në konsideratë se cilat meta të dhëna mund të mbledhin këto palë të treta.

Një praktikë tjetër e mirë është të enkriptosh serverin dhe disqet NAS , të aplikosh rregullisht patch-e dhe të kufizosh përditësimet automatike (shumë veta e shmangin Watchtower në favor të përditësimeve manuale të kontrolluara). Është më mirë të jesh pak prapa, por me kontroll sesa të prishësh gjysmën e Homelab për shkak të një përditësimi që nuk e ke kontrolluar.

Siç mund ta shihni, nuk keni nevojë të arrini një nivel "ndërmarrjeje", por këshillohet të vendosni një nivel minimal sigurie dhe disipline në mënyrë që laboratori juaj i shtëpisë të mos jetë një sitë ose një burim i vazhdueshëm frikësimi.

Në fund të fundit, ngritja e një laboratori serioz në shtëpi me Docker Compose është një përzierje e organizimit, logjikës së shëndoshë dhe gatishmërisë për të ndryshuar diçka: nëse gruponi shërbimet, përcaktoni mirë rrjetet, dokumentoni në Git dhe automatizoni pak, përfundoni me një mjedis që mund ta filloni me një komandë të vetme, të migroni lehtësisht në një makinë tjetër dhe të zgjeroheni pak nga pak pa u bërë një xhungël e pakontrollueshme.