Объясните как работать с Docker

Тебе это не нужно.

Я бы вручную установил ОС, весь стэк, конфигурацию, и общую папку (чтобы не копировать файлы). При необходимости эмулировать продакшн — создал бы ещё один контейнер.

Не надо использовать контейнер как облегчённую замену виртуальных машин. Это частая ошибка из-за которых многие потом ходят по форумам с миной «пробовали мы ваш докер — ерунда какая-то».

У вас есть какое-то окружение, которое состоит из нескольких процессов, взаимодействующих между собой тем или иным способом. Правильный подход заключается в том, что каждый процесс должен быть упакован в отдельный контейнер, торчащий нужным портом внаружу. Если нужно эмулировать несколько окружений на одной машине лучше посмотреть в сторону docker-compose.

Хорошо, я признаю, что пока не понимаю докер.

Это значит, что я должен, скажем, создать отдельный контейнер для mysql и отдельный контейнер для моего приложения на Node.js?

Да.

Да.

Нафига тогда это в ООО Рога и КОпыта по продаже дверных щеколд из Чугуева?
Для какого уровня предприятий это всё?

Для каких типов? Для интернет торговли? Для всяких мульти-корпораций, которые имеют офисы по всему миру?

Хорошо. У меня тогда остались вопросы про apt install в Dockerfile.

В официальном гайде устанавливается nginx и automake. Почему они берутся не из DockerHub, а из репозиториев?

там вредные советы :) автомейк тебе в работе не потребуется вообще - только для сборки (а сборочные зависимости в рабочий имидж пихать точно не стоит). а у nginx есть официальный контейнер, на базе которого ты можешь построить свой или использовать тот, что есть без модификаций, просто поместив в data-volume нужные конфиги

Я в некоторых Dockerfile видел apt-install — разве это уже не означает, что образ не иммутабелен? Ведь изменится версия библиотеки в репах — изменится и в твоём образе, разве нет?

Чтобы собрать образ нужно взять пустоту (или базовый минимальный образ) и накатить туда нужный софт. После того как образ собран, в нем можно запускать процессы. И да, он иммутабелен. (см так же docker volumes)

Я вижу как в очередном Dockerfile пишут FROM php:alpine-666 и чуть ниже RUN apt-install .... Это значит, что используемый образ из DockerHub — Ubuntu-based? В DockerHub все образы Ubuntu-based?

Alpine разве ubuntu based? На докер хабе очень много всего, в том числе всякие центоси и арчи. Бери любой и вперед.

Смысл докера в возможности собрать образ который будет работать из коробки где угодно.

Я тоже начинающий в этом вопросе, поэтому нижеследующее - моё скромное мнение.

Мы пользовались докером для сборки и тестирования. Плюс в том, что все этапы установки окружения заведомо автоматизированы и можно поставить на одной машине их несколько разных одновременно. Но это всё же виртуальная машина, причём ущербная. По сути никаких преимуществ перед настоящей виртуальной машиной нет. Может быть, какая-то пресловутая легковесность (это ещё надо померять, насколько она легковесна), зато затруднён доступ в контейнер. В принципе это обходится, но это лишние телодвижения.

При том, самое сложное в нашей работе было собирать 32-раздряную версию с ограничениями по памяти, которые выдерживает только 64-разрядная ОС. Для этого нужно настраивать какие-то библиотеки (забыл их название). Мы эту работу не делали и у нас нет скрипта, который настраивает это с голой 64-разрядной ОС. Там какая-то чёрная магия с библиотеками, сильно зависимая от версии. В итоге первая строчка нашего докерфайла говорила о том, что надо взять некий блоб из корпоративного хранилища. Получается, что и документированности процесса установки мы не получили.

Зато был ряд чисто технологических сложностей из-за отсутствия GUI. Круто, что наши люди теперь умеют запускать в докере VNC и получать гуй, но зачем это надо, если в виртуалке это возможно без лишних камланий?

