Kako sem zagnal Docker znotraj Dockerja in kaj je prišlo iz tega

Pozdravljeni vsi skupaj! V njegovem prejšnji članek, sem obljubil, da bom govoril o izvajanju Dockerja v Dockerju in praktičnih vidikih uporabe te lekcije. Čas je, da izpolniš obljubo. Izkušen devopser bo verjetno ugovarjal, da tisti, ki potrebujejo Docker znotraj Dockerja, preprosto posredujejo vtičnico Docker daemon iz gostitelja v vsebnik in to bo dovolj v 99% primerov. Vendar ne hitite vame metati piškotkov, ker bomo govorili o dejanskem izvajanju Dockerja znotraj Dockerja. Ta rešitev ima veliko možnih aplikacij in ta članek govori o eni od njih, zato se usedite in poravnajte roke pred seboj.

začenja

Vse se je začelo nekega deževnega septembrskega večera, ko sem čistil stroj, ki sem ga najel za 5$ na Digital Oceanu in je bil zamrznjen, ker je Docker s svojimi slikami in kontejnerji zapolnil vseh 24 gigabajtov razpoložljivega diskovnega prostora. Ironija je bila v tem, da so bile vse te slike in vsebniki začasni in so bili potrebni le za testiranje delovanja moje aplikacije vsakič, ko je bila izdana nova različica knjižnice ali ogrodja. Poskušal sem pisati lupinske skripte in nastaviti časovni razpored za čiščenje smeti, vendar ni pomagalo: vsakič se je neizogibno končalo tako, da je bil pojeden prostor na disku mojega strežnika in je strežnik (v najboljšem primeru) visel. Na neki točki sem naletel na članek o tem, kako zagnati Jenkins v vsebniku in kako lahko ustvari in izbriše gradbene cevovode prek vtičnice docker daemon, ki je posredovana vanj. Ideja mi je bila všeč, vendar sem se odločil, da grem dlje in poskusim eksperimentirati z neposrednim izvajanjem Dockerja znotraj Dockerja. Takrat se mi je zdela povsem logična rešitev, da naložim slike Dockerja in ustvarim kontejnerje za vse aplikacije, ki sem jih potreboval za testiranje znotraj drugega kontejnerja (recimo mu staging container). Ideja je bila zagnati uprizoritveni vsebnik z zastavico -rm, ki samodejno izbriše celoten vsebnik in vso njegovo vsebino, ko je ustavljen. Poigraval sem se s sliko Docker iz samega Dockerja (https://hub.docker.com/_/docker), vendar se je izkazalo za preveč okorno in nikoli mi ni uspelo pripraviti, da bi delovalo tako, kot sem potreboval, in želel sem iti sam do konca.

Vadite. Stožci

Odločil sem se, da bo posoda delovala tako, kot sem potreboval, in nadaljeval s poskusi, kar je privedlo do neštetih popkov. Rezultat mojega samomučenja je bil naslednji algoritem:

1. Vsebnik Docker zaženemo v interaktivnem načinu.

   docker run --privileged -it docker:18.09.6

   Bodite pozorni na različico posode, stopite desno ali levo in vaš DinD se spremeni v bučo. Pravzaprav se stvari precej pogosto pokvarijo, ko se izda nova različica.
   Takoj moramo priti v lupino.

2. Poskušamo ugotoviti, kateri vsebniki se izvajajo (odgovor: noben), vendar vseeno zaženimo ukaz:

   docker ps

   Nekoliko boste presenečeni, vendar se je izkazalo, da demon Docker sploh ne deluje:

   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. Zaženimo ga sami:

   dockerd &

   Še eno neprijetno presenečenje:

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

4. Namestite pakete iptables in bash (v bashu je vse bolj prijetno delati kot v sh):

   apk add --no-cache iptables bash

5. Zaženimo bash. Končno smo spet v običajni lupini

6. Poskusimo znova zagnati Docker:

   dockerd &

   Morali bi videti dolg list dnevnikov, ki se konča z:

   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. Pritisnite Enter. Spet smo v bašu.

Od zdaj naprej lahko poskusimo zagnati druge vsebnike znotraj našega vsebnika Docker, toda kaj, če želimo zagnati še en vsebnik Docker znotraj našega vsebnika Docker ali gre kaj narobe in se vsebnik zruši? Začni znova.

Lastna DinD posoda in novi poskusi

Da bi se izognil ponavljanju zgornjih korakov znova in znova, sem ustvaril svoj vsebnik DinD:

https://github.com/alekslitvinenk/dind

Delujoča rešitev DinD mi je dala možnost rekurzivnega izvajanja Dockerja znotraj Dockerja in izvajanja bolj pustolovskih poskusov.
Zdaj bom opisal en tak (uspešen) eksperiment z izvajanjem MySQL in Nodejs.
Najbolj neučakani si lahko ogledate, kako je bilo tukaj

Torej, začnimo:

1. DinD zaženemo v interaktivnem načinu. V tej različici DinD moramo ročno preslikati vsa vrata, ki jih lahko uporabljajo naši podrejeni vsebniki (na tem že delam)

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

   Pridemo v bash, od koder lahko takoj začnemo zaganjati podrejene vsebnike.

2. Zaženi MySQL:

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

3. Z bazo se povežemo na enak način, kot bi se z njo povezali lokalno. Poskrbimo, da vse deluje.

4. Zaženite drugi vsebnik:

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

   Upoštevajte, da bo preslikava vrat natančna 8080:8080, saj smo vrata 80 od gostitelja do nadrejenega vsebnika že preslikali v vrata 8080.

5. V brskalniku gremo na localhost in poskrbimo, da strežnik odgovori "Hello World!"

V mojem primeru se je poskus z ugnezdenimi Docker kontejnerji izkazal za precej pozitivnega in projekt bom še naprej razvijal in ga uporabljal za uprizoritev. Zdi se mi, da je to veliko lažja rešitev kot Kubernetes in Jenkins X. Ampak to je moje subjektivno mnenje.

Mislim, da je to vse za današnji članek. V naslednjem članku bom podrobneje opisal eksperimente z rekurzivnim izvajanjem Dockerja v Dockerju in nameščanjem imenikov globoko v ugnezdene vsebnike.

PS Če se vam zdi ta projekt koristen, ga označite z zvezdico na GitHubu, ga razdelite in povejte svojim prijateljem.

Uredi1 Popravljene napake, osredotočeno na 2 videa

Vir: www.habr.com