„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 su konteineriais sukūrimas tapo daugelio technikų mėgstamu hobiu. „Docker Compose“ beveik visada yra šios sistemos pagrindas : apibrėžkite savo paslaugas YAML, versijuokite jas naudodami „Git“ ir paleiskite visą aplinką viena komanda.

Tačiau pradėjus augti, viskas pasikeičia: nuo dviejų ar trijų konteinerių pereinama prie dešimčių paslaugų, vidinių tinklų, atvirkštinių tarpinių serverių, duomenų bazių ir CI vykdytojų . Tuomet iškyla svarbiausias klausimas: vienas milžiniškas „Docker Compose“ egzempliorius ar daug mažų failų? Kaip tvarkyti 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 dirba su trimis skirtingais „Compose“ organizaciniais modeliais, kurių kiekvienas turi savų privalumų ir trūkumų. Tinkamo požiūrio pasirinkimas padeda išvengti daugybės problemų didinant pajėgumus arba migruojant į naują kompiuterį.

Viena vertus, yra tokių, kurie pradėjo nuo atskirų „Docker Run“ komandų, tada perėjo prie „Portainer“ ir galiausiai prie „Docker Compose“ . Tai tipiškas scenarijus: „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 pusėje yra tas, kuris viską sujungė į vieną „mega“ „docker-compose.yml“, galintį paleisti absoliučiai visas „homelab“ paslaugas: atvirkštinį tarpinį serverį, mediją, komunalines paslaugas, stebėjimą, LLM, duomenų bazes... Visa tai viename steke.

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

Gana elegantiškas sprendimas sujungia abu pasaulius: „šakninė“ „Docker-compose“ programa, kurioje yra ir kitų failų (kiekvienas yra programų arba paslaugų poaplankyje). Tokiu būdu išsaugosite bendrą namų laboratorijos vaizdą, tačiau nepatirsite 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 pasiekti 30, 40 ar 50 paslaugų (įskaitant atsarginių kopijų kūrimo paslaugas, pvz., duomenų bazes, talpyklas ar indeksavimo priemones), labai svarbu jose įvesti tvarką. Čia praverčia ir grupavimas pagal funkciją , ir „Docker Compose“ profilių naudojimas.

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ų privalumas yra tas, kad galite diegti tik dalį infrastruktūros pagal poreikį. Pavyzdžiui, mažai energijos naudojančiame mini kompiuteryje galite paleisti tik pagrindinės dalies ir infrastruktūros profilį, o dideliame serveryje su daugiau diskų ir GPU diegti tik medijos profilį.

Gerai suprojektuotose saugyklose šakniniame kataloge paprastai yra „pagrindinis“ failas „docker-compose.yml“, kuris naudoja „include“ funkciją, kad įkeltų atskirus failus į aplanką „apps/“ arba „services/“ . Be to, beveik visos paslaugos konfigūruojamos naudojant vieną globalų .env failą, o kai kurie slapti raktai saugomi kataloge „secrets/“ , o tai labai supaprastina pradinį nustatymą.

Vadovaujantis šia schema, namų laboratorijos valdymas iš esmės susiveda į .env failo ir slaptų raktų redagavimą, profilių įjungimą arba išjungimą ir sprendimą, kurias paslaugas paleisti kiekviename pagrindiniame kompiuteryje . Tai idealu, jei ketinate diegti tą patį programų rinkinį 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 kiekvienai paslaugai“.

Tie, kurie pasisako už vieną pagrindinį failą, paprastai pabrėžia kelis privalumus:

• 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ų: didžiulį YAML failą sunkiau prižiūrėti, padaugėja sujungimo konfliktų, o derinant konkrečią problemą tenka naršyti šimtų eilučių monstre. Neretai jaučiamas šioks toks apgailestavimas, kai viskas tampa per didelė.

Kitas būdas – turėti po failą „docker-compose.yml“ kiekvienai programai arba loginiam stekui , tokioje struktūroje:

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

Todėl kiekvienas konteineris vadinamas, pavyzdžiui, „bookstack-app-1“ arba „traefik-reverse-proxy-1“ , o tai padeda greitai rasti problemas: jei „bookstack-app-1“ konteineris sugenda, tiksliai žinote, kuriame aplanke ieškoti.

