🥇Как стартирах Docker вътре в Docker и какво се получи

Здравейте на всички! В своето в предишната статия, обещах да разкажа за стартиране на Docker в Docker и практическите аспекти на това занимание. Време е да изпълня обещанието си. Опитен DevOps специалист може да възрази, че на тези, на които им е нужен Docker в Docker, просто пробиват сокета на Docker демона от хоста в контейнера и това е достатъчно в 99% от случаите. Но не бързайте да ме замеряте с бисквити, защото става въпрос за истинско стартиране на Docker вътре в Docker. Това решение има много възможни области на приложение и за една от тях е тази статия, така че се настанете удобно и изправете ръцете си пред себе си.

Как стартирах Docker вътре в Docker и какво се получи

Начало

Всичко започна на дъждовен септемврийски вечер, когато чистех наетата за 5 $ машинка на Digital Ocean, която се блокира заради това, че Docker запълни всичките 24 гигабайта налично дисково пространство с образи и контейнери. Иронията беше в това, че всичките тези образи и контейнери бяха преходни и бяха нужни само за тестване на функционалността на моето приложение всеки път, когато излезе нова версия на някоя библиотека или фреймуорк. Опитах се да пиша shell скриптове и да настройвам cron задачи за почистване на мърсотиите, но това не помогна: всеки път всичко неизменно завършваше с това, че дисковото пространство на моят сървър беше заето, а сървърът зависваше (в най-добрия случай). В един момент попаднах на статия за това как да стартирам Jenkins в контейнер и как той може да създава и премахва конвейри за компилация чрез пробит в него сокет на Docker демона. Идеята ми хареса, но реших да отида по-далеч и да експериментирам с директно стартиране на Docker вътре в Docker. Тогава ми се струваше напълно логично решение да изтеглям docker образи и да създавам контейнери на всички приложения, които ми трябват за тестване, вътре в друг контейнер (нека го наречем staging контейнер). Идеята беше да стартирам staging контейнера с флага -rm, който автоматично изтрива целия контейнер с цялото му съдържание при спиране. Разгледах Docker образа от самия Docker (https://hub.docker.com/_/docker), но той се оказа твърде обемен и не успях да го накарам да работи по начина, по който ми трябваше, и исках да премина през целия процес сам.

Практика. Неуспехи

Поставих си за цел да накарам контейнера да работи така, както ми трябваше, и продължих да експериментирам, резултатът от което бяха безброй пречки. В резултата на моето самоизтезание излезе следният алгоритъм:

Стартираме Docker контейнер в интерактивен режим.
```
docker run --privileged -it docker:18.09.6
```
Обърнете внимание на версията на контейнера, всяка стъпка наляво или надясно и вашият DinD се превръща в тиква. Всъщност, всичко често се счупва с излизането на нова версия.
Трябва да попаднем направо в shell.
Опитваме да разберем какви контейнери са стартирани (Отговор: никакви), но нека все пак изпълним командата:
```
docker ps
```
Ще бъдете малко изненадани, но се оказва, че Docker демонът дори не е стартиран:
```
error during connect: Get http://docker:2375/v1.40/containers/json: dial tcp: lookup docker on
192.168.65.1:53: no such host
```

Нека го стартираме сами:

dockerd &

Още едно неприятно изненадване:

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

Инсталираме пакетите iptables и bash (в bash е винаги по-приятно, отколкото в sh):
```
apk add --no-cache iptables bash
```
Стартираме bash. Накрая сме отново в познатия shell
опитваме отново да стартираме Docker:
```
dockerd &
```
Трябва да видим дълга поредица от логове, завършваща с:
```
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
```
Натискаме Enter. Отново сме в bash.

Започвайки от този момент, можем да опитваме да стартираме други контейнери в нашия Docker контейнер, но какво ще стане, ако искаме да вдигнем още един Docker контейнер вътре в нашия Docker контейнер или нещо не върви и контейнерът "излита"? Започваме отначало.

Собствен DinD контейнер и нови експерименти

За да не повтарям стъпките отгоре отново и отново, създадох собствен DinD контейнер:

https://github.com/alekslitvinenk/dind

Работното DinD решение ми даде възможност да стартирам Docker вътре в Docker рекурсивно и да провеждам по-смели експерименти.
Един такъв (успешен) експеримент с MySQL и Nodejs сега ще опиша.
Най-нетърпеливите могат да видят как беше тук

И така, да започнем:

Стартираме DinD в интерактивен режим. В тази версия на DinD трябва ръчно да мапваме всичките портове, които могат да се използват от нашите дъщерни контейнери (работя над това)
```
docker run --privileged -it
-p 80:8080
-p 3306:3306
alekslitvinenk/dind
```
Влизаме в един баш, от който можем да започнем веднага с пускането на дъщерни контейнери.

Стартираме MySQL:

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

Свързваме се с базата данни по същия начин, както бихме се свързали локално. Убедяваме се, че всичко работи.
Стартираме втори контейнер:
```
docker run -d --rm -p 8080:8080 alekslitvinenk/hello-world-nodejs-server
```
Обърнете внимание, че картографирането на порта тук ще бъде именно 8080:8080, тъй като вече сме картографирали порт 80 от хоста в родителския контейнер на порт 8080.
Отиваме на localhost в браузъра и се убедяваме, че сървърът отговаря с "Hello World!".

В моя случай експериментът с вложени Docker контейнери се оказа доста положителен и ще продължа да развивам проекта и да го използвам за стейджинг. Смятам, че това е много по-леко решение от Kubernetes и Jenkins X. Но това е мое субективно мнение.

Мисля, че това е всичко за днешната статия. В следващата статия ще опиша по-подробно експериментите с рекурсивното стартиране на Docker в Docker и монтиране на директории навътре в вложените контейнери.

P.S. Ако смятате, че този проект е полезен, моля, дайте му звезда в GitHub, направете форк и разкажете на приятелите си.

Edit1 Поправих грешки, фокусирах се върху 2 видеа

Източник: habr.com