Docker-in-Docker edukiontziaren barruan exekutatzen den Docker daemon ingurune birtualizatu bat da, edukiontzien irudiak eraikitzeko. Docker-in-Docker sortzearen helburu nagusia Docker bera garatzen laguntzea izan zen. Jenkins CI exekutatzeko erabiltzen du jende askok. Hasieran normala dirudi, baina gero Docker Jenkins CI edukiontzi batean instalatuz ekidin daitezkeen arazoak sortzen dira. Artikulu honek hau nola egin esaten dizu. Xehetasunik gabe azken irtenbidea interesatzen bazaizu, irakurri artikuluko azken atala, "Arazoa konpontzea".
Docker-in-Docker: "Ona"
Duela bi urte baino gehiago Docker-en sartu nuen βpribilegiatua eta idatzia . Helburua oinarrizko taldeari Docker azkarrago garatzen laguntzea zen. Docker-in-Docker baino lehen, garapen-ziklo tipikoa honelakoa zen:
- hackity hack;
- eraiki;
- martxan dagoen Docker daemon bat gelditzea;
- Docker daemon berri bat abian jartzea;
- probak;
- zikloa errepikatu.
Muntaketa eder eta erreproduzigarri bat egin nahi bazenu (hau da, edukiontzi batean), orduan korapilatsuagoa bihurtu zen:
- hackity hack;
- ziurtatu Docker-en funtzionatzen duen bertsio bat exekutatzen ari dela;
- Docker berria eraiki Docker zaharrarekin;
- gelditu Docker daemon;
- hasi Docker daemon berri bat;
- proba;
- gelditu Docker daemon berria;
- errepikatu.
Docker-in-Docker-en etorrerarekin, prozesua errazagoa bihurtu da:
- hackity hack;
- muntaia + abiarazte etapa batean;
- zikloa errepikatu.
Ez al da askoz hobea horrela?
Docker-in-Docker: "Gaizki"
Hala ere, uste denaren aurka, Docker-in-Docker ez da %100 izarrak, pottokak eta unikornioak. Esan nahi dudana da garatzaile batek jakin behar dituen hainbat arazo daudela.
Horietako bat AppArmor eta SELinux bezalako LSMei (Linux segurtasun moduluak) dagokie: edukiontzi bat exekutatzen denean, "barneko Docker"-a "kanpoko Docker"-a gatazkan edo nahastuko duten segurtasun-profilak aplikatzen saia daiteke. Hau da βprivileged banderaren jatorrizko ezarpena batzen saiatzean konpontzen den arazorik zailena. Nire aldaketek funtzionatu zuten eta proba guztiak nire Debian makinan eta Ubuntu probako VMetan pasatuko ziren, baina Michael Crosbyren makinan huts egin eta erre egingo ziren (Fedora zuen gogoratzen dudanez). Ezin dut gogoratzen arazoaren kausa zehatza, baina baliteke Mike SELINUX=enforce-rekin lan egiten duen tipo jakintsua delako (AppArmor erabili dut) eta nire aldaketek SELinux profilak ez dituztelako kontuan hartu.
Docker-in-Docker: "Gaiztoa"
Bigarren arazoa Docker biltegiratze-gidariekin dago. Docker-in-Docker exekutatzen duzunean, kanpoko Docker fitxategi-sistema arrunt baten gainean exekutatzen da (EXT4, BTRFS edo duzuna) eta barneko Docker kopia-idazketa-sistema baten gainean (AUFS, BTRFS, Device Mapper) , etab.). , kanpoko Docker erabiltzeko konfiguratuta dagoenaren arabera). Horrek funtzionatuko ez duten konbinazio asko sortzen ditu. Adibidez, ezin izango duzu AUFS AUFSen gainean exekutatu.
BTRFS BTRFSen gainean exekutatzen baduzu, hasieran funtzionatu beharko luke, baina habiaratutako azpibolumenak daudenean, azpibolumen nagusia ezabatzeak huts egingo du. Device Mapper moduluak ez du izen-espaziorik, beraz, Docker-en hainbat instantzia makina berean exekutatzen ari badira, guztiek ikusi ahal izango dituzte irudiak elkarrengan eta edukiontzien babeskopia-gailuetan. Hau txarra da.
Arazo horietako asko konpontzeko irtenbideak daude. Adibidez, AUFS barne Docker-en erabili nahi baduzu, /var/lib/docker karpeta bolumen bihurtu besterik ez duzu eta ondo egongo zara. Docker-ek oinarrizko izen-espazio batzuk gehitu ditu Device Mapper helburu-izenetara, beraz, Docker dei anitz makina berean exekutatzen ari badira, ez dute elkar zapalduko.
Hala ere, konfigurazio hori ez da batere erraza, hauetatik ikus daitekeenez GitHub-eko dind biltegian.
Docker-in-Docker: okerrera egiten du
Zer gertatzen da eraikitzeko cachearekin? Hau ere nahiko zaila izan daiteke. Jendeak askotan galdetzen dit: "Docker-in-Docker exekutatzen ari banaiz, nola erabil ditzaket nire ostalari ostatatutako irudiak dena nire barneko Docker-era eraman beharrean"?
Pertsona ekintzaileak /var/lib/docker ostalaritik Docker-in-Docker edukiontzi batera lotzen saiatu dira. Batzuetan, /var/lib/docker hainbat edukiontzirekin partekatzen dute.
Zure datuak hondatu nahi dituzu? Hau baita zure datuak kaltetuko dituena!
Docker daemon argi eta garbi diseinatu zen /var/lib/docker-erako sarbide esklusiboa izateko. Beste ezerk ez luke karpeta honetan dauden Docker fitxategiak "ukitu, zulatu edo zartatu".
Zergatik da hori horrela? Hau dotCloud garatzean ikasitako ikasgai gogorrenetako baten emaitza delako. DotCloud edukiontzi-motorra aldi berean /var/lib/dotcloud atzitzeko hainbat prozesu izan zituen. Trikimailu maltzurrak, hala nola, fitxategi atomikoak ordezkatzea (bertan editatu beharrean), aholku eta derrigorrezko blokeoekin kodea pipertzea eta SQLite eta BDB bezalako sistema seguruekin beste esperimentu batzuek ez zuten beti funtzionatu. Gure edukiontzien motorra birdiseinatzen ari ginenean, azkenean Docker bihurtu zena, diseinuaren erabaki handietako bat edukiontzien eragiketa guztiak deabru bakar baten pean finkatzea izan zen, aldibereko zentzugabekeria guztiak kentzeko.
Ez nazazu gaizki ulertu: guztiz posible da prozesu anitz eta kontrol paralelo modernoa dakartzan zerbait ona, fidagarria eta azkarra egitea. Baina uste dugu errazagoa eta errazagoa dela kodea idaztea eta mantentzea Docker erreproduzitzaile bakar gisa erabiliz.
Horrek esan nahi du /var/lib/docker direktorioa Docker instantzia anitzen artean partekatzen baduzu, arazoak izango dituzula. Noski, honek funtzionatu dezake, batez ere proben hasierako faseetan. "Entzun, ama, ubuntu docker gisa exekutatu dezaket!" Baina saiatu zerbait konplexuagoa, adibidez, irudi bera bi instantzia ezberdinetatik ateratzen, eta mundua erretzen ikusiko duzu.
Horrek esan nahi du zure CI sistemak eraikitzen eta berreraikitzen baditu, Docker-in-Docker edukiontzia berrabiarazten duzun bakoitzean, nuklear bat bere cachean erortzeko arriskua duzula. Hau ez da batere polita!
Irtenbidea
Eman dezagun pauso bat atzera. Benetan behar al duzu Docker-in-Docker edo, besterik gabe, Docker exekutatu eta zure CI sistematik edukiontziak eta irudiak eraiki eta exekutatu ahal izatea nahi duzu CI sistema bera edukiontzi batean dagoen bitartean?
Jende gehienek azken aukera hau nahi dutela uste dut, hots, Jenkins bezalako CI sistema bat edukiontziak exekutatu ahal izateko nahi dutela. Eta hori egiteko modurik errazena Docker socket bat zure CI edukiontzian sartzea eta -v banderarekin lotzea besterik ez da.
Besterik gabe, zure CI edukiontzia (Jenkins edo beste) exekutatzen duzunean, Docker-in-Docker-ekin batera zerbait hackeatu beharrean, hasi lerroarekin:
docker run -v /var/run/docker.sock:/var/run/docker.sock ...Edukiontzi honek orain Docker socketerako sarbidea izango du eta, beraz, edukiontziak exekutatu ahal izango ditu. "Haur" edukiontziak exekutatu beharrean, "anai-arreba" edukiontziak martxan jarriko dituela izan ezik.
Saiatu hau Dockerren irudi ofiziala erabiliz (Docker bitarra duena):
docker run -v /var/run/docker.sock:/var/run/docker.sock
-ti dockerDocker-in-Docker-en itxura eta funtzionatzen du, baina ez da Docker-in-Docker: edukiontzi honek edukiontzi gehigarriak sortzen dituenean, goi-mailako Docker-en sortuko dira. Ez duzu habiatzearen albo-ondoriorik izango eta muntaia-cachea dei askotan partekatuko da.
Oharra: Artikulu honen aurreko bertsioek Docker bitarra ostalaritik edukiontzira lotzea gomendatzen zuten. Hau orain fidagarria bihurtu da Docker motorrak jada liburutegi estatikoak edo ia estatikoak ez dituelako estaltzen.
Beraz, Jenkins CI-ko Docker erabili nahi baduzu, 2 aukera dituzu:
Docker CLI oinarrizko irudiak biltzeko sistema erabiliz instalatzea (hau da, zure irudia Debian oinarritzen bada, erabili .deb paketeak), Docker APIa erabiliz.
Iragarki batzuk π
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com