Правильно ли я понял философию Docker?

Question

[Кот Учёный]

Я только-только начал вникать в Docker, и мне понравилось. Но прежде чем создать свой первый рабочий стек, я хотел бы удостовериться, что я правильно всё понял. Вот как я вижу вижу веб-приложение, которое работает на связке nginx + Node.js + MongoDB:

1. nginx
   
   • HTTP-сервер
     
   • Конфиг
     
   • Логи
     
2. Node.js
   
   • Движок (сам Node.js)
     
   • Исходный код приложения
     
   • npm-модули
     
     • Глобальные
       
     • Локальные
       
   • Конфиг приложения
     
   • Логи
     
3. MongoDB
   
   • Сервер СУБД
     
   • Базы данных
     
   • Конфиг
     
   • Логи
     

Как это будет в Docker:

1. Образы
   
   1. nginx
      
   2. Node.js и глобальные npm-модули
      
   3. Исходный код и локальные npm-модули (или лучше это в предыдущий контейнер, и при старте выполнять npm install?)
      
   4. СУБД
      
2. Контейнеры данных
   
   1. Базы данных
      
3. На файловой системе хоста
   
   1. Логи (но, я так понимаю, это немного нарушает принцип изолированности. Если так, то куда их? В отдельный контейнер?)
      
   2. Все конфиги (или лучше разместить конфигурацию в Dockerfile полностью?)
      

Допустил ли я где-нибудь ошибки? Не могли бы ли вы поправить меня в 1.c., 3.a., 3.b.?

Answer 1

[Сергей Протько]

Контейнеры данных

Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).

Исходный код и локальные npm-модули (или лучше это в предыдущий контейнер, и при старте выполнять

Нет, npm install надо выполнять ДО сборки образа. Когда контейнер стартует - внутри у него уже все должно быть. Опять же я лично против того, что бы выносить исходники проекта в отдельный контейнер-пустышку. У вас есть контейнер с нодой - исходники для ноды должны быть там. Есть некоторые нюансы связанные со сборкой контейнера но это так.

На файловой системе хоста

Ничего.

Логи прокидываются в stdout/stderr контейнера и собираются на хосте через докер любым подходящим драйвером (читаем документацию).

Конфигурация - все что в конфигах от окружения к окружению меняется - в ENV переменные. Все остальное - не меняется и потому просто вшито внутрь контейнера.

Comments

[Евгений]

Вот все равно не понимаю нафига это нужно, если поддержка разных версий не требуется и данные все равно через volume прокидываются из основной системы в докер образы.

[Сергей Протько]

Nc_Soft: что именно нужно? Зачем так замарачиваться? Банально удобство поддержки. Если у вас обязанности разделены так, что одина обязанность на контейнер, то:

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

[Кот Учёный]

>> Контейнеры данных
> Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).

То есть, хранить БД на хосте, а не в контейнере? А как же изоляция? Запись на хост-машину — это же, вроде как, не совсем соответствует Docker-way?

[Сергей Протько]

Кот Учёный: ну как бы "контейнер данных" тоже волумы использует для персиста данных. И да, это не то же самое что просто писать на хост, данные будут сохраняться где-то там, неведомо где. Суть то в изоляции, а не в полном отказе от хранения данных на хосте. Контейнеры как раз таки должны быть stateless.

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

[Adrastus]

"Нет, npm install надо выполнять ДО сборки образа."
хм, а потом через "COPY node_modules app/node_modules"?

а в чем минус их делать сразу внутри? ну кроме того что постоянно перекачивать их. В тех же примерах официального node dockerfile в ONBUILD npm делается внутри контейнера.

[Сергей Протько]

Adrastus: ONBUILD обычно используют в ситуациях, когда ваш образ будет использоваться только как базовый, и когда результат команды зависит от каких-то переменных окружения к примеру. Ну то есть мы предоставляем возможность "собрать под себя" базовый образ. Это очень удобно, но это не совсем для этих нужд.