А вот насчёт целесообразности установки на докер сервера базы данных для production у меня большие сомнения. Т.е. это практически уверенность, что так делать не надо. Известно, что сеть не надёжна, и любой сервер SQL строго предпочитает хранить базу на локальной файловой системе. В докере это недоступно, поскольку файловая система иммутабельна и хранить базу на локальной для докера ФС - это не дело. Т.е. хранить её негде - ни локально нельзя хранить, ни в подмонтированной файловой системе. В итоге, когда я разворачивал своё упражнение, я взял VPS хостинг, а не докер.

Для чего докер нужен? Честно скажу - я пока что тоже не понял.

Это работает так: вы берёте базовый образ, любым способом, например через apt-get меняете его, и создаёте свой образ, который в свою очередь, может стать базовым для дальнейшей работы.

Но это всё же виртуальная машина,

Докер - это не виртуальная машина. Сколько можно то.

Зато был ряд чисто технологических сложностей из-за отсутствия GUI. Круто, что наши люди теперь умеют запускать в докере VNC и получать гуй, но зачем это надо, если в виртуалке это возможно без лишних камланий?

Прямо скажем, это очень, _очень_ нестандартное требование к докеру. Но, вообще, можно было прокинуть в контейнер X-socket. Я так Firefox (а может и хром) в контейнере запускал.

В докере это недоступно, поскольку файловая система иммутабельна и хранить базу на локальной для докера ФС - это не дело. Т.е. хранить её негде - ни локально нельзя хранить, ни в подмонтированной файловой системе.

Правильный ответ: подмонтировать в контейнер файловую систему хоста.

Плавает как утка (но тонет), крякает как утка (но сипит). Зато быстрый. Не, не утка :) Виртуальная машина или нет - это вопрос терминологии, не более того. А вот вопрос, в каких случаях применять виртуальную машину, а в каких докер - это вопрос содержательный. Одними словами, что докер - не виртуальная машина, на него ответить нельзя.

Я для себя пока вижу только такой вариант, что если докер быстрее разворачивается (а это не факт), то его можно применять для тестирования. Всё. Других пока не вижу.

FROM php:alpine-666 и чуть ниже RUN apt-install ...

не apt, а apk, тогда будет работать. нет, не ubuntu-based, а какой-хочешь-based.
apt install сделает новый дифф-образ поверх старого. рассматривай образы как пронумерованные шаги:
1 - FROM alpine:latest;
2 - RUN bla-bla;
3 - apt install vsyakoe;
4 - COPY my_code /my_awesome_app.
если ты правишь только последний шаг - меняется последний дифф-образ, если, например, меняешь второй шаг - меняется второй и все следующие.

надо прочухать концепт, что контейнер - это одно приложение и ничего больше.
монга-нода-кролик-нгинкс - 4 контейнера и взгляд в сторону docker-compose.

ш. 4 не проще ли тогда volume подключить, чтобы каждый раз не сеобирать образ. Вместо docker build -t blablabla . Просто находясь в докере пересобираем проект

Так в том-то и дело! Если что-то плавает не как утка, крякает не как утка и выглядит не как утка, то скорее всего это какая-то другая птица. Все, буквально все, кто пытались думать о докере как о виртуальной машине испытавали схожее с вашим чувство глубокого разочарования.

Докер - это не виртуальная машина

А с KVM-рантаймом? :)

можно и так. для разработки наверно даже и лучше. в эксплуатации мне удобнее гарантированно грохнуть контейнер и так же гарантированно перезапустить новый. ну и шаги обозначены так, для пояснения.

Не проще. Это пусть собрать все недостатки докера и не получить его достоинств. Контейнер должен быть простым и примитивным: один процесс запускается в заранее подготовленном окружении и всё. Если к этому начать добавлять сложности, типа запуститься, чуть-чуть пошаманить с файловой системой, запустить вспомогательный процесс, который на самом деле основной и т.д., то использование докера теряет смысл.

есть еще nspawn. как можно его сравнить с докером и виртуалкой?

