Hvor er Docker -bildene og beholderne lagret på verten? - CloudSavvy IT
Webbyrå » Digitale nyheter » Hvordan (og hvorfor) kjøre Docker Inside Docker - CloudSavvy IT

Hvordan (og hvorfor) kjøre Docker Inside Docker - CloudSavvy IT

Å kjøre Docker i Docker lar deg lage bilder og starte containere i et allerede containerisert miljø. Det er to mulige tilnærminger for å oppnå dette avhengig av om du ønsker å starte barne- eller søskencontainere.

Å få tilgang til Docker fra innsiden av en Docker-beholder er oftest ønskelig i sammenheng med CI- og CD-systemer. Det er vanlig å være vert for agentene som driver rørledningen din i en Docker-beholder. Du vil ende opp med å bruke en Docker-in-Docker-strategi hvis noen av pipeline-stadiene dine deretter avbilder eller samhandler med containere.

Docker-in-Docker-bildet

Docker leveres som et frittstående bilde gjennom docker:dind tag på Docker Hub. Oppstart av dette bildet vil gi deg en fungerende installasjon av Docker-demonen i den nye beholderen. Den vil kjøre uavhengig av vertens demon som kjører dind container, derfor docker ps inne i beholderen vil gi forskjellige resultater til docker ps på verten din.

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

Det er en stor ulempe ved å bruke Docker-in-Docker på denne måten - du må bruke privilegert modus. Denne begrensningen gjelder selv om du bruker beholdere uten rot. Den privilegerte modusen aktiveres av --privileged flagg i kommandoen ovenfor.

Bruk av privilegert modus gir beholderen full tilgang til vertssystemet. Dette er nødvendig i et Docker-in-Docker-scenario slik at din interne Docker kan opprette nye containere. Dette kan imidlertid representere en uakseptabel sikkerhetsrisiko i enkelte miljøer.

Det er andre problemer med dind for mye. Noen systemer kan oppleve konflikter med Linux Security Modules (LSM) som AppArmor og SELinux. Dette skjer når den interne Docker bruker LSM-policyer som den eksterne demonen ikke kan forutse.

En annen utfordring er med containerfilsystemer. Den eksterne daemonen vil kjøre på vertens normale filsystem, som f.eks ext4. Imidlertid vil alle beholderne, inkludert den interne Docker-demonen, stole på et kopi-på-skriv (CoW) filsystem. Dette kan skape inkompatibilitet hvis den interne daemonen er konfigurert til å bruke en pilolagringen som ikke kan brukes på et eksisterende CoW-filsystem.

Monter vertens Docker-kontakt i stedet

Utfordringene knyttet til dind behandles best ved helt å unngå bruk. I mange scenarier kan du oppnå ønsket effekt ved å montere vertens Docker-kontakt i en docker container:

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

Docker CLI inne i docker bildet samhandler med Docker daemon-kontakten som det finner på /var/run/docker.sock. Montering av vertens stikkontakt på denne banen betyr docker kommandoer som kjøres inne i beholderen vil kjøre på din eksisterende Docker-demon.

Dette betyr at beholderne som er opprettet av den interne Docker vil ligge på vertssystemet ditt, ved siden av selve Docker-beholderen. Alle beholdere vil eksistere som søsken, selv om det ser ut som den nestede Docker er et barn av forelderen. Fungerer docker ps vil gi de samme resultatene enten den kjøres på verten eller inne i beholderen.

Denne teknikken lindrer vanskelighetene med å implementere dind. Det fjerner også behovet for å bruke privilegert modus, selv om montering av Docker-kontakten i seg selv er et potensielt sikkerhetsproblem. Alle som har tilgang til sokkelen kan sende instruksjoner til Docker-demonen, noe som gir muligheten til å starte containere på verten din, trekke ut bilder eller slette data.

Når du skal bruke hver tilnærming

Docker-in-Docker via dind har alltid vært mye brukt i CI-miljøer. Dette betyr at de "indre" beholderne har et lag med isolasjon fra verten. En enkelt CI-runtime-beholder støtter hver rørledningsbeholder uten å forurense vertens Docker-demon.

Selv om dette ofte fungerer, er det fylt med bivirkninger og er ikke den tiltenkte brukssaken for dind. Den ble lagt til for å lette utviklingen av selve Docker, ikke for å gi sluttbrukerstøtte for nestede Docker-installasjoner.

I følge Jérôme Petazzoni, skaperen av dind implementering, bør bruk av den socket-baserte tilnærmingen være din foretrukne løsning. Å binde vertens socket-demon er tryggere, mer fleksibelt og like komplett som å starte en dind mottaker.

Hvis brukssaken din betyr at du absolutt trenger dind, er det en sikrere måte å distribuere den på. Det moderne Sysbox-prosjektet er en dedikert containerkjøretid som kan bygge andre kjøretider uten å bruke privilegert modus. Sysbox-beholdere blir lik virtuelle maskiner, slik at de kan støtte programvare som vanligvis kjører uten et operativsystem på en fysisk eller virtuell maskin. Dette inkluderer Docker og Kubernetes uten noen spesiell konfigurasjon.

konklusjonen

Å kjøre Docker i Docker er et relativt vanlig krav. Du vil sannsynligvis se dette når du konfigurerer CI-servere som skal støtte oppbygging av containerbilde fra brukeropprettede pipelines.

Ved hjelp av docker:dind gir deg en uavhengig Docker-demon som kjører i sin egen beholder. Den oppretter effektivt barnebeholdere som ikke er direkte synlige fra verten. Selv om det ser ut til å tilby sterk isolasjon, dind er faktisk hjemsted for mange perifere saksproblemer og sikkerhetsproblemer. Disse skyldes interaksjoner med Docker-operativsystemet.

Monter vertens Docker-kontakt i en beholder som inkluderer docker binær er et enklere og mer forutsigbart alternativ. Dette lar den nestede Docker-prosessen starte containere som blir sine egne søsken. Ingen andre parametere er nødvendige når du bruker den stikkontaktbaserte tilnærmingen.

★ ★ ★ ★ ★