Docker-in-Docker ir virtualizÄta Docker dÄmona vide, kas darbojas paÅ”Ä konteinerÄ, lai izveidotu konteinera attÄlus. Galvenais Docker-in-Docker izveides mÄrÄ·is bija palÄ«dzÄt attÄ«stÄ«t paÅ”u Docker. Daudzi cilvÄki to izmanto, lai palaistu Jenkins CI. SÄkumÄ tas Ŕķiet normÄli, bet pÄc tam rodas problÄmas, no kurÄm var izvairÄ«ties, instalÄjot Docker Jenkins CI konteinerÄ. Å ajÄ rakstÄ ir aprakstÄ«ts, kÄ to izdarÄ«t. Ja jÅ«s interesÄ galÄ«gais risinÄjums bez detaļÄm, vienkÄrÅ”i izlasiet raksta pÄdÄjo sadaļu āProblÄmas risinÄÅ”anaā.
Docker-in-Docker: "Labi"
VairÄk nekÄ pirms diviem gadiem es ievietoju Docker ā priviliÄ£Äts un rakstÄ«ja . MÄrÄ·is bija palÄ«dzÄt galvenajai komandai ÄtrÄk attÄ«stÄ«t Docker. Pirms Docker-in-Docker tipiskais izstrÄdes cikls izskatÄ«jÄs Å”Ädi:
- hackity hack;
- bÅ«vÄt;
- darbojas Docker dÄmona apturÄÅ”ana;
- jauna Docker dÄmona palaiÅ”ana;
- testÄÅ”ana;
- atkÄrtojiet ciklu.
Ja vÄlaties izveidot skaistu, reproducÄjamu komplektu (tas ir, konteinerÄ), tas kļuva sarežģītÄks:
- hackity hack;
- pÄrliecinieties, vai darbojas Docker darba versija;
- izveidot jaunu Docker ar veco Docker;
- apturÄt Docker dÄmonu;
- sÄkt jaunu Docker dÄmonu;
- pÄrbaude;
- apturÄt jaunu Docker dÄmonu;
- atkÄrtojiet.
LÄ«dz ar Docker-in-Docker parÄdÄ«Å”anos process ir kļuvis vienkÄrÅ”Äks:
- hackity hack;
- montÄža + palaiÅ”ana vienÄ posmÄ;
- atkÄrtojiet ciklu.
Vai Å”ÄdÄ veidÄ nav daudz labÄk?
Docker-in-Docker: "Slikti"
TomÄr pretÄji plaÅ”i izplatÄ«tam uzskatam Docker-in-Docker nav 100% zvaigznes, poniji un vienradži. Es domÄju, ka izstrÄdÄtÄjam ir jÄapzinÄs vairÄkas problÄmas.
Viens no tiem attiecas uz LSM (Linux droŔības moduļiem), piemÄram, AppArmor un SELinux: palaižot konteineru, "iekÅ”Äjais Docker" var mÄÄ£inÄt lietot droŔības profilus, kas konfliktÄs vai sajauks "ÄrÄjo Docker". Å Ä« ir visgrÅ«tÄk risinÄmÄ problÄma, mÄÄ£inot apvienot priviliÄ£ÄtÄ karoga sÄkotnÄjo ievieÅ”anu. Manas izmaiÅas darbojÄs, un visi testi tika nodoti manai Debian maŔīnai un Ubuntu testa virtuÄlajÄm maŔīnÄm, taÄu tÄs avarÄja un sadedzinÄja Maikla Krosbija maŔīnÄ (viÅam bija Fedora, cik es atceros). Es nevaru atcerÄties precÄ«zu problÄmas cÄloni, bet tas varÄtu bÅ«t tÄpÄc, ka Maiks ir gudrs puisis, kurÅ” strÄdÄ ar SELINUX=enforce (es izmantoju AppArmor), un manas izmaiÅas neÅÄma vÄrÄ SELinux profilus.
Docker-in-Doker: "Ļaunums"
OtrÄ problÄma ir saistÄ«ta ar Docker krÄtuves draiveriem. Palaižot Docker-in-Docker, ÄrÄjais Docker darbojas virs parastÄs failu sistÄmas (EXT4, BTRFS vai jebkura cita), un iekÅ”Äjais Docker darbojas uz kopÄÅ”anas un rakstÄ«Å”anas sistÄmas (AUFS, BTRFS, Device Mapper). u.c.). , atkarÄ«bÄ no tÄ, kas ir konfigurÄts ÄrÄjÄ Docker izmantoÅ”anai). Tas rada daudzas kombinÄcijas, kas nedarbosies. PiemÄram, jÅ«s nevarÄsit palaist AUFS papildus AUFS.
Ja palaižat BTRFS papildus BTRFS, tam vispirms vajadzÄtu darboties, taÄu, tiklÄ«dz ir ligzdotie apakÅ”sÄjumi, vecÄkapsÄjums neizdosies izdzÄst. Modulim Device Mapper nav nosaukumvietas, tÄdÄļ, ja tajÄ paÅ”Ä datorÄ to palaiž vairÄkas Docker instances, tÄs visas varÄs redzÄt (un ietekmÄt) attÄlus savÄ starpÄ un konteinera dublÄÅ”anas ierÄ«cÄs. Tas ir slikti.
Ir risinÄjumi, lai atrisinÄtu daudzas no Ŕīm problÄmÄm. PiemÄram, ja vÄlaties izmantot AUFS iekÅ”ÄjÄ Docker, vienkÄrÅ”i pÄrveidojiet mapi /var/lib/docker par sÄjumu, un viss bÅ«s kÄrtÄ«bÄ. Docker ir pievienojis dažas pamata nosaukumvietas Device Mapper mÄrÄ·a nosaukumiem, lai, ja vienÄ un tajÄ paÅ”Ä iekÄrtÄ darbojas vairÄki Docker zvani, tie nedarbosies viens otram.
TomÄr Å”Äda iestatÄ«Å”ana nepavisam nav vienkÄrÅ”a, kÄ redzams no Å”iem dind repozitorijÄ vietnÄ GitHub.
Docker-in-Docker: tas pasliktinÄs
KÄ ar bÅ«vÄÅ”anas keÅ”atmiÅu? Tas var bÅ«t arÄ« diezgan grÅ«ti. CilvÄki man bieži jautÄ: āJa es izmantoju Docker-in-Docker, kÄ es varu izmantot resursdatorÄ mitinÄtus attÄlus, nevis ievilkt visu atpakaļ savÄ iekÅ”ÄjÄ Dockerā?
Daži uzÅÄmÄ«gi cilvÄki ir mÄÄ£inÄjuÅ”i saistÄ«t /var/lib/docker no resursdatora ar Docker-in-Docker konteineru. Dažreiz tie koplieto /var/lib/docker ar vairÄkiem konteineriem.
Vai vÄlaties sabojÄt savus datus? Jo tieÅ”i tas sabojÄs jÅ«su datus!
Docker dÄmons tika skaidri izstrÄdÄts tÄ, lai tam bÅ«tu ekskluzÄ«va piekļuve /var/lib/docker. Nekam citam nevajadzÄtu "pieskarties, bakstÄ«t vai producÄt" Docker failus, kas atrodas Å”ajÄ mapÄ.
KÄpÄc tas tÄ ir? Jo tas ir rezultÄts vienai no grÅ«tÄkajÄm mÄcÄ«bÄm, kas gÅ«tas, izstrÄdÄjot dotCloud. DotCloud konteinera dzinÄjs darbojÄs, vairÄkiem procesiem vienlaikus piekļūstot /var/lib/dotcloud. ViltÄ«gi triki, piemÄram, atomu failu aizstÄÅ”ana (nevis rediÄ£ÄÅ”ana uz vietas), koda papildinÄÅ”ana ar ieteikuma un obligÄtajÄm slÄdzenÄm un citi eksperimenti ar droÅ”Äm sistÄmÄm, piemÄram, SQLite un BDB, ne vienmÄr darbojÄs. Kad mÄs pÄrprojektÄjÄm savu konteineru dzinÄju, kas galu galÄ kļuva par Docker, viens no lielÄkajiem projektÄÅ”anas lÄmumiem bija apvienot visas konteineru darbÄ«bas vienÄ dÄmonÄ, lai novÄrstu visas vienlaicÄ«bas muļķības.
NepÄrprotiet mani nepareizi: ir pilnÄ«gi iespÄjams izveidot kaut ko labu, uzticamu un Ätru, kas ietver vairÄkus procesus un modernu paralÄlo vadÄ«bu. TaÄu mÄs domÄjam, ka ir vienkÄrÅ”Äk un vieglÄk rakstÄ«t un uzturÄt kodu, izmantojot Docker kÄ vienÄ«go atskaÅotÄju.
Tas nozÄ«mÄ, ka, koplietojot direktoriju /var/lib/docker starp vairÄkiem Docker gadÄ«jumiem, radÄ«sies problÄmas. Protams, tas var darboties, it Ä«paÅ”i agrÄ«nÄ testÄÅ”anas stadijÄ. "Klausies, mÄt, es varu palaist ubuntu kÄ dokeris!" Bet izmÄÄ£iniet kaut ko sarežģītÄku, piemÄram, izvelciet vienu un to paÅ”u attÄlu no diviem dažÄdiem gadÄ«jumiem, un jÅ«s redzÄsit, ka pasaule sadeg.
Tas nozÄ«mÄ, ka, ja jÅ«su CI sistÄma veic bÅ«vÄÅ”anu un pÄrbÅ«vi, ikreiz, kad restartÄjat Docker-in-Docker konteineru, jÅ«s riskÄjat iemest kodolu tÄs keÅ”atmiÅÄ. Tas nemaz nav forÅ”i!
RisinÄjums
AtkÄpsimies soli atpakaļ. Vai jums tieÅ”Äm ir nepiecieÅ”ams Docker-in-Docker vai vienkÄrÅ”i vÄlaties palaist Docker un izveidot un palaist konteinerus un attÄlus no savas CI sistÄmas, kamÄr pati CI sistÄma atrodas konteinerÄ?
Varu derÄt, ka lielÄkÄ daļa cilvÄku vÄlas pÄdÄjo iespÄju, kas nozÄ«mÄ, ka viÅi vÄlas, lai CI sistÄma, piemÄram, Dženkinss, varÄtu darbinÄt konteinerus. Un vienkÄrÅ”Äkais veids, kÄ to izdarÄ«t, ir vienkÄrÅ”i ievietot Docker ligzdu savÄ CI konteinerÄ un saistÄ«t to ar karogu -v.
VienkÄrÅ”i sakot, kad palaižat CI konteineru (Jenkins vai citu), tÄ vietÄ, lai kaut ko uzlauztu kopÄ ar Docker-in-Docker, sÄciet to ar rindiÅu:
docker run -v /var/run/docker.sock:/var/run/docker.sock ...Å im konteineram tagad bÅ«s piekļuve Docker ligzdai, un tÄpÄc tas varÄs palaist konteinerus. IzÅemot to, ka tÄ vietÄ, lai palaistu ābÄrnuā konteinerus, tiks palaists ābrÄļuā konteineri.
IzmÄÄ£iniet Å”o, izmantojot oficiÄlo docker attÄlu (kurÄ ir Docker binÄrs):
docker run -v /var/run/docker.sock:/var/run/docker.sock
-ti dockerTas izskatÄs un darbojas kÄ Docker-in-Docker, taÄu tas nav Docker-in-Docker: kad Å”is konteiners izveidos papildu konteinerus, tie tiks izveidoti augstÄkÄ lÄ«meÅa Docker. JÅ«s nesajutÄ«sit ligzdoÅ”anas blakusparÄdÄ«bas, un montÄžas keÅ”atmiÅa tiks koplietota vairÄkiem zvaniem.
PiezÄ«me. Å Ä« raksta iepriekÅ”ÄjÄs versijÄs tika ieteikts saistÄ«t Docker binÄro failu no resursdatora uz konteineru. Tagad tas ir kļuvis neuzticams, jo Docker dzinÄjs vairs neaptver statiskas vai gandrÄ«z statiskas bibliotÄkas.
TÄtad, ja vÄlaties izmantot Jenkins CI Docker, jums ir 2 iespÄjas:
Docker CLI instalÄÅ”ana, izmantojot pamata attÄlu pakoÅ”anas sistÄmu (t.i., ja jÅ«su attÄls ir balstÄ«ts uz Debian, izmantojiet .deb pakotnes), izmantojot Docker API.
Dažas reklÄmas š
Paldies, ka palikÄt kopÄ ar mums. Vai jums patÄ«k mÅ«su raksti? Vai vÄlaties redzÄt interesantÄku saturu? Atbalsti mÅ«s, pasÅ«tot vai iesakot draugiem, , unikÄls sÄkuma lÄ«meÅa serveru analogs, ko mÄs jums izgudrojÄm: (pieejams ar RAID1 un RAID10, lÄ«dz 24 kodoliem un lÄ«dz 40 GB DDR4).
Dell R730xd 2x lÄtÄk Equinix Tier IV datu centrÄ AmsterdamÄ? Tikai Å”eit NÄ«derlandÄ! Dell R420 ā 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB ā no 99 USD! LasÄ«t par
Avots: www.habr.com