Является ли Docker/Vagrant сейчас стандартом для dev-окружения веб-разработчика?

Question

[l4m3r]

Я всегда пользовался LEMP (без VM) на своей убунте для разработки. Да, у меня стоит php 7.2, 5.6, nginx, mariadb, node, mongo, глобальный composer, линты. Всё это крутится аки сервер, зато очень удобно без всяких remote interpreter'ов и хорошей интеграцией с IDE. Я правильно понимаю, что это в 2018 антипаттерн и позор?
Я планирую в следующем году сменить работу и не знаю будут ли про dev-окружение спрашивать на собеседовании и какие-то требования к этому. Стоит ли переучиваться сразу на Docker? Или заставить себя пользоваться VM...

Я пробовал Docker. Меня оттолкнуло, что нельзя дать контейнеру фиксированный ip адрес, чтобы потом sitename.local в host прописать. Сложно пользоваться всякими composer'ами и подобными. Сложилось впечатление, что Docker только для продакшена норм подходит.

Vagrant мне тоже показался неудобным: каждый раз, когда мне нужно сделать хоть одностраничный лендос, мне нужно будет качать 2гб и заново устанавливать туда lamp и подобное? Homestead же мне показался жутко избыточным. Собственно, как и всё у laravel :)

Comments

[Евгений Ромашкан]

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

Answer 1

[DevMan]

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

докер:
проще вагранта по ресурсам. но гораздо менингитнее в плане изучения/поддержки.

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

Comments

[l4m3r]

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

Видимо, очень плохо знаю Vagrant. Этот стек в Vagrantfile задаётся? как в Dockerfile типа "RUN apt install php-cli..."? И типа можно будет один такой универсальный Vagrantfile создать для типовых сайтов и использовать его из проекта в проект.

[DevMan]

l4m3r, совершенно верно.

[alexq2]

В вагрантфайл можно описать свой проект полностью со всеми вм и подсунуть им папет манифест например.

Answer 2

[Sanes]

Как раньше пользовались нативно, так и будет самым правильным. ИМХО конечно.
В каждой компании свои извращения. За неделю покажут, расскажут и дадут попробовать.

Answer 3

[Станислав Бодро́в]

Стоит ли переучиваться сразу на Docker?

Стоит. Программисты его по разному немного распробовали, теперь неистоствуют.

Сложилось впечатление, что Docker только для продакшена норм подходит.

Продакшн продакшену рознь. Как-то интересовался у фанатеющих от него компутерщиков, готовы ли они, чтобы их ЗП считали на ПО развёрнутом в контейнерах? И что-то утвердительных ответов не было.

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

У некоторых контейнеры во время сборки тоже пол интернета тянут.

Или заставить себя пользоваться VM...

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

Comments

[l4m3r]

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

Короче, вот я снёс винду с игрульками. Поставил себе убунту. И встал вопрос как организовать рабочее
окружение у себя удобно (docker/vagrant показались не такими удобными просто, а lamp как-то неправильно). Наверное, зря я парюсь.

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

[Денис]

Продакшн продакшену рознь. Как-то интересовался у фанатеющих от него компутерщиков, готовы ли они, чтобы их ЗП считали на ПО развёрнутом в контейнерах? И что-то утвердительных ответов не было.

Не уловил связи окружения и по для расчёта ЗП

[Anton Mashletov]

ttys, ну контейнеры часть зп хавают прям в карман создателю докера, что не ясно

[Станислав Бодро́в]

ttys, сравни продакш какого-нибудь сайта и продакшн процессинга в банке. Где надёжней и устойчивей?

Не уловил связи окружения и по для расчёта ЗП

Внезапная встреча контейнера и OOM Killer не является чем-то экстраординарным и критическим. В настройках dockercompose можно указать что делать с контейнером при этой встрече: выключить, перезагрузить и ещё что-то. Некоторые свои системы специально делают без раздела подкачки, чтобы контейнеры при подобной ситуации не оттягивали свой конец, а сразу рестартовали. А теперь представь контейнер, в котором считают твою зряплату, или через который идёт транзакция в банк о ЗП, внезапно перезагрузился. И твоя ЗП на нолик стала меньше.

