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

Docker-in-Docker on Dockeri virtuaalne keskkond, kus Dockeri deemon töötab konteineris, et ehitada konteinerite pilte. Docker-in-Dockeri loomise peamine eesmärk oli aidata Dockerit arendada. Paljud inimesed kasutavad seda Jenkins CI käivitamiseks. Alguses tundub see normaalne, kuid seejärel tekivad probleemid, mida oleks võimalik vältida, kui installida Docker Jenkins CI konteinerisse. Käesolevas artiklis räägitakse, kuidas seda teha. Kui teid huvitab lõpplahendus, ilma detailideta, lugege lihtsalt artikli viimatist osa „Probleemi lahendamine”.

Docker-in-Docker: "Hea"

Üle kahe aasta tagasi lisasin Dockerisse Teised --privileged ja kirjutasin esimese versiooni dind. Eesmärk oli aidata põhimeeskonda Dockerit kiiremini arendada. Enne Docker-in-Dockeri ilmumist oli tüüpiline arendus-tsükkel selline:

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

Kui aga soovisite teha ilusat, korduvat ehitust (st konteineris), siis muutus see keerulisemaks:

• hackity hack;
• veenduda, et töötav Docker on käivitunud;
• ehitada uus Docker vana Dockeriga;
• peatada Docker-deemon;
• käivitada uus Docker-deemon;
• testida;
• peatada uus Docker-deemon;
• korrata.

Docker-in-Dockeri tulekuga muutus protsess lihtsamaks:

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

Ei tundu, et see oleks palju parem?

Docker-in-Docker: "Halb"

Siiski, vastupidiselt levinud arvamusele, ei koosne Docker-in-Docker 100% tähtedest, poniidest ja ükssarvikutest. Ma pean silmas, et on mitmeid probleeme, millest arendajal on teadlik olla.

