Mõelge hoolikalt, enne kui kasutate Docker-in-Docker'i CI või testkeskkonnas

Docker-in-Docker on Docker-teenuse virtuaalset keskkonda, mis töötab konteineri sees, et luua konteineripilte. Docker-in-Docker'i peamine eesmärk oli aidata Dockerit arendada. Paljud kasutavad seda Jenkins CI käitamiseks. Esialgu tundub see normaalne, kuid hiljem tekivad probleemid, mida oleks saanud vältida, kui Docker installida Jenkins CI konteinerisse. Selles artiklis räägitakse, kuidas seda teha. Kui teid huvitab viimane lahendus ilma üksikasjade vaatamiseta, loe lihtsalt artikli „Probleemi lahendamine” viimane osa.

Docker-in-Docker: „Hea”

Ükskord rohkem kui kaks aastat tagasi lisasin Dockerisse lipuke –privileged ja kirjutasin esimese versiooni dind. Eesmärk oli aidata põhimeeskonnal Dockerit kiiremini arendada. Enne Docker-in-Docker'i ilmumist nägi tüüpiline arendustsükkel välja järgmine:

• hackity hack;
• koostamine (build);
• käivitatud Docker-teenuse peatamine;
• uue Docker-teenuse käivitamine;
• testimine;
• tsükli kordamine.

Kuid kui soovisite teha ilusat, korratavasse pakkesse (st konteinerisse), muutus see keerulisemaks:

• hackity hack;
• veenduda, et käimas on toimiv Docker versioon;
• koosta uus Docker vana Dockeriga;
• peatada Docker daemon;
• käivitada uus Docker daemon;
• testida;
• peatada uus Docker daemon;
• korrata.

Docker-in-Docker'i tulek on protsessi lihtsustanud:

• hackity hack;
• ehitamine + käivitamine ühes etapis;
• tsükli kordamine.

Küsi endalt, kas see ei ole palju parem?

Docker-in-Docker: "Halb"

Kuid vastupidiselt levinud arvamusele, ei koosne Docker-in-Docker 100% tähekestest, poniidest ja ükssarvikutest. Ma tahan öelda, et on mõned probleemid, millest arendajal tasub teadlik olla.

Üks neist puudutab LSM-i (Linuxi turvamuuduleid), nagu AppArmor ja SELinux: konteineri käivitamisel võib "sisemine Docker" proovida rakendada turvaprofiile, mis võivad "välist Dockerit" segadusse ajada või konfliktidesse sattuda. See oli kõige keerulisem probleem, mida oli vaja lahendada lähtudes -privileged lippu. Minu muudatused toimisid ja kõik testid oleksid ka minu Debianis ja Ubuntu teste virtuaalmasinates läkid tegevuse, kuid nad kukuksid ja sureksid Michael Crosby masinas (kui ma õigesti mäletan, oli tal Fedora). Ma ei suuda täpselt meenutada probleemi põhjust, kuid see võis tekkida selle tõttu, et Mike on tark mees, kes töötab SELINUX=enforce tingimustes (ma kasutasin AppArmore), ning minu muudatused ei võtnud arvesse SELinuxi profile.

Docker-in-Docker: "Kurjuse"

Teiseks probleemiks on Docker'i salvestusjuhikud. Kui käitate Docker'it Docker'i sees, töötab väline Docker tavalise failisüsteemi (EXT4, BTRFS või muu, mis teil on) peal, samas kui sisemine Docker töötab kirjutamise koopiasüsteemi (AUFS, BTRFS, Device Mapper jne, sõltuvalt sellest, mis on konfigureeritud välise Docker'i jaoks). See tekitab palju kombinatsioone, mis ei tööta. Näiteks ei saa te käivitada AUFS'i AUFS'i peal.

Kui käitate BTRFS'i BTRFS'i peal, peaks see esmalt töötama, kuid kui ilmnevad sisemised alamhõivad, ei saa vanemat alamhõivet kustutada. Device Mapper'il ei ole nimeruumi, seega kui mitu Docker'i instantsi kasutavad seda ühel masinal, saavad kõik neist näha (ja mõjutada) üksteise pilte ja konteinerite varundusseadmeid. See on halb.

On olemas vältimised paljude nende probleemide lahendamiseks. Näiteks, kui soovite kasutada AUFS-i sisemises Dockeris, muutke lihtsalt kaust /var/lib/docker montaažiks ja kõik töötab nagu peab. Docker on lisanud sihtmärkide seadme kaardile mõned põhiraamid, nii et kui mitu Docker'i kutset töötab ühel masinal, ei lähe need „üks teise peale.”

Siiski, selline seadistus pole sugugi lihtne, nagu saate näha nendest artiklites dind'i hoidlast GitHub'is.

Docker-in-Docker: muutub veel keerulisemaks

