Docker-in-Docker hawîrdorek daemon a Docker-a virtual ye ku di hundurê konteynerê de bixwe tê xebitandin da ku wêneyên konteynerê ava bike. Armanca sereke ya afirandina Docker-in-Docker ev bû ku bibe alîkar ku Docker bixwe pêşve bibe. Gelek kes wê bikar tînin ku Jenkins CI-ê bimeşînin. Ev di destpêkê de normal xuya dike, lê dûv re pirsgirêkên ku dikarin bi sazkirina Docker-ê di konteynirek Jenkins CI-ê de ji holê rabin derdikevin holê. Ev gotar ji we re vedibêje ka meriv çawa vê yekê dike. Heke hûn bi çareseriya paşîn a bê hûrgulî re eleqedar in, tenê beşa paşîn a gotarê, "Çareserkirina pirsgirêkê" bixwînin.
Docker-in-Docker: "Baş"
Zêdetirî du sal berê min xist Docker – îmtiyaz û nivîsand . Armanc ev bû ku alîkariya tîmê bingehîn bike ku Docker zûtir pêşve bibe. Berî Docker-in-Docker, çerxa pêşkeftina tîpîk bi vî rengî xuya bû:
- hackity hack;
- avakirin;
- rawestandina daemonek Docker a ku diherike;
- destpêkirina daemonek nû ya Docker;
- testing;
- çerxa dubare bike.
Ger we dixwest ku meclîsek xweşik, ji nû ve çêbibe (ango di konteynerek de), wê hingê ew tevlihevtir bû:
- hackity hack;
- Piştrast bike ku guhertoyek xebitandinê ya Docker dimeşe;
- Docker-a nû bi Docker-a kevn re ava bikin;
- rawestin Docker daemon;
- dest bi daemonek nû ya Docker bikin;
- îmtîhan;
- Daemonê nû yê Docker rawestîne;
- dûbare.
Bi hatina Docker-in-Docker re, pêvajo hêsantir bûye:
- hackity hack;
- civîn + destpêkirin di yek qonaxê de;
- çerxa dubare bike.
Ma bi vî awayî ne çêtir e?
Docker-in-Docker: "Bad"
Lêbelê, berevajî baweriya populer, Docker-in-Docker ne 100% stêrk, ponijî û yekkorn e. Mebesta min ev e ku gelek pirsgirêk hene ku pêdivî ye ku pêşdebirek jê haydar be.
Yek ji wan LSM (modulên ewlehiyê yên Linux) yên wekî AppArmor û SELinux eleqedar dike: dema ku konteynerek dimeşîne, dibe ku "Dockera hundurîn" hewl bide ku profîlên ewlehiyê yên ku dê "Dockera derveyî" nakok an tevlihev bikin, bicîh bîne. Ev pirsgirêka herî dijwar e ku meriv dema ku hewl dide ku pêkanîna orîjînal a -ala îmtiyazê li hev bike. Guhertinên min xebitîn û hemî ceribandin dê li ser makîneya min a Debian û VM-yên ceribandina Ubuntu derbas bibin, lê ew ê li ser makîneya Michael Crosby biqelişin û bişewitînin (wekî ku tê bîra min Fedora wî hebû). Ez nikarim sedema tam a pirsgirêkê bi bîr bînim, lê dibe ku ji ber ku Mike zilamek biaqil e ku bi SELINUX=nforce re dixebite (min AppArmor bikar anî) û guheztinên min profîlên SELinux li ber çavan negirtin.
Docker-in-Docker: "Xerab"
Pirsgirêka duyemîn bi ajokarên hilanîna Docker re ye. Dema ku hûn Docker-in-Docker-ê dimeşînin, Docker-ya derveyî li ser pergalek pelê ya birêkûpêk (EXT4, BTRFS, an her tiştê ku we heye) dimeşîne û Docker-ya hundurîn li ser pergala kopî-li-nivîsandinê (AUFS, BTRFS, Nexşeya cîhazê) dimeşîne. , û hwd.), li gorî tiştê ku ji bo karanîna Docker-a derveyî hatî mîheng kirin). Ev gelek kombînasyonan diafirîne ku dê nexebitin. Mînakî, hûn ê nikaribin AUFS-ê li ser AUFS-ê bimeşînin.
Ger hûn BTRFS-ê li ser BTRFS-ê bimeşînin, divê ew di destpêkê de bixebite, lê gava ku jêr-cildên hêlîn hebin, jêbirina jêrvoluma dêûbav dê têk nebe. Modula Device Mapper cîhê navî tune, ji ber vê yekê heke gelek mînakên Docker wê li ser heman makîneyê dimeşînin, ew ê hemî karibin wêneyên li ser hev û li ser cîhazên paşvekêşana konteynerê bibînin (û bandor bikin). Ev xirab e.
Ji bo çareserkirina gelek ji van pirsgirêkan rêyên kar hene. Mînakî, heke hûn dixwazin AUFS-ê di Docker-a hundurîn de bikar bînin, tenê peldanka /var/lib/docker-ê veguherînin cildê û hûn ê baş bibin. Docker hin navên bingehîn li navên armancê Device Mapper zêde kiriye da ku heke gelek bangên Docker li ser heman makîneyê têne xebitandin, ew ê gav neavêjin hev.
Lêbelê, sazkirina wusa ne hêsan e, wekî ku ji van tê dîtin di depoya din de li ser GitHub.
Docker-in-Docker: Ew xirabtir dibe
Çi li ser cache build? Ev jî dikare pir dijwar be. Mirov bi gelemperî ji min dipirsin "ger ez Docker-in-Docker-ê dixebitim, ez çawa dikarim wêneyên ku li ser mêvandarê xwe têne mêvandar kirin bikar bînim li şûna ku her tiştî vegerînim nav Docker-a xweya hundurîn"?
Hin mirovên karsaz hewl dane ku /var/lib/docker ji mêvandar bi konteynirek Docker-in-Docker ve girêdin. Carinan ew /var/lib/docker bi gelek konteyneran re parve dikin.
Ma hûn dixwazin daneyên xwe xera bikin? Ji ber ku ev tam ya ku dê zirarê bide daneyên we ye!
Daemonê Docker eşkere hate sêwirandin ku xwedan gihîştina taybetî ya /var/lib/docker-ê ye. Tiştek din pêdivî ye ku pelên Docker-ê yên ku di vê peldankê de ne "dest bixin, bişkînin, an jî hilînin".
Çima wisa ye? Ji ber ku ev encama yek ji wan dersên herî dijwar e ku dema pêşkeftina dotCloud-ê hatî fêr kirin. Motora konteynerê dotCloud bi xwedîkirina gelek pêvajoyên ku bi hevdemî digihîjin /var/lib/dotcloud xebitî. Axafeyên fêlbaz ên wekî guheztina pelê atomê (li şûna guheztina di cîh de), guheztina koda bi qefleyên şêwirmendî û mecbûrî, û ceribandinên din ên bi pergalên ewledar ên wekî SQLite û BDB re her gav ne dixebitin. Dema ku me motora konteynera xwe ji nû ve dîzayn dikir, ku di dawiyê de bû Docker, yek ji biryarên sêwiranê yên mezin ev bû ku hemî karûbarên konteynerê di binê yek daemon de yek bikin da ku hemî bêaqiliyên hevdemî ji holê rakin.
Min şaş fam neke: bi tevahî gengaz e ku meriv tiştek baş, pêbawer û bilez çêbike ku pir pêvajoyên û kontrola paralel a nûjen vedihewîne. Lê em difikirin ku nivîsandin û domandina kodê bi karanîna Docker wekî lîstikvanê yekane hêsan û hêsantir e.
Ev tê vê wateyê ku heke hûn pelrêça /var/lib/docker di navbera gelek mînakên Docker de parve bikin, dê pirsgirêkên we hebin. Bê guman, ev dikare bixebite, nemaze di qonaxên destpêkê yên ceribandinê de. "Guhdarî bike, Ma, ez dikarim ubuntuyê wekî doker bimeşînim!" Lê tiştek tevlihevtir biceribînin, mîna kişandina heman wêneyê ji du bûyerên cûda, û hûn ê bibînin ku cîhan dişewite.
Ev tê vê wateyê ku ger pergala CI-ya we avahî û ji nû ve ava bike, her gava ku hûn konteynera xweya Docker-in-Docker ji nû ve bidin destpêkirin, hûn xeternak in ku nukleerek nav kaşê wê bavêjin. Ev qet ne xweş e!
Troubleshooting
Werin em gavekê paşde bavêjin. Ma hûn bi rastî hewceyê Docker-in-Docker-ê ne an hûn tenê dixwazin ku hûn bikaribin Docker-ê bimeşînin û ji pergala xweya CI konteynir û wêneyan ava bikin û bimeşînin dema ku ew pergala CI bixwe di konteynerek de ye?
Ez bet dikim ku pir kes vebijarka paşîn dixwazin, tê vê wateyê ku ew pergalek CI-ya mîna Jenkins dixwazin ku karibin konteyneran bimeşînin. Û awayê herî hêsan a kirina vê ev e ku meriv bi tenê soketek Docker têxe nav konteynera CI-ya xwe û wê bi ala -v re têkildar bike.
Bi hêsanî, gava ku hûn konteynera CI-ya xwe (Jenkins an din) dimeşînin, li şûna ku hûn bi Docker-in-Docker re tiştek hack bikin, wê bi rêzê dest pê bikin:
docker run -v /var/run/docker.sock:/var/run/docker.sock ...Vê konteynir dê naha bigihîje soketa Docker û ji ber vê yekê dikare konteyneran bimeşîne. Ji xeynî ku li şûna ku konteynerên "zarok" bixebite, dê konteynirên "bira-bira" bavêje.
Vê bi karanîna wêneya docker-a fermî (ya ku binarya Docker-ê vedihewîne) biceribînin:
docker run -v /var/run/docker.sock:/var/run/docker.sock
-ti dockerEw mîna Docker-in-Docker xuya dike û dixebite, lê ew ne Docker-in-Docker e: gava ku ev konteynir konteynerên zêde diafirîne, ew ê di asta jorîn Docker de werin afirandin. Hûn ê bandorên alîgirê hêlînê nebînin û cache civîn dê li ser gelek bangan were parve kirin.
Nîşe: Guhertoyên berê yên vê gotarê şîret kir ku Docker binary ji mêvandar bi konteynerê ve girêbide. Ev naha bêbawer bûye ji ber ku motora Docker êdî pirtûkxaneyên statîk an nêzîk-statîk vedigire.
Ji ber vê yekê, heke hûn dixwazin Docker ji Jenkins CI bikar bînin, 2 vebijarkên we hene:
sazkirina Docker CLI bi karanîna pergala pakkirina wêneya bingehîn (ango heke wêneya we li ser Debian-ê ye, pakêtên .deb bikar bînin), bi karanîna API-ya Docker bikar bînin.
Hin reklam 🙂
Spas ji bo ku hûn bi me re bimînin. Ma hûn ji gotarên me hez dikin? Ma hûn dixwazin naveroka balkêştir bibînin? Piştgiriya me bikin bi danîna fermanek an pêşniyarkirina hevalan, , analogek bêhempa ya pêşkêşkerên asta têketinê, ku ji hêla me ve ji bo we hatî vedîtin: (bi RAID1 û RAID10, heta 24 core û heya 40 GB DDR4 peyda dibe).
Dell R730xd 2x erzantir li navenda daneya Equinix Tier IV li Amsterdam? Tenê li vir li Hollanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ji $99! Li ser bixwînin
Source: www.habr.com