Kako sam pokrenuo Docker unutar Dockera i što je iz toga proizašlo

Bok svima! U njegovom prethodni članak, obećao sam govoriti o pokretanju Dockera u Dockeru i praktičnim aspektima korištenja ove lekcije. Vrijeme je da održiš svoje obećanje. Iskusni devopser će vjerojatno prigovoriti da oni koji trebaju Docker unutar Dockera jednostavno proslijede Docker daemon socket s hosta u spremnik i to će biti dovoljno u 99% slučajeva. Ali nemojte žuriti bacati kolačiće na mene, jer ćemo razgovarati o stvarnom pokretanju Dockera unutar Dockera. Ovo rješenje ima mnogo mogućih primjena, a ovaj je članak o jednoj od njih, stoga se zavalite i ispružite ruke ispred sebe.

početak

Sve je počelo jedne kišne rujanske večeri kada sam čistio stroj koji sam unajmio za 5 dolara na Digital Oceanu, a koji je bio zamrznut jer je Docker svojim slikama i spremnicima napunio svih 24 gigabajta raspoloživog prostora na disku. Ironija je bila u tome što su sve te slike i spremnici bili prolazni i bili su potrebni samo za testiranje performansi moje aplikacije svaki put kada se objavi nova verzija biblioteke ili okvira. Pokušao sam napisati skripte ljuske i postaviti cron raspored za čišćenje smeća, ali nije pomoglo: svaki put je neizbježno završilo s pojedenim prostorom na disku mog poslužitelja i spuštanjem poslužitelja (u najboljem slučaju). U nekom sam trenutku naišao na članak o tome kako pokrenuti Jenkins u spremniku i kako može stvarati i brisati cjevovode za izgradnju kroz utičnicu docker demona koja je proslijeđena u njega. Svidjela mi se ideja, ali sam odlučio ići dalje i pokušati eksperimentirati s izravnim pokretanjem Dockera unutar Dockera. Tada mi se činilo sasvim logičnim rješenjem preuzeti Docker slike i napraviti kontejnere za sve aplikacije koje su mi bile potrebne za testiranje unutar drugog kontejnera (nazovimo ga staging kontejner). Ideja je bila pokrenuti pripremni spremnik s oznakom -rm, koja automatski briše cijeli spremnik i sav njegov sadržaj kada se zaustavi. Petljao sam sa Docker slikom iz samog Dockera (https://hub.docker.com/_/docker), ali ispalo je preglomazno i ​​nikad ga nisam uspio natjerati da radi onako kako sam trebao i htio sam sam ići do kraja.

Praksa. Čunjevi

Odlučila sam napraviti spremnik kako trebam i nastavila s eksperimentima, što je rezultiralo bezbrojnim pupoljcima. Rezultat mog samomučenja bio je sljedeći algoritam:

1. Pokrećemo Docker spremnik u interaktivnom načinu rada.

   docker run --privileged -it docker:18.09.6

   Obratite pažnju na verziju spremnika, zakoračite desno ili lijevo i vaš DinD se pretvara u bundevu. Zapravo, stvari se često pokvare kada se objavi nova verzija.
   Moramo odmah ući u školjku.

2. Pokušavamo saznati koji spremnici rade (odgovor: nijedan), ali ipak pokrenimo naredbu:

   docker ps

   Bit ćete malo iznenađeni, ali ispada da Docker demon uopće nije pokrenut:

   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. Pokrenimo ga sami:

   dockerd &

   Još jedno neugodno iznenađenje:

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

4. Instalirajte iptables i bash pakete (sve je ugodnije raditi u bashu nego u sh):

   apk add --no-cache iptables bash

5. Pokrenimo bash. Napokon smo opet u uobičajenoj ljusci

6. Pokušajmo ponovno pokrenuti Docker:

   dockerd &

   Trebali bismo vidjeti dugačak list dnevnika koji završava s:

   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. Pritisni enter. Vratili smo se u bash.

Od sada možemo pokušati pokrenuti druge spremnike unutar našeg Docker spremnika, ali što ako želimo pokrenuti još jedan Docker spremnik unutar našeg Docker spremnika ili nešto pođe po zlu i spremnik se sruši? Počni sve ispočetka.

Vlastiti DinD kontejner i novi eksperimenti

Kako bih izbjegao stalno ponavljanje gornjih koraka, napravio sam vlastiti DinD spremnik:

https://github.com/alekslitvinenk/dind

Radno DinD rješenje dalo mi je mogućnost rekurzivnog pokretanja Dockera unutar Dockera i izvođenja avanturističkih eksperimenata.
Sada ću opisati jedan takav (uspješan) eksperiment s pokretanjem MySQL-a i Nodejsa.
Oni najnestrpljiviji mogu vidjeti kako je bilo ovdje

Dakle, krenimo:

1. DinD pokrećemo u interaktivnom načinu rada. U ovoj verziji DinD-a moramo ručno mapirati sve priključke koje naši dječji spremnici mogu koristiti (već radim na tome)

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

   Ulazimo u bash, odakle možemo odmah pokrenuti podređene spremnike.

2. Pokrenite MySQL:

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

3. S bazom se povezujemo na isti način kao što bismo se s njom spajali lokalno. Pobrinimo se da sve radi.

4. Pokrenite drugi spremnik:

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

   Imajte na umu da će mapiranje luka biti točno 8080:8080, budući da smo već mapirali port 80 od glavnog računala do nadređenog spremnika u port 8080.

5. Idemo na localhost u pregledniku, provjerimo odgovara li poslužitelj "Hello World!"

U mom slučaju, eksperiment s ugniježđenim Docker spremnicima pokazao se prilično pozitivnim i nastavit ću razvijati projekt i koristiti ga za inscenaciju. Čini mi se da je ovo puno lakše rješenje od Kubernetesa i Jenkinsa X. Ali ovo je moje subjektivno mišljenje.

Mislim da je to sve za današnji članak. U sljedećem ću članku detaljnije opisati eksperimente s rekurzivnim pokretanjem Dockera u Dockeru i montiranjem direktorija duboko u ugniježđene spremnike.

PS Ako smatrate da je ovaj projekt koristan, dajte mu zvjezdicu na GitHubu, račvajte ga i recite svojim prijateljima.

Edit1 Ispravljene pogreške, fokusiran na 2 videa

Izvor: www.habr.com