Докер и прочие контейнеризаторы — для доставки контента или также для разработки?

Question

[Kentavr16]

Вопрос с большой долей вероятности покажется вам идиотским. Но. Вот я потратил некоторое количество времени на изучение веб-разработки. Дошел до изучения докера, так как это мастхэв веб-разработчика судя по статьям/требованиям работодателей. Смотрю доки, статьи, обучающие видео. Но так до конца и не понял - нужен ли мне докер для самого процесса веб-разработки? Или все же это инструмент в первую очередь для доставки контента? Пока не вижу никаких преимуществ от разработки под докером - вижу что технически это реально, но билдить каждый раз после внесения изменений в код - что я от этого выиграю? Как с этим дела в реальной жизни, на реальном среднестатистическом проекте? Никак не могу получить целостную картину. Возможно ткнете на статью/доки, где подробно о практическом применении. Вот подобный вопрос на хэтом же ресурсе, но и там я не получил твердого ответа. Только что-то вроде "в веб-деве докер нужен, учи, там поймешь что к чему". Заранее спасибо за ваши наводки. Прошу не копипастить ссылку на офдокументацию самого докера/намекать на тупость вопроса, а отнестись с пониманием.

Comments

[Дмитрий]

Практическое применение это когда у вас не один проект, а вагон с каким нибудь еще легаси, или вагон микросервисов и вы можете не парясь о том какая там версия чего требуется - поднимать и работать. А если у вас один пет проект - смысл только в тренировке

Answer 1

[fenrir]

Если ты собрал и у тебя работает на локальной машине - не факт что заведётся на тесте/стейдже/проде.
Если ты собрал и у тебя работает в контейнере - оно вероятно будет работать везде и с одной команды.

Comments

[Kentavr16]

Вот и вопрос - мне на локалке разрабатывать и после тестировать в собранном на ноде образе или как?

[ky0]

Kentavr16, можете разрабатывать, как вам удобно - компилировать в самой IDE, запускать без контейнеров и т. д. Но в какой-то момент хорошо бы всё-таки запустить сборку проекта в докере - и только убедившись, что в докере всё ок, коммитить в репозиторий.

Иначе происходят сильно бесящие (меня, как девопс-инженера) ситуации, когда разработчик закоммитил, а CI у него обваливается - и он приходит с аргументом "локально у меня всё ок".

[fenrir]

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

Answer 2

[Drno]

Смысл в том, что все пакеты, зависимости итд можно упаковать в 1 контейнер, который с помощью 1 yml файла потом можно поднять фактически где угодно ( на любом линукс) с вероятностью в 99%

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

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

Answer 3

[Valentin Barbolin]

>Или все же это инструмент в первую очередь для доставки контента?
Докер упрощает процесс доставки контента, но это не едиственный его плюс. Он позволяет быстро создать,воссоздать,повторить аналогичное окружение и зависимости которые необходимы твоему приложению в любом (почти) месте где есть поддержка docker.

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

> Как с этим дела в реальной жизни, на реальном среднестатистическом проекте?
Повсеместно испольуется. Следующий шаг развития докер это k8s, а это mainstream. Если ты умееш работать с докером, то освоить k8s уже намного проще.

Если сильно упростить то контейнер докер это виртуальная машина на linux внутри которой крутиться одно приложение. В идеологии докера каждое приложение должно быть в отдельном контейнере - mysql,redis,php.

Докер позволяет обойти проблему зависимостей.

Помню когда первый раз столкнулся с docker, это была система анализа логов от ruckus. По своей структуре это был centos на котором было запущено 8-9 контейнеров docker. Таким подходом ruckus как минимум решил для себя проблему установки обновлений, тебе не надо ставить обновления на саму ОС, тебе достаточно обновить контейнер. Если контейнер не запустился, то просто откати его. Все библиотеки и зависимости внутри контейнеров. Это настолько упростило процесс разработки и доставки обновлений, что сложно и представить.

Answer 4

[Everything_is_bad]

но билдить каждый раз после внесения изменений в код

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

Comments

[Kentavr16]

А в случае если у меня условное СПА без бекенда - что можно вынести наружу, если весь код работает с модулями? Контейнеризировать папку с модулями? Вероятно я не до конца понял принцип...

[Everything_is_bad]

Kentavr16, тут вопрос, а нужен ли тебе тогда докер? у тебя есть проблема с зависимостями или что-то подобное?

[Kentavr16]

Everything_is_bad, нет, никаких проблем ни с чем не испытываю. Дело именно в ознакомлении - если я не понимаю как именно его использовать, то и ознакомиться увы не получится. Да, билдить, запускать контейнеры и и ТД я умею, а толку если полной картины нет.

[Everything_is_bad]

Kentavr16, значит тут он тебе не нужен

Answer 5

[Сергей Горностаев]

Дошел до изучения докера, так как это мастхэв веб-разработчика судя по статьям/требованиям работодателей.

Нет.Это полезно знать, но далеко не всегда стоит применять.

Как с этим дела в реальной жизни, на реальном среднестатистическом проекте?

Среднестатистическому проекту контейнеризация вообще не нужна. И даже там, где нужна, зачастую с ней имеют дело админы, а не разработчики.

В разработке докер нужен только тогда, когда вы ведёте множество проектов, которые требуют разных окружений и не поддерживают собственных средств виртуализации. Например разработка чего-то системного на C.
В развёртывании докер нужен тогда, когда у вас сотни динамически разворачиваемых серверов. Если у вас одна VPS'ка, то докер - это оверкилл.

Comments

[Everything_is_bad]

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

[Kentavr16]

Everything_is_bad , Valentin Barbolin , Drno , Дмитрий - спасибо всем за объяснения и комментарии. Для себя вынес следующее -
1) Не совсем правильно воспринимал концепцию докера, если это в основном про окружение. Раньше думалось что это дополнение/расширение среды разработки, которое отчасти призвано избавлять разработчика от настройки среды. То да не совсем.
2) Пока сделал вывод о том, что доскональное изучение докера - не вопрос первостепенного приоритета.
Странно в таком случае что не первый раз встречаю требования знания докера в описании вакансии джуна-фронтендера. Что-то вроде "реакт,понимание рест-архитектуры, докер". Называется убери третье лишнее.
Если кому есть что добавить - велкам. Все вышесказанное - ценная для меня информация.

[Сергей Горностаев]

Everything_is_bad, хайпожоры.

[fenrir]

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

[Сергей Горностаев]

прикладное нужно сейчас везде

Не везде. В Сбере например докер вообще запрещён, его даже не удастся установить на рабочую машину.

Answer 6

[Василий Банников]

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

Главное преимущество в том что у тебя инфраструктура на проде и инфраструктура при разработке похожие=> в случае проблем, они будут быстро вскрываться.

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

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

Comments

[Kentavr16]

Как часто вы пишете в докере?

[Василий Банников]

Kentavr16, что значит "пишете в докере"? У меня не такое сложное окружение для разработки, чтобы не устанавливать его на машину. Но вот тесты в докере я гоняю.

Хотя вот рядом есть ещё 1 проект на php - вот там я его в devcontainers завернул, тк окружение там сложное пздц, а захламлять свой комп php-шным мусором не хочется.