Vizualiai jis yra daug švaresnis ir leidžia valdyti kiekvieną paslaugą atskirai (paleisti, sustabdyti ar atnaujinti ją nepaveikiant kitų). Be to, tokios programos kaip „Dozzle“ pasinaudoja atskirų stekų privalumais, kad geriau tvarkytų žurnalus.

Trūkumas yra tas, kad jei viską per daug atskirsite, bendrų paslaugų (pvz., „Traefik“ ar bendrų tinklų) koordinavimas reikalauja šiek tiek daugiau dėmesio : turite deklaruoti išorinius tinklus, konkrečias „Traefik“ etiketes ir atsiminti kitų „Docker-Compose“ sukurtų tinklų nomenklatūrą.

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

Vienas iš labiausiai neįvertintų triukų yra konfigūracijos centralizavimas .env failuose . Užuot užtvindę savo docker-compose.yml failą aplinkos kintamaisiais, galite apibrėžti kažką panašaus į tai:

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

O YAML jie nurodomi kaip ${DB_USERNAME} arba ${DB_PASSWORD} . Tai leidžia „Compose“ lengvai skaityti, bendrinti kintamuosius tarp kelių paslaugų ir, svarbiausia, saugo slaptažodžius atskirame faile (kurį galite neįtraukti į „Git“).

Įvairiose aplinkose (gamybos, testavimo, kūrimo) labai naudinga naudoti „docker-compose.override.yml“ . Idėja yra turėti bazinį „docker-compose.yml“ failą ir, keičiant nustatymus, keisti tik tuos pakeitimus: prievadus, kelius, derinimo žymas ir kt.

Pavyzdžiui, kūrimo metu galite įkelti perrašymą, kuriame atidarote kitą prievadą, įjungiate derinimą ir prijungiate vietinį šaltinio kodą . Jūs neliečiate pagrindinio YAML, bet pritaikote steko aplinką, kurioje jį naudojate.

Akivaizdu, kad visko versijavimas naudojant „Git“ yra būtinas, jei norite, kad jūsų namų laboratorija būtų bent kiek profesionali . Paprastai turėsite kažką panašaus į tai:

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

Tada galite inicijuoti saugyklą, įdiegti infrastruktūros pakeitimus ir, jei kas nors sugenda, per kelias sekundes galite grįžti prie ankstesnės „Compose“ versijos . Ambicingoms namų laboratorijoms tai ne tik pasirinkimas; tai vienintelis būdas išvengti beprotybės.

Tinklai, „Traefik“ ir saugių paslaugų poveikis

Beveik visose vidutiniškai pažangiose namų laboratorijose rodomas tas pats derinys: „Traefik“ kaip atvirkštinis tarpinis serveris ir centralizuotas tapatybės teikėjas („Auth“ arba „Authentik“) . Tai leidžia pasiekti daugelį programų subdomenuose naudojant HTTPS ir SSO.

Klasikinis būdas – sukurti specialų „Docker“ tinklą, pvz., „reverse_proxy“ ar panašų, kuriame būtų prijungta „Traefik“ ir visos išoriškai teikiamos žiniatinklio paslaugos. Likę konteineriai (duomenų bazės, talpyklos ir kt.) lieka izoliuotuose vidiniuose tinkluose.

Jei naudojate „Traefik“ ir atskiriate savo paslaugas į skirtingus „Docker Compose“ egzempliorius, turite apibrėžti bendrą išorinį tinklą . Kažkas panašaus į tai:

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“ stekas, o kitos paslaugos prie jo pridedamos per išorinį tinklą, vadinamą „traefik-net“. Žymės nurodo „Traefik“, kurį tinklą naudoti srauto nukreipimui.

Kai viename steke yra vidinės paslaugos (pvz., žiniatinklio konteineris ir jo duomenų bazė), galite jas prijungti prie bendro numatytojo tinklo ir suteikti žiniatinklio konteineriui prieigą tik prie „Traefik“ tinklo . Duomenų bazės žyma bus nustatyta kaip `traefik.enable=false`, kad „Traefik“ ją ignoruotų.