Так для чего он нужен-то? Для массива stateless сервисов можно себе помыслить, но тут напрягает проблема логов. Куда денутся дампы памяти и логи после смерти контейнера? Опять же, нужна внешняя ФС, а это снижение надёжности и усложнение оценки производительности.

Да и не так много истинно stateless сервисов. Я вообще пока не нашёл. Даже если он просто принимает и обрабатывает запрос, то потеря запроса может быть чувствительной. И оказывается, что основная сложность и ответственность в системе находится не внутри этого сервиса, а где-то в другом месте.

Не знаю, не сталкивался.

Т.е. реальный вариант использования докера такой: руки на стол! Настройка сред - это трудоёмкая вещь, в которой есть тонкости. Уволился человек - и никто больше не может сделать, чтобы приложение собиралось.

А если мы запихиваем всё это в докер, то у нас есть скрипт, который всё настраивает. В этом я и вижу смысл. Но тут докерность не столь важна. Ключевое слово здесь - скрипт. Но ведь наверняка есть и пакетная установка ОС, т.е. виртуальную машину для этой же цели тоже можно использовать.

А, вон ещё какая умная фича есть. Если я скомпилирую заново проект, то выполнится только 4 шаг (COPY). А если подмонтировать в контейнер свою фс, то достаточно будет перезапустить контейнер. 3 шаг выполнится только если я изменю его.

Хорошо. Теперь я хочу понять про иммутабельность. Если я захочу запустить старое приложение, которое работало в докере, то при создании нового образа (через docker build) всё что устанавливается через apt-get — будет установлено свежее. Например, раньше устанавливался пакет php-zip версии 2.1, а теперь 2.6.2. Это так работает?

Так для чего он нужен-то?

Для облегчения развёртывания, тестирования, автоматизации и безопасности. Контейнер это a-la статически скомпилированный бинарный файл, который запускается всегда и везде. И всегда и везде запускается одинаково. И в изолированном окружении.

Серебряной пулей не является, но улучшает надёжность и безопасность.

Куда денутся дампы памяти и логи после смерти контейнера?

Останутся лежать в ElasticSearch, зайдите в Kibana и проверьте.

нужна внешняя ФС,

У вас так и так на сервере есть файловая система. Я гарантирую это.

Но ведь наверняка есть и пакетная установка ОС

Тут есть тонкость. Если вы собрали образ, ваши пакеты с вами навечно. А если у вас есть скрипт с `apt install blah`, то сегодня он работает, а завтра — кто знает. Пакетики из интернета могут и пропасть.

А докер этому не подвержен? Если в Dockerfile прописать `apt install`. Сегодня получилось успешно собрать, а через недельку при повторной сборке (например, на чужом ноутбуке) вдруг что-нибудь случится.

docker build создаёт неизменный образ. При этом, конечно, сам процес создания заключается в изменении базового образа. В этом его смысл.

Правильный подход здесь — использовать метки. Т.е. через `docker build -t image:v0.0.1` сделали неизменный образ с php-zip-2.1. Через месяц запустили команду опять `docker build -t image:v.0.0.2` и получили новый образ с новой версией библиотеки. Старый при этом остался с вами.

Для массива stateless сервисов можно себе помыслить, но тут напрягает проблема логов.

отошлются в централизованное хранилище, вы же не предлагаете логи по контейнерам собирать.

Опять же, нужна внешняя ФС

не нужна, ну или не всегда.

Я вообще пока не нашёл.

так то их дохера, зачастую сервис ничего локально и не требует, может хранилище для временных файлов и только, если в планах хоть какой-то scale закладывался, то зачастую уже всё отвязано от конкретного сервера.

Даже если он просто принимает и обрабатывает запрос, то потеря запроса может быть чувствительной.

а куда ему теряться? если упал/убили по каким то критериям, то аcknowledge от таска не придёт и его подберёт другой consumer.

