Правильный опыт

Пролистал несколько статей. Про использование докера и вагранта с оффтопиком, я , конечно, погорячился...

Страшные вещи глаголят.

Я не такой уж профи - переползаю с vagrant на docker-compose, и чувствую, что дальше будет minicube...

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

Но vagrant потребует больше памяти на хосте, что критично, если в разработке-тестировании-ревью часто бывает несколько веток одновременно. Также, если внутрь вагрантовской виртуалки не удастся запихнуть одновременно несколько сервисов нужных версий (например, mysql-сервер конфликтанёт с mysql-клиентами), то придётся изобретать Vagrantfile на несколько машин - и они соответствено отхавают памяти каждая. docker-compose в этом отношении более удобен, т.к. достаточно указать только используемые сервисы, а настраивать их окружение не нужно.

Но есть момент, что vagrant удобнее для небольших несложных окружений. Если есть возможность легко организовать внутри виртуалки vagrant окружение , похожее на прод (например, скопировать Vagrantfile из подобных проектов на github), то можно для начала остановиться на нём. C vagrant, например, удобнее, что можно выполнить vagrant provision или vagrant ssh в любом месте проекта. Для docker-compose подобную функциональность придётся написать в скрипте-обёртке.

Если у вас в проде не используется docker, и окружение в vagrant похоже на прод, то вариант с vagrant ещё и «нагляднее».

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

это правда

Большое вам спасибо за развернутый ответ.

А как же все тяготы, с которыми придется бороться/мириться, используя Винду?

например, какие?

Хочется узнать мнение профи и сразу пойти по правильному пути.

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

правильный путь 2: разрабатываешь часть какой-то системы, жрешь что дают, понадобится - будешь хоть в vi через SSH, хоть в notepad через RDP писать. никто под твое «ой а у меня докер, почему у вас не работает» подстраиваться не будет, как и под «ой, а я в докер не умею»

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

Это то, что пока успел узнать.

Обычно вопрос про vagrant/docker возникает, когда по пути 2 в проде уже понакодили такого, что каждую раскладку при фиксе того, что сломали при фиксе предыдущей раскладки всё ломается из-за того, что ожидания разраба относительно того, как это всё запущено на проде - не соответствует действительности.

Тогда тупо копируем зависимости с прода в provision скрипты для vagrant, либо в Dockerfile, и получаем эффект как от уборки козы из дома.

Первая фраза - это про что?

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

Про sql. Много жалуются

Докер есть смысл использовать если у вас и в проде докер.

Моя история успеха - пишу в удобной для меня среде, запускаю и тестирую в lxc, с версией ОС и библиотеками теми же что и в проде. IDE берет список библиотек и прочий обвес также из lxc, так что на моем локалхосте ничего нет из тех проектов, с которыми работаю, все это внутри контейнеров.

А вообще если вы хотите применить полученные ITT рекомендации на своей галере - лучше смотрите как ваши коллеги работают, тут в каждом конкретном случае могут быть свои подводные камни и свои рекомендации.

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

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

vagrant и контейнеризация, в т.ч. docker - это про изоляцию несовместимых зависимостей, про решение dependency hell и про облегчение установки рабочего окружения для новых сотрудников на проекте и для целей CI.

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

А для решения задачи изоляции зависимостей сперва изучить, как эти зависимости указываются в вашем языке (cpanfile, Gemfile и т.п.)

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

А что сможете сказать про типы дистрибутивов, которые именуются как контейнеры? Это как раз в среду виртуализации загоняется?

А новая какая-то Федора, где киллер фичей указали, что работать все в контейнерах из коробки будет. Ничего не путаю?

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

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

Прежде чем что-то юзать самому, курю форумы, литературу. Ну и говорю, что видел. Если это не так, то к лучшему.

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

тип дистрибутива целиком определяется задачей, решение которой возлагается на решение для виртуализации. Если это имитация прода, то и надо брать нужный базовый бокс/имидж. Если это для решения dependency hell в проде, то чел, который будет всё это продумывать и определит: официальные образы, какие-то специальные или самосборные; alpine, redhat, ubuntu, debian; с имитатором init или нормальные (без). Параметров слишком много, что бы здесь даже reference привести.

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

