Hi almal! In sy , Ek het belowe om te praat oor die bestuur van Docker in Docker en die praktiese aspekte van die gebruik van hierdie les. Dit is tyd om jou belofte na te kom. 'n Ervare devopser sal waarskynlik beswaar maak dat diegene wat Docker binne Docker benodig, eenvoudig die Docker-demonsok van die gasheer na die houer aanstuur en dit sal genoeg wees in 99% van die gevalle. Maar moenie haastig wees om koekies na my te gooi nie, want ons sal praat oor die feit dat Docker binne Docker bestuur word. Hierdie oplossing het baie moontlike toepassings en hierdie artikel handel oor een van hulle, so sit terug en maak jou arms reguit voor jou.
Begin
Dit het alles begin op 'n reΓ«nerige September-aand toe ek besig was om die masjien wat ek vir $5 gehuur het op Digital Ocean skoon te maak, wat gevries was as gevolg van die feit dat Docker al 24 gigagrepe beskikbare skyfspasie met sy beelde en houers gevul het. Die ironie was dat al hierdie beelde en houers van verbygaande aard was en slegs nodig was om die werkverrigting van my toepassing te toets elke keer as 'n nuwe weergawe van 'n biblioteek of raamwerk vrygestel is. Ek het probeer om dopskrifte te skryf en 'n cron-skedule op te stel om vullis op te ruim, maar dit het nie gehelp nie: elke keer het dit onvermydelik geΓ«indig met my bediener se skyfspasie wat opgevreet is en die bediener hang (op sy beste). Op 'n stadium het ek op 'n artikel afgekom oor hoe om Jenkins in 'n houer te laat loop en hoe dit boupyplyne kan skep en uitvee deur 'n docker daemon-sok wat daarin aangestuur word. Ek het van die idee gehou, maar ek het besluit om verder te gaan en te probeer eksperimenteer om Docker direk binne Docker te laat loop. Op daardie tydstip het dit vir my 'n heeltemal logiese oplossing gelyk om Docker-beelde af te laai en houers te skep vir al die toepassings wat ek nodig gehad het om binne 'n ander houer te toets (kom ons noem dit 'n opstelhouer). Die idee was om 'n opstelhouer met die -rm-vlag te begin, wat die hele houer en al sy inhoud outomaties uitvee wanneer dit gestop word. Ek het gepeuter met die Docker-beeld van Docker self (), maar dit blyk te omslagtig te wees en ek het dit nooit reggekry om te werk soos ek dit nodig gehad het nie en ek wou self die hele pad gaan.
Oefen. Kegels
Ek het besluit om die houer te laat werk soos ek nodig het en het my eksperimente voortgesit, wat 'n magdom knoppe tot gevolg gehad het. Die resultaat van my selfmarteling was die volgende algoritme:
-
Ons begin die Docker-houer in interaktiewe modus.
docker run --privileged -it docker:18.09.6Gee aandag aan die weergawe van die houer, stap regs of links en jou DinD verander in 'n pampoen. Trouens, dinge breek redelik dikwels wanneer 'n nuwe weergawe vrygestel word.
Ons moet dadelik in die dop kom. -
Ons probeer uitvind watter houers loop (Antwoord: geen), maar kom ons voer in elk geval die opdrag uit:
docker psJy sal 'n bietjie verbaas wees, maar dit blyk dat die Docker-demoon nie eens loop nie:
error during connect: Get http://docker:2375/v1.40/containers/json: dial tcp: lookup docker on 192.168.65.1:53: no such host -
Kom ons bestuur dit self:
dockerd &Nog 'n onaangename verrassing:
failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: Iptables not found -
Installeer die iptables en bash-pakkette (alles is lekkerder om in bash te werk as in sh):
apk add --no-cache iptables bash -
Kom ons begin bash. Uiteindelik is ons terug in die gewone dop
-
Kom ons probeer om Docker weer te begin:
dockerd &Ons behoort 'n lang vel logs te sien wat eindig met:
INFO[2019-11-25T19:51:19.448080400Z] Daemon has completed initialization INFO[2019-11-25T19:51:19.474439300Z] API listen on /var/run/docker.sock -
Druk Enter. Ons is terug in die bash.
Van nou af kan ons probeer om ander houers binne ons Docker-houer te lanseer, maar wat as ons nog 'n Docker-houer binne-in ons Docker-houer wil lanseer of iets loop verkeerd en die houer crash? Begin weer van voor af.
Eie DinD-houer en nuwe eksperimente
Om te verhoed dat die bogenoemde stappe oor en oor herhaal word, het ek my eie DinD-houer geskep:
Die werkende DinD-oplossing het my die vermoΓ« gegee om Docker rekursief binne Docker te laat loop en meer avontuurlike eksperimente te doen.
Ek gaan nou een so 'n (suksesvolle) eksperiment met die bestuur van MySQL en Nodejs beskryf.
Die mees ongeduldige kan sien hoe dit hier was
Laat ons dus begin:
-
Ons begin DinD in interaktiewe modus. In hierdie weergawe van DinD moet ons al die poorte wat ons kinderhouers kan gebruik, handmatig karteer (ek werk reeds hieraan)
docker run --privileged -it -p 80:8080 -p 3306:3306 alekslitvinenk/dindOns klim in die bash, vanwaar ons dadelik kinderhouers kan begin lanseer.
-
Begin MySQL:
docker run --name mysql -e MYSQL_ROOT_PASSWORD=strongpassword -d -p 3306:3306 mysql -
Ons koppel aan die databasis op dieselfde manier as wat ons plaaslik daaraan sou koppel. Kom ons maak seker alles werk.
-
Begin die tweede houer:
docker run -d --rm -p 8080:8080 alekslitvinenk/hello-world-nodejs-serverNeem asseblief kennis dat die poortkartering presies sal wees 8080:8080, aangesien ons reeds poort 80 van die gasheer na die ouerhouer na poort 8080 gekarteer het.
-
Ons gaan na localhost in die blaaier, maak seker dat die bediener reageer "Hallo WΓͺreld!"
In my geval het die eksperiment met geneste Docker-houers redelik positief geblyk te wees en ek sal voortgaan om die projek te ontwikkel en vir opstelling te gebruik. Dit lyk vir my of dit 'n baie meer liggewig oplossing is as Kubernetes en Jenkins X. Maar dit is my subjektiewe mening.
Ek dink dit is al vir vandag se artikel. In die volgende artikel sal ek in meer besonderhede eksperimente beskryf om Docker rekursief in Docker te laat loop en dopgehou diep in geneste houers te monteer.
PS As jy hierdie projek nuttig vind, gee dit asseblief 'n ster op GitHub, vurk dit en vertel jou vriende.
Wysig1 Foute reggestel, gefokus op 2 video's
Bron: will.com