виртуалка — это эмулирование аппаратной части, а контейнеризация — это когда ОС поддерживает несколько изолированных userspace. Докер и nspawn — это контейнеризация, только семантически разная: докер изолирует отдельные процессы, а nspawn — всю ОС (это часто сравнивают с chroot).

У вас так и так на сервере есть файловая система.

Обычно «удалённая» файловая система - это совсем не то, что «локальная». Когда я монтирую ФС сервера в докер, надёжна ли она?

Ничего докер-специфичного. Сделал скрипт для создания виртуалки, сделал образ, сохранил образ, поставил метку. Через месяц повторил с другой версией PHP. Т.е. дело должно быть в чём-то другом.

А как можно обеспечить то, что на разных машинах код запускается на одном и том же образе? Чтобы, например, код одинаково запускался у разработчиков и на stage и production-сервере.

Devops-инженер должен скинуть образ всем разработчикам?

отошлются в централизованное хранилище, вы же не предлагаете логи по контейнерам собирать.

Я ничего не предлагаю, я пока не в теме. Но идея об отсылке логов выглядит стрёмной. А если не отошлются? Как мы узнаем о течении аварии?

Обычно «удалённая» файловая система - это совсем не то, что «локальная».

У вас есть сервер. Железный или виртуальный не важно. На нём есть файловая система. Я гарантирую это. Кусок этот файловой системы можно прокинуть внуть контейнера.

Попробуйте

$ mkdir /tmp/vol
$ docker run --rm -d --name test-nginx -v /tmp/vol:/exchange nginx
$ docker exec test-nginx ls -lh /exchange
total 0
$ touch /tmp/vol/hi-den73
$ docker exec test-nginx ls -lh /exchange
total 0
-rw-rw-r-- 1 1001 1001 0 Apr  2 13:29 hi-den73

При этом вся магия достигается за счёт mount-bind, что на фоне скорости доступа к диску — ниже статистической погрешности.

Когда я монтирую ФС сервера в докер, надёжна ли она?

В смысле? Контейнер это обычный процесс в слегка модифицированном окружении. Почему надёжность ФС должна меняться от того, как мы запустили работающий с ней процесс?

ничто не мешает вам делать свои велосипеды.

Подумайте лучше о другом сценарии.

1. Сервер внезапно умер. И по ssh недоступен. И после перезагрузки не включился. Если все логи были на мёртвом, недоступном сервере, как вы собираетесь узнать что с ним случилось?

2. У вас сто веб серверов. Надо проверить состояние /var/log/nginx/error.log на каждом. Ваши действия?

Я ничего не предлагаю, я пока не в теме.

так стоит поизучать, прежде чем выводы делать, хранение логов удалённо не так и плохо как кажется, даже без докера если у вас 10+ серверов с разными сервисами на них, когда таск может разделиться на несколько и обработаться на любом сервере, найди потом куда, что и как прыгало.

Но идея об отсылке логов выглядит стрёмной. А если не отошлются?

а идея о записи логов на диск не срёмная? а вдруг не запишутся?

Видимо у вас сервера/диски не умирали никогда ;-)

При этом вся магия достигается за счёт mount-bind, что на фоне скорости доступа к диску

Угу. Всё равно я пока в недоумении. Наверняка есть подводные камни какие-нибудь. Но может быть, ты и прав.

В общем, мой главный вопрос — что мне вообще делать с этим докером — отвечен. Огромное спасибо! Особенно ugoday :)

Теперь мне понятна эта технология и я пойду дальше разбираться в предназначении

Сервер внезапно умер. И по ssh недоступен. И после перезагрузки не включился.

Я тут читал задачу про двух генералов. Пока не знаю, как решать такие задачи. Может быть, они решаются за счёт зеркалирования (упадёт один сервер из трёх, но не более того). А может быть, никак не решаются. Но за счёт выбора неудачных технологий можно сделать положение ещё хуже. Пока всё для меня упирается в то, чем монтирование в докере отличается от обычного монтирования физического диска. Если не отличается, то может быть и нормально всё.