Šio tipo sąranka suteikia du pagrindinius privalumus: izoliaciją tarp paslaugų ir kontroliuojamą poveikį . Iš 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 Compose Down“. Tomai ir susiejimo jungtys yra jūsų gelbėjimosi ratas.

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

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

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

Tokiu būdu taikomas mažiausių privilegijų principas : kiekvienas konteineris pasiekia tik tai, ko jam iš tikrųjų reikia. 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 naudinga naudoti kietąsias nuorodas atsisiuntimo grandinėje: tokios paslaugos kaip „Radarr“ ar „Sonarr“ gali susieti atsisiųstus failus, kad būtų išlaikytas siuntimas nedubliuojant vietos diske. Katalogų struktūra, siūloma tokių vadovų kaip „TRaSHGuides“, yra pagrįsta būtent šiuo principu.

Diegimų automatizavimas naudojant „GitHub Actions“ ir vietinius vykdytojus

Jei norite žengti dar vieną žingsnį, galite automatizuoti namų laboratorijos atnaujinimus naudodami CI/CD . Keletas vartotojų „Jenkins“ ir panašius įrankius pakeitė darbo eiga, naudodami „GitHub Actions“ ir vykdiklį, esantį pačioje namų laboratorijoje.

Mechanizmas paprastas: kiekvieną kartą, kai bandote pasiekti pagrindinę savo „homelab“ saugyklos šaką, paleidžiamas „GitHub Actions“ darbo procesas, kuris 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 pasikartojantys diegimai vienu paspaudimu . Kadangi naudojate vietinį vykdiklį, vaizdai ir tomai nepalieka jūsų tinklo; tiesiog naudojate „GitHub“ sąsają, kad vizualizuotumėte srautus.

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

Daugelis žmonių metų metus pasikliovė „Docker Run“ ir „Portainer“, kol po incidento ar migracijos buvo priversti iš naujo įvertinti savo požiūrį. Praradus pagrindinį kompiuterį arba perkėlus paslaugas į kitą kompiuterį, pasikliauti vien tik „Portainer“ komandomis ar konfigūracijomis yra spąstai.

Didžiausias skirtumas, kai perjungiate į „Compose“, yra tas, kad visas paslaugos apibrėžimas tampa tekstu : tomai, prievadai, tinklai, etiketės, kintamieji... Visa tai YAML faile, kurį galite kopijuoti, bendrinti, versuoti ir pakartotinai naudoti.

Paslaugos redagavimas nebėra susijęs su „konteinerio perkūrimu rankiniu būdu“; dabar reikia modifikuoti failo eilutę, išsaugoti ir paleisti 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ę nukopijuoti tą patį „Compose“ failą į kitą kompiuterį, pakoreguoti keturis kelius ir paleisti tą patį paketą skirtingose ​​aparatinėse sistemose . Tiesą sakant, 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 tas, kad naujų paslaugų kūrimas iš senų tampa paprastas: pavyzdžiui, „Plex“ konfigūracijos klonavimas, norint nustatyti „Jellyfin“, pakartotinai naudojant tuos pačius medijos kelius ir transkodavimo įrenginius, 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šųjų atvaizdų, kai kuriais atvejais kompiliuosite patys. Tokiais atvejais svarbu valdyti kompiliavimo kontekstą : neįkelkite visos saugyklos nefiltruotos, o apsiribokite savo projekto aplanku (naudodami stiprią `.dockerignore` direktyvą), kad užtikrintumėte greitą ir lengvą kompiliavimą.

Dar vienas labai naudingas metodas yra naudoti kelių etapų kompiliavimą „Dockerfiles“ failuose: pirmajame etape įdiegiate priklausomybes ir kompiliuojate, o antrajame etape į nedidelį bazinį atvaizdą kopijuojate tik būtinus artefaktus. Rezultatas: daug mažesni ir saugesni galutiniai atvaizdai , nes juose nėra nereikalingų įrankių grandinių ar bibliotekų.

