Hur jag körde Docker inuti Docker och vad som kom ut av det

Hej alla! I min den föregående artikeln, jag lovade att berätta om att köra Docker i Docker och de praktiska aspekterna av denna aktivitet. Det är dags att hålla mitt löfte. En erfaren DevOps kanske invänder att de som behöver Docker inuti Docker bara vidarebefordrar Docker daemon-socket från värden in i containern och att detta räcker i 99 % av fallen. Men skynda er inte att kasta kakor på mig, för det handlar om att faktiskt köra Docker inuti Docker. Denna lösning har många potentiella användningsområden, och denna artikel handlar om ett av dem, så sätt er bekvämt och sträck ut händerna framför er.

Början

Allt började en regnig söndagskväll när jag rensade en hyrbil för $5 på Digital Ocean, som helt hade hängt sig eftersom Docker hade fyllt ut alla 24 gigabyte tillgängligt diskutrymme med sina bilder och containrar. Irin var att alla dessa bilder och containrar var tillfälliga och behövdes bara för att testa min applikations funktionalitet varje gång en ny version av någon bibliotek eller ramverk släpptes. Jag försökte skriva shell-skript och schemalägga cron-jobb för att rensa skräpet, men det hjälpte inte: varje gång slutade det oundvikligen med att mitt servers diskutrymme var uppätet och servern hängde sig (i bästa fall). Vid ett tillfälle snubblade jag över en artikel om hur man kör Jenkins i en container och hur den kan skapa och ta bort byggkonvejer via den vidarebefordrade Docker daemon-socketen. Idén tilltalade mig, men jag beslutade att gå längre och experimentera med att köra Docker direkt inuti Docker. Det verkade logiskt att ladda ner Docker-bilder och skapa containrar för alla applikationer jag behövde för tester inuti en annan container (låt oss kalla det staging-container). Idén var att köra staging-containern med flaggan -rm, vilket automatiskt tar bort hela containern med allt dess innehåll när den stoppas. Jag grävde i Docker-bilden av själva Docker,https://hub.docker.com/_/docker, men den visade sig vara för otymplig och jag kunde inte få den att fungera som jag ville, och jag ville gå hela vägen själv.

Praktik. Knoppar

Jag hade som mål att få containern att fungera som jag ville och fortsatte mina experiment, vilket resulterade i ett otaliga misslyckanden. Resultatet av mina plågor blev följande algoritm:

1. Starta Docker-containern i interaktivt läge.

   docker run --privileged -it docker:18.09.6

   Observera versionen av containern, ett steg åt höger eller vänster och din DinD förvandlas till en pumpa. Faktum är att allt går sönder ganska ofta med nya versioner.
   Vi måste omedelbart komma in i shell.

2. Vi försöker ta reda på vilka containrar som körs (Svar: inga), men låt oss ändå köra kommandot:

   docker ps

   Du kommer att bli lite förvånad, men det visar sig att Docker-demon inte ens är igång:

   error during connect: Get http://docker:2375/v1.40/containers/json: dial tcp: lookup docker on 
   192.168.65.1:53: no such host

3. Låt oss starta den själva:

   dockerd &

   Ännu en otrevlig överraskning:

   failed to start daemon: Error initializing network controller: error obtaining controller instance: failed 
   to create NAT chain DOCKER: Iptables not found

4. Installerar paketen iptables och bash (det är alltid trevligare att arbeta i bash än i sh):

   apk add --no-cache iptables bash

5. Startar bash. Äntligen är vi tillbaka i vårt vanliga shell

6. vi försöker starta Docker igen:

   dockerd &

   Vi bör se en lång sträng av loggar som slutar med:

   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

7. Tryck på Enter. Vi är tillbaka i bash.

Från och med nu kan vi försöka köra andra containrar inom vår Docker-container, men vad händer om vi vill starta ännu en Docker-container inom vår Docker-container eller om något går fel och containern "flyger ut"? Då får vi börja om från början.

Egen DinD-container och nya experiment

För att undvika att upprepa ovanstående steg om och om igen har jag skapat en egen DinD-container:

https://github.com/alekslitvinenk/dind

En fungerande DinD-lösning gav mig möjligheten att köra Docker inuti Docker rekursivt och genomföra mer djärva experiment.
Ett sådant (lyckat) experiment med att köra MySQL och Nodejs kommer jag nu att beskriva.
De mest otåliga kan se hur det gick till här

Så låt oss börja:

1. Starta DinD i interaktivt läge. I denna version av DinD behöver vi manuellt mappa alla portar som våra underordnade containrar kan använda (detta arbetar jag redan med)

   docker run --privileged -it 
   -p 80:8080 
   -p 3306:3306 
   alekslitvinenk/dind

   Vi går in i bash, där vi omedelbart kan börja starta underbehållare.

2. Startar MySQL:

   docker run --name mysql -e MYSQL_ROOT_PASSWORD=strongpassword -d -p 3306:3306 mysql

3. Vi ansluter till databasen precis som vi skulle göra lokalt. Vi ser till att allt fungerar.

4. Startar den andra containern:

   docker run -d --rm -p 8080:8080 alekslitvinenk/hello-world-nodejs-server

   Observera att portmappningen här kommer att vara just 8080:8080, eftersom vi redan har mappar port 80 från värden till den överordnade containern på port 8080.

5. Gå till localhost i webbläsaren och se till att servern svarar "Hello World!".

I mitt fall har experimentet med inbäddade Docker-containrar varit ganska positivt och jag kommer att fortsätta utveckla projektet och använda det för staging. Jag tycker att detta är en mycket lättare lösning än Kubernetes och Jenkins X. Men det är min subjektiva åsikt.

Jag tror att det räcker för dagens artikel. I nästa artikel kommer jag att beskriva experimenten med rekursiv Docker-startning och montering av kataloger i djupet av inbäddade containrar mer detaljerat.

P.S. Om du tycker att detta projekt är användbart, vänligen ge det ett stjärna på GitHub, gör en fork och berätta för dina vänner.

Edit1 Har fixat felen, fokuserat på 2 videor

Källa: habr.com