Üks neist puudutab LSM-i (Linuxi turvamoode), nagu AppArmor ja SELinux: konteinerit käivitades võib „sisemine Docker“ proovida rakendada turvaprofii, mis võib konfliktida või segi ajada „välist Dockerit“. See oli kõige keerulisem probleem, mida tuli lahendada, püüdes ühendada algse implementatsiooni -privileegide lippu. Minu muudatused töötasid ning kõik testid oleksid läbinud minu Debian masinas ja Ubuntus testmasinates, kuid nad oleksid kokku kukkunud ja põlenud Michael Crosby masinas (kui ma õigesti mäletan, oli tal Fedora). Ma ei mäleta probleemi täpset põhjust, kuid võib-olla tekkis see seetõttu, et Mike on nutikas inimene, kes töötab SELINUX=enforce (mina kasutasin AppArmor'i) ning minu muudatused ei arvestanud SELinuxi profiilidega.

Docker-in-Docker: „Kurjuse tütar“

Teine probleem on seotud Docker'i salvestusdraiveritega. Kui käivitate Docker-in-Docker'i, töötab väline Docker tavalisel failisüsteemil (EXT4, BTRFS või mis iganes teil on) ja sisemine Docker töötab kirjutamise kopeerimise süsteemi (AUFS, BTRFS, seadme kartoteek jne, sõltuvalt sellest, mis on välist Dockerit kasutama seadistatud). Sellega kaasnevad paljud kombinatsioonid, mis ei tööta. Näiteks ei saa te AUFS'i käivitada AUFS'i peal.

Kui käitate BTRFS'i BTRFS'i peal, peaks see esmalt töötama, kuid kui ilmuvad sisemised alamkogud, ei saa vanemat alamkogude parent subvolume-d kustutada. Seadmepõhine kartoteek ei oma nimesihte, seega kui mitu Docker'i instantsi kasutavad seda ühel masinal, saavad nad kõik üksteise pilte näha (ja mõjutada) ning konteinerite varukoopiaid. See on halb.

Paljude nende probleemide lahendamiseks on olemas ainult lahendused. Näiteks kui soovite kasutada AUFS'i sisemises Dockeris, muutke lihtsalt kaust /var/lib/docker mahuks ja kõik on korras. Docker on lisanud mõned põhikohtumised seadme kartoteekide sihtmärkidele, nii et kui mitu Docker'i kutsungit tehakse ühel masinal, siis nad ei „astuks“ üksteise varbale.

Kuid selline seadistus pole sugugi lihtne, nagu on näha neist. artikleid GitHubi dind'i allikast.

Docker-in-Docker: läheb aina hullemaks

Kuidas on lood ülesehitamise cache'iga? See võib olla üsna keeruline. Inimesed küsivad sageli: "kui ma kasutan Docker-in-Dockerit, kuidas ma saan kasutada minu hostis asuvaid pilte, selle asemel et kõik taas alla laadida minu sisemisse Dockerisse?"

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

Kas soovite andmeid kahjustada? Sest see on täpselt see, mis teie andmeid kahjustab!

Docker'i demon on selgelt loodud, et omada eksklusiivset juurdepääsu /var/lib/docker'ile. Mitte miski muu ei tohiks "puutuda, torkida või katsuda" ühtegi Docker'i faili, mis asub selles kaustas.

Miks see nii on? Sest see on tulemus ühest kõige keerulisemast õppetunnist, mis saadud dotCloud'i arendamisel. DotCloud'i konteineri mootor töötas, kui mitmed protsessid kasutasid samaaegselt /var/lib/dotcloud'i. Peened trikid, nagu atomaarne failide asendamine (kui mitte redigeerimine kohapeal), koodi „tõukamine” soovituslike ja kohustuslike lukudega ning muud eksperimendid turvaliste süsteemidega, nagu SQLite ja BDB, ei töötanud alati. Kui me ümber tegime meie konteineri mootori, mis lõpuks muutus Docker'iks, oli üks peamistest disainilahendustest koondada kõik konteinerite operatsioonid ühte daemonisse, et lõpetada kogu see jama samaaegsest juurdepääsust.

Ärge saage mind valesti aru: on täiesti võimalik teha midagi head, usaldusväärset ja kiiret, mis hõlmab mitmeid protsesse ja kaasaegset paralleelset haldust. Kuid meie arvates on lihtsam ja kergem kirjutada ja hallata koodi, kasutades Docker'it ainulaadse mängijana.

See tähendab, et kui jagate katalooge /var/lib/docker mitmete Docker'i eksemplaride vahel, siis teil on probleeme. Loomulikult võib see toimida, eriti varajaste testimise etappide jooksul. "Kuule, ma saan Ubuntu 'd dockeri' abil jooksutada!" Aga proovige teha midagi keerukamat, näiteks alla laadida sama pilti kahest erinevast eksemplarist, ja te näete, kuidas maailm põleb.

See tähendab, et kui teie CI-süsteem teostab ehitusi ja ümberehitusi, siis iga kord, kui käitate Docker-in-Docker konteinerit, riskite tuuma pommi oma puhverdatud mälus eemaldamisega. See pole sugugi äge!

Probleemi lahendus

Võtame ühe sammu tagasi. Kas teil on tõeliselt vaja Docker-in-Docker'i või soovite lihtsalt võimalust käivitada Dockerit, st ehitada ja käivitada konteinerite ja piltide teie CI-süsteemist, samas kui see CI-süsteem asub konteineris?

Olen kindel, et enamikule inimestele meeldib viimane variant, st nad soovivad, et CI-süsteem, nagu Jenkins, saaks konteinerite käivitamiseks. Ja kõige lihtsam viis seda teha on lihtsalt liituda Docker sokliga teie CI konteineris, seostades selle -v lipuga.

Lihtsalt öeldes, kui käitate oma CI konteinerit (Jenkins või muu), aluseta midagi Docker-in-Docker'iga, alustage seda järgmiselt:

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

Nüüd pääseb see konteiner Docker soklile ja seega suudab käivitada konteinerid. Erinevalt sellest, et „alamsõlmed” konteinerid saavad olema „sugulased“ konteinerid.

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 konteinerite, luuakse need kõrgema taseme Docker'is. Te ei koge sisemise taseme kõrvalmõjusid ja ehituse vahemälu jagatakse mitme kutsumise vahel.

Märkus: selle artikli varasemad versioonid soovitasid siduda Docker'i binaarfail hostist konteinerisse. Nüüd on see muutunud ebausaldusväärseks, kuna Docker'i mehhanism ei laiene enam staatilistele või peaaegu staatilistele raamatukogudele.

Seega, kui soovite kasutada Dockerit Jenkins CI-s, on teil 2 varianti:
installige Docker CLI, kasutades pakettide paigaldamise põhiosakonda (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 huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level 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 jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com