да, поэтому если ты хочешь гвоздями какие-то версии прибить - будут некоторые заморочки, но всё решаемо.
upd. выше ugoday всё разъяснил лучше меня

man mount | grep bind

Я тут читал задачу про двух генералов.

Слишком глубоко копаете. Вам бы в криптографию пойти с таким складом мысли. Задача не в создании теоретически-идеальной схемы, а в достижении разумной надёжности стистемы. Так вот, в рамках данного допущения достаточно сказать: перед смертью сервер посылал (ELK, rsyslog, не важно) логи и там должно быть что-то полезное. Может быть последние логи и не дошли, если сеть умерла раньше, но это уже не так важно.

чем монтирование в докере отличается от обычного монтирования физического диска.

Де факто, происходит следующее

$ ls /tmp/vol
hi-den73
$ ls /tmp/vol2
$ sudo mount --bind /tmp/vol /tmp/vol2
$ ls /tmp/vol2
hi-den73

Т.е. вы не монтируете одну файловую систему к другой, но меняете пути в рамках одной ФС.

Ну, тогда может оказаться, что докер и годится для развёртывания баз на проде. Я просто пока не разбирался, что значит это --bind, но буду иметь в виду.

А так - ну я должен понимать, как работает система, и как её чинить. Веб отличается от энтерпрайза тем, что там больше должно чиниться автоматически. Когда я в это воткнулся, я впал в ступор, из которого пока не вышел.

Веб отличается от энтерпрайза тем,

«Карма от кармана отличается турбулентностью!» (http://www.oaf.narod.ru/tundra.htm)

Я прочитал статьи про то зачем нужен докер, как на нём разворачивать простейшие приложения, но всё ещё не понимаю как я могу его использовать в своём проекте

Это значит, что тебе не нужен докер. Люди, которым нужен докер, абсолютно точно знают, что им нужен докер, и вопросов не задают. Если говорить о том, как докер используют в основном другие люди - они используют его для того, чтобы запускать на нем кал, который высрал индус в обмен на еду.

Node.js/Express/TypeScript, MongoDB, RabbitMQ, nginx

А м'сье знатный говноед. Жабоскриптеров припахивают к серверам потому, что вас развелось, как грязи, а не потому, что это какой-то там хороший фреймворк. В браузерах просто нет выбора, от JS отчаянно пытаются избавиться, создавая более адекватные надстройки, но все равно приходится в JS компилировать. Node.js не умеет в высокую нагрузку, а это значит, что ты до конца своих дней будешь писать говнобекенды для контор на 10-100 человек или «корпоративные приложения» уровня делфи или даже выше. В принципе, если тебя устраивает серая жизнь и возможность сыто существовать, не отсвечивая, то вполне приемлимый вариант, только не удивляйся, если годам к 30 начинешь впадать в кризис и бухать.

А вот насчёт целесообразности установки на докер сервера базы данных для production у меня большие сомнения

Есть весьма забавные формы сексуального извращения, в том числе у админов. Ставить БД на среду, которая создана из соображений невозможности работы БД на ней - это очень увлекательный процесс, и есть люди, которым он нравится.

Контейнер это a-la статически скомпилированный бинарный файл, который запускается всегда и везде. И всегда и везде запускается одинаково. И в изолированном окружении.

Для этого собирается статически линкованный бинарный файл безо всяких докеров. Так делали в форточках уже десятилетия. Зависимость от ABI ОС всегда есть и от нее никуда не денешься - иначе только виртуалка.

Куда денутся дампы памяти и логи после смерти контейнера?

Останутся лежать в ElasticSearch, зайдите в Kibana и проверьте.

Лишние сущности. Вместо запуска статически линкованного бинарника получаем необходимость строить целую инфраструктуру на докере и нанимать свору индусов, чтобы эту инфраструктуру поддерживать. Я понимаю, что это клевый способ устроиться на работу, но не все работодатели безграмотны в IT.