Ну, это не совсем верно. Для web-проектов вполне можно в среде VirtualBox работать - просто памяти должно быть достаточно на компе. Так что, тоже вариант для небольшой команды и соответствующего проекта. Давеча таким способом активно работали над проектом в течении 3-х лет - никаких проблем не возникало. Сейчас, правда, переключились на docker-контейнеры - но это, скорее, потому винду на Ubuntu заменили на девелоперских десктопах.

И если использовать docker, то нужно сразу учесть две «грабли»: правильно настроить в docker-е MTU (весьма актуально для DSL-подключений к инету) и порешать проблему настроек десктопного firewall-а.

Позвольте узнать, а чем была обусловлена миграция на другую ОС?

Позвольте узнать, а чем была обусловлена миграция на другую ОС?

А смысла особого нет держать на рабочем компе «родную» Windows, если вы не занимаетесь разработкой именно под Windows. На мой взгляд в плане комфорта работы программиста Linux - гораздо более приятная среда чем Windows. Особенно, если речь идет о веб-разработке - есть всё необходимое и даже больше ).
Единственное, нужно иметь уровень продвинутого пользователя Linux, чтобы десктоп и всякие сервисные процессы настроить как нужно. Ну и с некоторым железом могут возникнуть заморочки - иногда приходится параметры ядра и драйверов «ручками» подстраивать - тут еще не всё так гладко как в винде.

Ну я так полагаю, что linux необходим уже продвинутому веб разработчику?

Многие продвинутые разработчики тоже прекрасно живут на винде, и даже без виртуалок. Разумеется, если есть доступ к серверу, где можно тестировать код.

Сейчас большинство IDE имеют функцию «удалённого» редактирования кода, а часто ещё и удалённой отладки. Поэтому выбор операционки для десктопа сугубо личный.

Ну я так полагаю, что linux необходим уже продвинутому веб разработчику?

Это скорее дело вкуса - на чем удобнее, на том и работайте. VirtualBox везде есть - гонять другую операционку не проблема.
Я, например, когда перескочил c 32bit Windows 7 на 64bit Ubuntu 18.04 - так у меня сразу больше всяких полезных задачек стало помещаться в памяти без лишних тормозов. Своппинг более оптимально работает. Плюс, над Linux-ом у пользователя гораздо больше контроля, чем над Windows - особо это касается 10-ки :)

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

дает*

пхпшнику - не особо

Я не могу понять зачем среду воспроизводить досконально, ведь пишешь все равно под подобие виртуальной машины (java, DotNet или подобные)?

Не вижу никакого смысла воссоздавать что-либо на рабочей машине, для сборки и тестирования у меня жирные kvm-хосты (а теперь ещё и один под докер). Из 28 проектов в IDE локально у меня соберутся только 6, 2 из них частично, а 3 — вообще метапакеты, 3 запустятся и ещё один запустится (из тех, что не соберутся) только с DEBUG=1. Никак от этого не страдаю, всё очень удобно.

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

ТС-а вроде интересует не та среда, где текст набирают в текстовом редакторе - а та, где всё это дело тестируется ) Очевидно, что тестировать нужно в среде, аналогичной по конфигурации production-у. Ну а что вкладывать в понятие «аналогичная среда» - это уж зависит от конкретного проекта и используемого инструментария.

ТС-а вроде интересует не та среда, где текст набирают в текстовом редакторе - а та, где всё это дело тестируется

для сборки и тестирования у меня жирные kvm-хосты

Ты от новогодних попоек ещё не отошел что ли?

для сборки и тестирования у меня жирные kvm-хосты ...

Ну и какое отношение твоё выступление имеет к стартовому топику? Может конкретно тебе и не имеет смысла что-то воссоздавать на рабочем компе... )

Минусы очевидны (если тебе нет, то перечислю), а какие ты видишь в этом плюсы? Ты и есть предпочитаешь в сортире?

Для тестирования гораздо лучше подходят docker-compose и виртуалки со снапшотами.

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

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

И поаккуратнее с выражениями )