[Денис]

Станислав Бодро́в, что за ересь? Слово транщакции ничего не говорит? Таких дилетантских рассуждений я давно не видел!

[Станислав Бодро́в]

что за ересь?

Почему сразу ересь? Один из моментов каждодневной ебли с контейнерами.

Слово транщакции ничего не говорит?

Много чего говорит. Я думаю, в банковском процессинге не приходится по несколько раз на день базу поднимать. Тем более транзакция не панацея. Совсем. Сейчас будет немного дилетантских рассуждений:
вся свистопляска с транзакциями крутится вокруг write access log (в зависимости от базы он может именоваться по разному).
он реализуется линейной записью в определённый файл.
этот файл типа находится обычно на хорошей файловой системе, на хорошем контроллере носителей (raid), на хороших носителях.
Так вот - ни одна файловая система (даже хвалёная zfs), ни самый крутой контроллер raid, ни самый крутой носитель не гарантируют потерь данных. Доказано и проверено на опыте. Поэтому всякие энтерпрайз базы данных (oracle, sybase, teradata) пишут на raw-диски. Где исключены слабые звенья. И бэкапы приходится делать через каждые четыре часа. Потому что тразакции транзакциями, вот только бывает случайность с вероятностью выпадения один на миллиард, выпадает девять раз из десяти.

Ещё немного в довесок: система оркестрации, которая управляет десятками, сотнями контейнерами не будет заморачиваться с попыткой откатиться к последней валидной транзакции, подъёмом базы и проверкой корректности данных. У неё нет такого функционала. Если указано, что надо рестартовать контейнер, она это сделает. Всё.

[Денис]

Станислав Бодро́в, транзакция это подход к процессу а не банально процедура в рсубд.
Очень понравилось про zfs особенно попытка натянуть сову на глобус ;)
Главное как это всё присовокупить контейнерам? Как рукожопость архитекторов по для подсчёта ЗП присовокупляется к докеру?
ЗЫ: И особенно забавно, что оом приходит только к контейнерам (судя по твоему прошлому сообщению)

[Станислав Бодро́в]

Очень понравилось про zfs особенно попытка натянуть сову на глобус

Неправильный ответ на этот вопрос стоил вакансии в ЦОДе опсоса. Тоже по наивности думал, что zfs всему голова. Потом популярно и объективно объяснили про raid-массивы, файловые системы и почему энтерпрайзные базы используют raw-диски.

Как рукожопость архитекторов по для подсчёта ЗП присовокупляется к докеру?

Просим показать пример как во истину должно быть собственным примером. Сделать банковский процессинг только на контейнерах и утереть всем нос неслыханной надёжностью.

И особенно забавно, что оом приходит только к контейнерам

Его до знакомства с контейнерами не встречал. только слышал. LO в несколько тысяч встречал, но ООМК не было, память выжиралась, что ОС начинала фризить, но ООМК не было. Зато с контейнерами чуть ли не каждый день. Даже не интересно стало.

Answer 4

[Denis Melnikov]

Как по мне, надо просто знать как им пользоваться, а юзать то, что удобно...

Comments

[l4m3r]

Понимаете, ещё намного раньше было удобно и Denver. Если себя не заставлять, то так бы и на нём остался бы.

[Denis Melnikov]

l4m3r, денвер тоже крут для своего времени был = ), но докер, это что то с чем то, для меня пока что зародышь , чего то большего... скорей всего он войдет в стек, но позже... Очень много статей , которые описывают печальный опыт внедрение в продакт. Хотя звучит , по описанию красиво =) Разработал -упаковал -развернул ...

Answer 5

[Кирилл Несмеянов]

Меня оттолкнуло, что нельзя дать контейнеру фиксированный виртуальный ip адрес, чтобы потом sitename.local в host прописать.

Он всегда будет 127.0.0.1, т.е. адрес sitename.localhost (как и любой в домене localhost) будет сразу же на него вести.

