Является ли установка php/node на хост антипаттерном веб-разработки в 2018?

Question

[l4m3r]

Я правильно понимаю, что любое начинание (будь то hello world на 2 строчки или более крупный веб-проект), по-хорошему, должно быть обязательно изолировано с помощью контейнеров или VM с фиксированием версий.
И хост машина разработчика не должна содержать ничего, кроме собственно Docker, Vagrant и, наверное, git.
Понятно, что "делай как удобно", но интересен именно best practice.

PS: а то вот переустановил убунту и на моменте apt install php задумался, нужно ли это?

Answer 1

[Stalker_RED]

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

А если ответы типа "быть как все" или "следовать современным модным трендам" - это так себе ответы, и не стоит связываться.

Comments

[l4m3r]

Ну как минимум же ради СУБД, elastic, cron для разработки ... Чтобы они не крутились на компе разработчика?

Answer 2

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

Нет большего сигнала о профессиональной несостоятельности, чем бездумное следование хайпу.

Comments

[l4m3r]

А если "думное"? Третий раз напишу: Ну как минимум же ради СУБД, elastic, cron для разработки ... Чтобы они не крутились на компе разработчика?

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

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

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

По поводу СУБД есть прекрасный ответ юзера Melkij.

[l4m3r]

Сергей Горностаев, я правильно понимаю, что у вас ничего не крутится вы запускаете сервис postgres и подобное по мере надобности? А, например, всякие очереди / cron? Получается, вот сесть работать с проектом, вам надо запустить миниум 2-3 сервиса

[l4m3r]

Сергей Горностаев, то есть получается, для типовых фриланс проектов ни docker, ни vagrant вообще не нужен? просто чтобы эти сервисы не крутились, надо запускать их по необходимости

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

l4m3r, да, запускаю по мере надобности. В том числе брокеры очередей, если в том есть потребность. Не вижу ничего страшного в том, чтобы набрать три команды в консоли. Тем более, что эта проблема легко решается shell-скриптом\батником. Крон в системе и так есть. Правда, не понимаю, зачем он может понадобиться на этапе разработки.

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

l4m3r, может и есть какие-то corner cases, в которых без контейнеров никак. Типа наличия двух проектов, которые требуют разных конфликтующих версий какой-то библиотеки, причём обязательно на уровне системы. Но такой хлам ещё встретить надо. В обыденной жизни потребности в контейнерах нет.

Answer 3

[Decadal]

Я правильно понимаю, что любое начинание (будь то hello world на 2 строчки или более крупный веб-проект), по-хорошему, должно быть обязательно изолировано с помощью контейнеров или VM с фиксированием версий.

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

Comments

[l4m3r]

Ну как минимум же ради СУБД, elastic, cron для разработки ... Чтобы они не крутились на компе разработчика?

[Decadal]

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

Answer 4

[Владислав]

> best practice

Смысл в том, что для разных проектов best practice разный.
Если вы работаете в Facebook или чем-то, где у вас более 10 серверов, то да - задумываться о виртуализации необходимо.
В противном случае (ИМХО, конечно) best practice означает "не усложняй задачу на ровном месте".
Вот неплохая статья на хабре по теме: https://habr.com/post/421895/

Comments

[l4m3r]

вопрос только про разработку не прод. Да и вообще команды у меня нет. Разрабатываю один

Answer 5

[Александр]

должно быть обязательно изолировано

Это все делается в первую очередь для создания (и легкого переноса) одинакового рабочего окружения. Бонусом сверху идет некоторая защита частей сервиса (контейнеров) от возможно-скомроментированного контейнера.

Comments

[l4m3r]

ну так это должно быть всегда же?

Answer 6

[Sanes]

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