Docker-in-Docker er sýndarvædd Docker púkaumhverfi sem keyrir innan ílátsins sjálfs til að búa til gámamyndir. Megintilgangur þess að búa til Docker-in-Docker var að hjálpa til við að þróa Docker sjálft. Margir nota það til að keyra Jenkins CI. Þetta virðist eðlilegt í fyrstu, en síðan koma upp vandamál sem hægt er að forðast með því að setja Docker upp í Jenkins CI gám. Þessi grein segir þér hvernig á að gera þetta. Ef þú hefur áhuga á endanlegri lausn án smáatriði, lestu bara síðasta hluta greinarinnar, "Að leysa vandamálið."
Docker-in-Docker: „Gott“
Fyrir meira en tveimur árum síðan fór ég í Docker -forréttindi og skrifaði . Markmiðið var að hjálpa kjarnateyminu að þróa Docker hraðar. Fyrir Docker-in-Docker leit dæmigerð þróunarferill svona út:
- hackity hakk;
- byggja;
- stöðva hlaupandi Docker púka;
- kynnir nýjan Docker púkk;
- prófun;
- endurtaka hringinn.
Ef þú vildir búa til fallega samsetningu sem hægt er að endurskapa (þ.e. í ílát) þá varð það flóknara:
- hackity hakk;
- ganga úr skugga um að vinnandi útgáfa af Docker sé í gangi;
- byggja nýjan Docker með gamla Docker;
- stöðva Docker púkinn;
- byrjaðu nýjan Docker púka;
- próf;
- stöðva nýjan Docker púkk;
- endurtaka.
Með tilkomu Docker-in-Docker hefur ferlið orðið einfaldara:
- hackity hakk;
- samsetning + sjósetja í einu stigi;
- endurtaka hringinn.
Er þetta ekki miklu betra svona?
Docker-in-Docker: „Slæmt“
Hins vegar, þvert á almenna trú, er Docker-in-Docker ekki 100% stjörnur, hestar og einhyrningar. Það sem ég á við er að það eru nokkur atriði sem verktaki þarf að vera meðvitaður um.
Ein þeirra varðar LSM (Linux öryggiseiningar) eins og AppArmor og SELinux: þegar gámur er keyrður gæti „innri Docker“ reynt að beita öryggissniðum sem munu stangast á eða rugla „ytri Docker“. Þetta er erfiðasta vandamálið til að leysa þegar reynt er að sameina upprunalega útfærslu –forréttindafánans. Breytingarnar mínar virkuðu og allar prófanir myndu standast Debian vélina mína og Ubuntu prófunar VMs, en þær hrundu og brenndu á vél Michael Crosby (hann var með Fedora að mig minnir). Ég man ekki nákvæmlega orsök vandans, en það gæti hafa verið vegna þess að Mike er vitur strákur sem vinnur með SELINUX=enforce (ég notaði AppArmor) og breytingarnar mínar tóku ekki tillit til SELinux prófíla.
Docker-in-Docker: "Evil"
Annað málið er með Docker geymslurekla. Þegar þú keyrir Docker-in-Docker keyrir ytri Docker ofan á venjulegt skráarkerfi (EXT4, BTRFS, eða hvað sem þú hefur) og innri Docker keyrir ofan á copy-on-write kerfi (AUFS, BTRFS, Device Mapper) , osfrv.), allt eftir því hvað er stillt til að nota ytri Docker). Þetta skapar margar samsetningar sem munu ekki virka. Til dæmis muntu ekki geta keyrt AUFS ofan á AUFS.
Ef þú keyrir BTRFS ofan á BTRFS ætti það að virka í fyrstu, en þegar það eru hreiðruð undirbindi mun það mistakast að eyða yfirundirbindi. Device Mapper einingin hefur ekkert nafnrými, þannig að ef mörg Docker tilvik eru að keyra hana á sömu vélinni, munu þau öll geta séð (og haft áhrif á) myndirnar hver á annarri og á gámaafritunartækjunum. Þetta er slæmt.
Það eru til lausnir til að leysa mörg af þessum vandamálum. Til dæmis, ef þú vilt nota AUFS í innri Docker, breytirðu bara /var/lib/docker möppunni í bindi og þú munt vera í lagi. Docker hefur bætt nokkrum grunnnafnasvæðum við Device Mapper marknöfn þannig að ef mörg Docker símtöl eru í gangi á sömu vélinni munu þau ekki stíga á hvort annað.
Slík uppsetning er þó alls ekki einföld eins og sjá má af þessum í dind geymslunni á GitHub.
Docker-in-Docker: Það versnar
Hvað með smíða skyndiminni? Þetta getur líka verið frekar erfitt. Fólk spyr mig oft „ef ég er að keyra Docker-in-Docker, hvernig get ég notað myndir sem eru hýstar á gestgjafanum mínum í stað þess að draga allt aftur í innri Docker minn“?
Sumt framtakssamt fólk hefur reynt að binda /var/lib/docker frá hýsilnum við Docker-in-Docker gám. Stundum deila þeir /var/lib/docker með mörgum ílátum.
Viltu skemma gögnin þín? Vegna þess að þetta er einmitt það sem mun skemma gögnin þín!
Docker púkinn var greinilega hannaður til að hafa einkaaðgang að /var/lib/docker. Ekkert annað ætti að „snerta, pota eða stinga“ á neinar Docker skrár sem eru staðsettar í þessari möppu.
Hvers vegna er þetta svona? Vegna þess að þetta er afleiðing af einni erfiðustu lexíu sem lærðist við þróun dotCloud. DotCloud gámavélin keyrði með því að hafa marga ferla aðgang að /var/lib/dotcloud samtímis. Slæm brellur eins og að skipta um atómskrár (í stað þess að klippa á staðnum), töfra kóða með ráðgefandi og lögboðnum læsingum og aðrar tilraunir með örugg kerfi eins og SQLite og BDB virkuðu ekki alltaf. Þegar við vorum að endurhanna gámavélina okkar, sem á endanum varð Docker, var ein af stóru hönnunarákvörðunum að sameina allar gámaaðgerðir undir einum púka til að útrýma allri samhliða vitleysunni.
Ekki misskilja mig: það er alveg hægt að búa til eitthvað gott, áreiðanlegt og hratt sem felur í sér marga ferla og nútíma samhliða stjórnun. En við teljum að það sé einfaldara og auðveldara að skrifa og viðhalda kóða með Docker sem eina spilarann.
Þetta þýðir að ef þú deilir /var/lib/docker skránni á milli margra Docker tilvika muntu eiga í vandræðum. Auðvitað getur þetta virkað, sérstaklega á fyrstu stigum prófunar. "Heyrðu, mamma, ég get keyrt Ubuntu sem hafnarmann!" En reyndu eitthvað flóknara, eins og að draga sömu myndina úr tveimur mismunandi tilfellum, og þú munt sjá heiminn brenna.
Þetta þýðir að ef CI kerfið þitt framkvæmir smíði og endurbyggingu, í hvert skipti sem þú endurræsir Docker-in-Docker gáminn þinn, þá er hætta á að kjarnorkusprengja sleppti í skyndiminni þess. Þetta er alls ekki flott!
Lausnin
Við skulum taka skref til baka. Þarftu virkilega Docker-in-Docker eða vilt þú bara geta keyrt Docker og smíðað og keyrt gáma og myndir úr CI kerfinu þínu á meðan það CI kerfi sjálft er í gámi?
Ég veðja á að flestir vilji síðari kostinn, sem þýðir að þeir vilja að CI kerfi eins og Jenkins geti keyrt gáma. Og auðveldasta leiðin til að gera þetta er einfaldlega að setja Docker-innstunguna í CI-ílátið þitt og tengja það við -v-fánann.
Einfaldlega sagt, þegar þú keyrir CI gáminn þinn (Jenkins eða annað), í stað þess að hakka eitthvað ásamt Docker-in-Docker, byrjaðu það með línunni:
docker run -v /var/run/docker.sock:/var/run/docker.sock ...Þessi gámur mun nú hafa aðgang að Docker falsinu og geta því keyrt gáma. Nema að í stað þess að keyra „barn“ gáma mun það ræsa „systkini“ gáma.
Prófaðu þetta með því að nota opinberu Docker myndina (sem inniheldur Docker tvöfaldann):
docker run -v /var/run/docker.sock:/var/run/docker.sock
-ti dockerÞað lítur út og virkar eins og Docker-in-Docker, en það er ekki Docker-in-Docker: þegar þessi gámur býr til viðbótargáma verða þeir búnir til í efsta stigi Docker. Þú munt ekki upplifa aukaverkanir af hreiður og samsetningarskyndiminni verður deilt yfir mörg símtöl.
Athugið: Fyrri útgáfur þessarar greinar ráðlögðu að tengja Docker tvöfaldann frá hýsilnum við ílátið. Þetta er nú orðið óáreiðanlegt þar sem Docker vélin nær ekki lengur yfir kyrrstæð eða næstum kyrrstæð bókasöfn.
Svo, ef þú vilt nota Docker frá Jenkins CI, hefurðu 2 valkosti:
setja upp Docker CLI með því að nota grunnmyndapökkunarkerfið (þ.e. ef myndin þín er byggð á Debian, notaðu .deb pakka), með því að nota Docker API.
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com