Kuinka (ja miksi) Docker Inside Dockerin käyttäminen - CloudSavvy IT

Dockerin suorittaminen Dockerissa antaa sinun luoda kuvia ja käynnistää säilöjä jo säilötyssä ympäristössä. Tämän saavuttamiseksi on kaksi mahdollista lähestymistapaa riippuen siitä, haluatko aloittaa lapsi- vai sisarussäiliöt.

Dockeriin pääsy Docker-säiliön sisältä on useimmiten toivottavaa CI- ja CD-järjestelmien yhteydessä. On tavallista isännöidä putkilinjaasi ajavat agentit Docker-säiliössä. Päätät käyttämään Docker-in-Docker-strategiaa, jos jokin putkilinjasi vaiheista sitten kuvaa tai on vuorovaikutuksessa säiliöiden kanssa.

Docker-in-Docker-kuva

Docker toimitetaan erillisenä kuvana docker:dind tunniste Docker Hubissa. Tämän kuvan käynnistäminen antaa sinulle toimivan Docker-daemonin asennuksen uuteen säilöön. Se toimii riippumatta isäntäsi demonista, joka käyttää dind kontti siis docker ps säiliön sisällä antaa erilaisia ​​tuloksia docker ps isäntäsi päällä.

docker run -d --etuoikeutettu --name docker -e DOCKER_TLS_CERTDIR=/certs -v docker-certs-ca:/certs/ca -v docker-certs-client:/certs/client docker:dind

Docker-in-Dockerin käyttämisessä tällä tavalla on yksi suuri haittapuoli - sinun on käytettävä etuoikeutettua tilaa. Tämä rajoitus pätee, vaikka käytät säilöjä ilman juurta. Etuoikeutettu tila aktivoituu --privileged lippu yllä olevassa komennossa.

Etuoikeutetun tilan käyttö antaa säilölle täyden pääsyn isäntäjärjestelmääsi. Tämä on välttämätöntä Docker-in-Docker-skenaariossa, jotta sisäinen Dockerisi voi luoda uusia säilöjä. Tämä voi kuitenkin olla kohtuuton turvallisuusriski joissakin ympäristöissä.

On muitakin ongelmia dind liian paljon. Joissakin järjestelmissä voi olla ristiriitoja Linux Security Module (LSM) -moduulien, kuten AppArmor ja SELinux, kanssa. Tämä tapahtuu, kun sisäinen Docker käyttää LSM-käytäntöjä, joita ulkoinen demoni ei voi ennakoida.

Toinen haaste on säilötiedostojärjestelmät. Ulkoinen demoni toimii isäntäsi normaalissa tiedostojärjestelmässä, kuten ext4. Kuitenkin kaikki sen säilöt, mukaan lukien sisäinen Docker-daemon, perustuvat CoW-tiedostojärjestelmään (copy-on-write). Tämä voi aiheuttaa yhteensopimattomuutta, jos sisäinen demoni on määritetty käyttämään pilotallennustilaa, jota ei voi käyttää olemassa olevassa CoW-tiedostojärjestelmässä.

Kiinnitä sen sijaan isäntäsi Docker-pistoke

Haasteet liittyvät dind hoidetaan parhaiten välttämällä sen käyttöä kokonaan. Monissa tilanteissa voit saavuttaa halutun vaikutuksen asentamalla isäntäsi Docker-liittimen a docker kontti:

docker run -d --name docker -v /var/run/docker.sock:/var/run/docker.sock docker:latest

Dockerin CLI sisällä docker kuva on vuorovaikutuksessa Docker-daemon-socketin kanssa, jonka se löytää /var/run/docker.sock. Isännän pistorasian asentaminen tälle polulle tarkoittaa docker säilön sisällä suoritettavat komennot toimivat olemassa olevassa Docker-daemonissasi.

Tämä tarkoittaa, että sisäisen Dockerin luomat säilöt sijaitsevat isäntäjärjestelmässäsi itse Docker-säilön vieressä. Kaikki säilöt ovat olemassa sisaruksina, vaikka näyttää siltä, ​​että sisäkkäinen Docker on vanhemman lapsi. Toiminta docker ps tuottaa samat tulokset riippumatta siitä, suoritetaanko se isännässä tai säilössäsi.

Tämä tekniikka helpottaa täytäntöönpanon vaikeuksia dind. Se myös poistaa tarpeen käyttää etuoikeutettua tilaa, vaikka Docker-pistorasian asentaminen itsessään on mahdollinen tietoturvaongelma. Jokainen, jolla on pääsy pistorasiaan, voi lähettää Docker-demonille ohjeita, jotka tarjoavat mahdollisuuden käynnistää säilöjä isännässäsi, poimia kuvia tai poistaa tietoja.

Milloin kutakin lähestymistapaa käytetään

Docker-in-Docker kautta dind on aina ollut laajalti käytössä CI-ympäristöissä. Tämä tarkoittaa, että "sisäisillä" säiliöillä on eristyskerros isännästä. Yksi CI-ajonaikainen kontti tukee jokaista putkilinjakonttia saastuttamatta isäntäkoneen Docker-daemonia.

Vaikka tämä usein toimii, se on täynnä sivuvaikutuksia, eikä se ole tarkoitettu käyttötarkoitukseen dind. Se lisättiin helpottamaan itse Dockerin kehitystä, ei tarjoamaan loppukäyttäjätukea sisäkkäisille Docker-asennuksille.

Jérôme Petazzonin, luojan mukaan dind toteutuksessa socket-pohjaisen lähestymistavan tulisi olla ensisijainen ratkaisu. Isäntäsi socket-daemonin sitominen on turvallisempaa, joustavampaa ja yhtä täydellistä kuin käynnistäminen dind vastaanottaja.

Jos käyttötapasi tarkoittaa, että tarvitset ehdottomasti dind, on olemassa turvallisempi tapa ottaa se käyttöön. Nykyaikainen Sysbox-projekti on omistettu konttiajoaika, joka voi sisäistää muita ajonaikoja käyttämättä etuoikeutettua tilaa. Sysbox-säilöistä tulee virtuaalikoneiden kaltaisia, joten ne voivat tukea ohjelmistoja, jotka tyypillisesti toimivat ilman käyttöjärjestelmää fyysisessä tai virtuaalikoneessa. Tämä sisältää Dockerin ja Kubernetesin ilman erityisiä määrityksiä.

Yhteenveto

Dockerin käyttäminen Dockerissa on suhteellisen yleinen vaatimus. Näet tämän todennäköisesti, kun määrität CI-palvelimia, joiden pitäisi tukea konttikuvan koontiversioita käyttäjien luomista putkistoista.

Käyttämällä docker:dind antaa sinulle itsenäisen Docker-daemonin, joka toimii omassa konttissaan. Se luo tehokkaasti lapsisäiliöitä, jotka eivät näy suoraan isännältä. Vaikka se näyttää tarjoavan vahvaa eristystä, dind on itse asiassa koti monille oheiskoteloongelmille ja turvallisuuskysymyksille. Nämä johtuvat Docker-käyttöjärjestelmän vuorovaikutuksista.

Kiinnitä isäntäsi Docker-liitin säiliöön, joka sisältää docker binääri on yksinkertaisempi ja ennustettavampi vaihtoehto. Tämä sallii sisäkkäisen Docker-prosessin käynnistää säilöjä, joista tulee sen omat sisarukset. Muita parametreja ei tarvita socket-pohjaista lähestymistapaa käytettäessä.