Сложилось впечатление, что Docker только для продакшена норм подходит.

Как раз наоборот, для продакшена без шаманства докер слабо подходит, так что он только в основном для разработки.

Comments

[l4m3r]

Ну тем не менее, всех проектов будет localhost с разными портами? Это удобно?

[l4m3r]

А вы используйте только Docker? На рабочей машине вообще нет php и прочего?

[Кирилл Несмеянов]

Ну тем не менее, всех проектов будет localhost с разными портами? Это удобно?

l4m3r, никогда не было более одного запущенного проекта одномоментно, так что не знаю.

[Кирилл Несмеянов]

А вы используйте только Docker? На рабочей машине вообще нет php и прочего?

l4m3r, да нет, есть все версии php, от 5.6 до 7.4 но это лишь для тестов. Ничего более нет, остальное всё в докере.

[l4m3r]

Кирилл Несмеянов, можно, пожалуйста, несколько вопросов:

1) composer'ом, консольными командами (artisan/yii/...), npm, webpack, миграциями, тестированием удобно пользоваться? Каждый раз когда надо что-то сделать подобное, вы заходите в терминал, аттачитесь к контейнеру и там уже вводите команды?
2) То есть я правильно понял, что что у вас все проекты на localhost:80. И вы их по очереди запускаете? А браузер не будет ключить из-за того что по одному адресу разный контент кеширует?
3) все-таки есть какие-то неудобства или подводные камни у вас по сравнению с обычным lamp?

[Кирилл Несмеянов]

1) composer'ом, консольными командами (artisan/yii/...), npm, webpack, миграциями, тестированием удобно пользоваться? Каждый раз когда надо что-то сделать подобное, вы заходите в терминал, аттачитесь к контейнеру и там уже вводите команды?

l4m3r, только тогда, когда надо что-то выполнить на уровне приложеньки, ну, например миграции.

2) То есть я правильно понял, что что у вас все проекты на localhost:80. И вы их по очереди запускаете? А браузер не будет ключить из-за того что по одному адресу разный контент кеширует?

Не, никаких проблем с этим.

3) все-таки есть какие-то неудобства или подводные камни у вас по сравнению с обычным lamp?

Залезать внутрь контейнера - неудобно (но можно просто не вылезать из него). Конфижить и пробрасывать всякие xdebug маппинги внутрь тоже неудобно, но тут тоже достаточно один раз разобраться что и как. Единственное с чем ещё не разобрался - это автокомплит для Commad Line Tool плагинчика, тут действительно засада, так что приходится руками всегда набирать всякие "php console migrate" внутри контейнера.

Ну т.е. в целом минусы конечно есть, которые в основном касаются работы с тем, что внутри контейнеров, но и плюсов куча. И мне кажется, что возможность полностью настроить всё, начиная с обычной БД, заканчивая поднятым рядом Sentry, полностью сконфиженным кроном, супервизором и прочим - перевешивает.

[Кирилл Несмеянов]

l4m3r, ща чуть-чуть потыркал что там в шторме есть на эту тему. Минут 30 потратил времени на всё это дело, чтобы разобраться. Так что никаких проблем нет с этим.

Answer 6

[ТыжСисАдмин]

Является ли Docker/Vagrant сейчас стандартом для dev-окружения веб-разработчика?

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

Меня оттолкнуло, что нельзя дать контейнеру фиксированный ip адрес, чтобы потом sitename.local в host прописать.

Всё намного проще - поднимаете два контейнера: в первом Nginx во втором своё приложение.
Но так-то да, для разработки это всё слегка неудобно если предполагается допиливание фронта, для бэкенда вполне применимо.

Answer 7

[Андрей]

Сам недавно взялся за докер.

Меня оттолкнуло, что нельзя дать контейнеру фиксированный ip адрес,

Вроде же можно? Вот тут посмотрите, может это то что нужно?

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

Стоит ли переучиваться сразу на Docker? Или заставить себя пользоваться VM

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

Сложилось впечатление, что Docker только для продакшена норм подходит.

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

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