В принципе если хотите - можете ставить зависимости и при сборке контейнера, это тоже вполне себе живой вариант. Проблема только в том что вы не сможете при сборке использовать кэш. Так же помимо npm есть другие менеджеры пакетов, например если вы собираете PHP контейнер - там по дефолту нет composer, а стало быть его надо еще и ставить отдельно.

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

[Reckful]

>> Контейнеры данных
> Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).
named volume - это https://docs.docker.com/engine/reference/commandli... ?

[Сергей Протько]

Reckful: да. https://github.com/docker/docker/issues/17798

[Алекс]

> Нет, npm install надо выполнять ДО сборки образа.
Если мы используем named volumes как тогда производить инициализацию приложения через Dockerfile? Ведь в команде RUN у нас недоступны данные из named volumes. Или я что то упускаю?

[Сергей Протько]

ALexhha: named volumes наполнять при старте контейнера. Образ ничего не знает ни о каких волумах, это тупо образ.

и причем тут npm install? вы это все в волумы пихаете? как-то это так себе решение.

[Алекс]

Сергей Протько:
> named volumes наполнять при старте контейнера
вот в этом и вопрос, как наполнять при старте? Писать самописные скрипты или есть что то более удобное? Ну и второй вопрос. Раз данные на volumes у нас меняются, то мы не можем гарантировать 100% воспроизведения и повторяемости, что так же не очень хорошо.

> и причем тут npm install? вы это все в волумы пихаете? как-то это так себе решение.
у меня там legacy код, который уже не будет меняться. А volumes пришлось использовать только на время отладки.

[Сергей Протько]

ALexhha:

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

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

npm install нужно делать либо ДО сборки образа контейнера либо ВО ВРЕМЯ сборки. То есть вот та самая директива ON BUILD она как раз для этого. И это своего рода гарантия того что после сборки образ будет содержать всегда одни и те же зависимости.

[Алекс]

Сергей Протько: Прочитал ONBUILD, но то ли я его не до конца понял, то ли он выполняет немного другую задачу. Вы бы могли привести какой то простой пример, который позволит произвести инициализацию приложения, для упрощения пусть это будет npm install && npm run, данных которые хранятся на внешнем volume и подключаются к контейнеру только при старте через -v

[Сергей Протько]

Алекс: entrypoint.

Вообще делать npm install в рантайме плохо потому что npm install может не взлететь и "стабильность" контейнера окажется под большим сомнением. Но если вы осознаете риски - то вперед.

[Кот Учёный]

Сергей Протько: но если делать npm install на хост-машине, то это же уменьшает переносимость приложения (появляется зависимость от ноды на хосте)? На мой взгляд, это странно. Я думаю, разумнее было бы просто обрабатывать фейл npm install, не?

[Кот Учёный]

Сергей Протько: ну, или создавать образ и пихать туда приложение (то есть, каждый деплой — новый образ, его распространение по нодам, остановка старых и запуск новых).

[Алекс]

Ну я же писал, из-за того, что код меняется, я не могу использовать data контейнер или зашивать код в сам образ. Но entrypoint вроде будет выполняться каждый раз при запуске контейнера, т.е. придется в кауком-нибудь bash скрипте проверять, инициализировали мы контейнер или нет?

[Сергей Протько]

Кот Учёный: ничего не понял. on build как раз выполняет команду внутри контейнера при сборке образа оного. То есть при таком раскладе мы не завязываемся на хосте и все клево.

Алекс: что значит "код меняется"? На продакшене? Это как?

[Алекс]

Я использую -v для "проброса" данных внутрь контейнера, но на этапе сборки они не доступны. Или мы с вами говорим о разных вещах?

[Сергей Протько]

Алекс: то есть ваша сборка зависит от каких-то данных? Вы можете сделать npm install ДО того как понадобятся данные? если так - то самое страшное позади и далее - entrypoint и баш скрипты.

[Алекс]

Сергей Протько:
> Вы можете сделать npm install ДО того как понадобятся данные?
нет, не могу. Ибо данных на этапе сборки образа попросту нет. Она находятся на хосте и подключаются при запуске через -v