„Compose“ pusėje galite apibrėžti procesoriaus ir RAM apribojimus (ypač „Swarm“ aplinkose arba kai „Docker“ atsižvelgia į šiuos parametrus), kad daug išteklių reikalaujančios programos neapkrautų išteklių. „Homelabs“ tai padeda išvengti netinkamai sukonfigūruotos paslaugos, kuri sutrikdytų likusios sistemos darbą.

Nepamirškite paleidimo iš naujo politikos (paleisti iš naujo: visada, nebent sustabdyta, gedimo atveju): jomis 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 patartina periodiškai atlikti valymo užduotis naudojant tokias komandas kaip „docker image prune“, „docker container prune“ ir „docker volume prune“, kad būtų pašalinti senų kompiliacijų, sustabdytų konteinerių ar našlaičių tomų likučiai ir taip atkurta vietos diske.

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

Kad jūsų namų laboratorija netaptų „juodąja dėže“, svarbu dirbti su trimis pagrindiniais aspektais: sveikatos patikromis, kontroliuojamu registravimu ir stebėjimu . „Docker Compose“ leidžia deklaruoti sveikatos patikras kiekvienai paslaugai (naudojant tokias komandas kaip „curl -f http://localhost“ arba konkrečius scenarijus), kurios nustato, ar konteineris yra sveikas.

Tai leidžia užtikrinti, kad srautą gautų tik „sveiki“ konteineriai (pavyzdžiui, per „Traefik“) ir kad jiems nustojus reaguoti, jie būtų paleisti iš naujo pagal sukonfigūruotą politiką. Tai žymiai padidina atsparumą minimaliomis pastangomis.

Kalbant apie žurnalus, pakoregavus JSON failų tvarkyklę su maksimaliu dydžiu ir maksimaliu failų skaičiumi , diskas neužsipildo gigabaitais 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.

Metrikoms ir nuolatiniam stebėjimui klasikinis derinys yra „cAdvisor“ + „Prometheus“ + „Grafana“ . „cAdvisor“ pateikia procesoriaus, atminties, disko ir tinklo naudojimo statistiką kiekvienam konteineriui; „Prometheus“ ją periodiškai renka, o „Grafana“ rodo patraukliose ataskaitų suvestinėse, įspėdama apie padidėjimą.

Gerai įrengtoje namų laboratorijoje paprastai yra „Uptime Kuma“ prieinamumo patikrinimams (HTTP, ICMP, TCP ir kt.) ir automatinė atsarginių kopijų kūrimo sistema, pvz., „Duplicati“, skirta svarbiems duomenims kopijuoti į kitus diskus arba debesį. Tokiu būdu žinote, kas vyksta, ir jei kas nors nutiks ne taip, neprarasite to, kas svarbu.

Saugumas ir nuotolinė prieiga prie namų laboratorijos

Kad ir kaip bebūtumėte įdiegę įrenginį patys, saugumas nėra neprivalomas. Daugelis žmonių nusprendžia tiesiogiai neatskleisti savo NAS ar jo paslaugų išoriniam pasauliui , ribodami nuotolinę prieigą per VPN („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 programos nėra pasiekiamos internetu be šio išankstinio filtravimo.

Tie, kurie nenori patys tvarkyti savo VPN, kartais naudojasi „Cloudflare Tunnel“ arba „Tailscale“ , kad pasiektų savo namų laboratoriją neatidarydami prievadų. Tai patogios alternatyvos, tačiau jei privatumas yra jūsų svarbiausias prioritetas, turėsite apsvarstyti, kokius metaduomenis šios trečiosios šalys gali rinkti.

Kita gera praktika – šifruoti serverio ir NAS diskus , reguliariai diegti pataisas ir riboti automatinius atnaujinimus (daugelis vengia „Watchtower“ ir renkasi kontroliuojamus rankinius atnaujinimus). Geriau šiek tiek atsilikti, bet kontroliuoti procesą, nei sugadinti pusę „Homelab“ dėl nepatikrinto atnaujinimo.

Kaip matote, nebūtina pasiekti „įmonės“ lygio, tačiau patartina nustatyti minimalų saugumo ir drausmės lygį , 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.