Comments 7
Мне кажется, что лечить отсутствие квалификации Vagrant'om это некоторый оверхед. Тем более, что контейнер тоже настроил, а потом просто подвязываешь к нему IDE.
Но с Vagrant мы так работали тоже, но тогда не было Docker:) Ну или, если точнее, он не был так популярен
Я рекомендую связку tilt + docker for desktop + vscode для локального окружения.
* врубаем kubernetes engine в докере
* используем helm_resource для деплоя зависимостей (куча готовых чартов для postgres/redis/ и тд)
* docker_build для образа своего софта
* свой софт деплоится через тот же helm_resource или через k8s_yaml
* дополнительно можно ingress_nginx задеплоить и выставлять наружу (на локалхост) свои сервисы через .7f000001.nip.io. Если хочется потестить с честным SSL - get.localhost.localdirect
Сложная часть обычно c удалённым дебагом. Проще всего с go, с python придётся повозиться, для poetry проектов надо debugpy в зависимости подключать и запускать через poetry run python -m debugpy --listen 0.0.0.0:5679 src/main.py arg1 arg2 arg3
Плюсы по сравнению с вагрантом:
* можно в куб и докер
* можно организовать hot reload с локального кода, а не разрабатывать внутри вм
* можно локально сервисы заавтоматизировать таким же образом
* меньше оверхед иногда. Иногда наоборот :)
* не надо ансибл
Виртуальная машина Vagrant
<занудство-on>
Vagrant не является вирутальной машиной. Врутальные машины создает Oracle VritualBox, а Vagrant это просто обёртка-менеджер, которая позволяет легко их создавать, конфигурировать и уничтожать.
<занудство-off>
В качестве альтернативы виртуальной машине можно использовать docker-контейнеры. Но есть нюанс, что для работы с контейнерами требуется соответствующая квалификация.
Прошу обратить внимание, что для выполнения всех действий в статье также требуется альтернативная квалификация (только в Vagrant + Ansible, как минимум). А особенно - что перечень описанных действий, на мой взгляд, существенно длиннее, чем если поднять локальный стенд на docker + что-нибудь вспомогательное, например, docker-compose, плюс расшарить общий проект с ветками где-нибудь в github/gilab/bitbucket. И это совсем не сложно, стек всем известен и хорошо отлажен. А вот о vagrant не могу сказать, чтобы он был столь же распространенным и активно использовался бы. ИМХО - как раз для него небольшое самообучение потребуется.
Безусловно, автор проделал хорошую работу и подробно описал интересный кейс. Возможно, также, что в каких-то случаях, действительно, возможны объективные причины, которые КАТЕГОРИЧЕСКИ требуют использования vagrant vs docker, где он имеет какие-то явные и реальные преимущества. Только я, например, таких преимуществ особо не нашел, может быть, кто-то их действительно знает? - Тогда прошу их описать, хотя бы в комментариях.
Здесь важен контекст. Речь идёт о группах, в которых были выпускники курсов. Я использовал два варианта - на докере и на вагранте. Вагрант требовал от меня больше знаний и объяснений на входе в проект. Потом вопросов "как это мне запустить?" было минимум, потому что участники работали с привычным интерфейсом (по другому я это объяснить не могу). С докером было наоборот. Сначала приходилось объяснять что-такое докер, а затем попутно решать вопросы "а у меня слетело, а я перезапустил" и т.д.
Виртуальная машина Vagrant для разработки в команде