Aga kuidas on ehituskatalooge? See võib samuti olla üsna keeruline. Inimesed küsivad tihti, "kui ma käitan Docker-in-Docker't, kuidas saan kasutada oma hostis asuvaid pilte, selle asemel et kõike oma sisemises Dockeris uuesti alla laadida?"

Mõned ettevõtlikud inimesed on proovinud /var/lib/docker'i hostist Docker-in-Docker konteineris siduda. Mõnikord jagavad nad /var/lib/dockerit mitme konteineriga.

Kas soovite andmeid rikkuda? Sest see on just see, mis rikub teie andmed!

Dockeri demon on selgelt loodud sellele, et tagada ainulaadne juurdepääs /var/lib/docker. Mitte miski muu ei tohiks "puutuda, suruda või katsuda" mis tahes Dockeri faile, mis asuvad selles kaustas.

Miks see nii on? Kuna see on tulemus ühest kõige raskematest õppetundidest, mis saadi dotCloudi arendamisel. DotCloudi konteinerimootor töötas, lubades mitmel protsessil samal ajal juurdepääsu /var/lib/dotcloudile. Ohtlikud nipid, nagu failide aatomiline asendamine (kui mitte redigeerida kohapeal), koodi "pipardamine" soovituslike ja kohustuslike lukustustega ning muud katsed ohutute süsteemidega, nagu SQLite ja BDB, ei töötanud alati. Kui me ümber kujundasime meie konteinerimootori, mis lõpuks muutus Dockeriks, oli üheks peamiseks kavandamisotsuseks kõik konteineritega seotud toimingud koondada ühe demonini, et lõpetada kogu see segadus samaaegsest juurdepääsust.

Ärge saage valesti aru: on täiesti võimalik teha midagi head, usaldusväärset ja kiiret, mis hõlmab mitmeid protsesse ja kaasaegset paralleelset haldust. Kuid me arvame, et on lihtsam ja kergem kirjutada ja hallata koodi, kasutades Dockerit ainukese mängijana.

See tähendab, et kui jagate katalooge /var/lib/docker mitme Docker-i eksemplari vahel, siis tekivad teil probleemid. Muidugi võib see toimida, eriti testimise varases etapis. "Kuule, ema, ma saan "dockeriga" ubuntu käivitada!" Kuid proovige teha midagi keerulisemat, näiteks tõmmata sama pilti kahest erinevast eksemplarist, ja näete, kuidas maailm põleb.

See tähendab, et kui teie CI-süsteem sooritab ehitusi ja uuesti ehitusi, siis iga kord Docker-in-Docker konteineri taaskäivitamisel riskite oma vahemälu sees tuumabombaga. See ei ole sugugi lahe!

Probleemi lahendamine

Teeme sammu tagasi. Kas teil on tõesti vaja Docker-in-Dockerit või soovite lihtsalt võimalust käivitada Dockerit, nimelt koguda ja käivitada konteinerid ja pildid oma CI-süsteemist, samal ajal kui see CI-süsteem ise on konteineris?

Ma arvan, et enamik inimesi vajab viimast varianti, s.t. nad soovivad, et CI-süsteem nagu Jenkins saaks konteinerit käivitada. Ja lihtsaim viis selleks on lihtsalt Docker-soketi sisestamine oma CI-konteinerisse, seostades selle -v lipuga.

Lihtsalt öeldes, kui käitate oma CI-konteinerit (Jenkins või muu), alustage seda järgmistel ridadel, selle asemel et midagi Docker-in-Dockeriga kokku panna:

docker run -v /var/run/docker.sock:/var/run/docker.sock ...

Nüüd on sellel konteineril juurdepääs Docker-soketile ja seega saab see konteinerit käivitada. Erinevalt sellest, et see ei käivita “alam” konteinerit, vaid “sugulasi” konteinerit.

Proovige seda, kasutades ametlikku Docker'i pilti (mis sisaldab Docker'i binaarfaili):

docker run -v /var/run/docker.sock:/var/run/docker.sock 
           -ti docker

See näeb välja ja töötab nagu Docker-in-Docker, kuid see ei ole Docker-in-Docker: kui see konteiner loob täiendavaid konteine, luuakse need ülemise Docker'i alla. Te ei koge pesakonna kõrvaltoimeid ja ehitusvahemälu kasutatakse mitme kutsumise jaoks.

Märkus: Artikli varasemates versioonides soovitati siduda hosti binaarfail Docker konteineriga. Nüüd on see ebausaldusväärne, kuna Docker mehhanism ei kehti enam staatilistele või peaaegu staatilistele raamatukogudele.

Seega, kui soovite Jenkins CI-st Dockerit kasutada, on teil 2 võimalust:
installige Docker CLI, kasutades pildipakendi aluseks olevat süsteemi (nt. kui teie pilt põhineb Debianil, kasutage .deb pakette), kasutage Docker API-d.

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com