Блог

Настройка рабочей среды

Anton
0

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

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

Раньше, если мне надо было что-то использовать, к примеру, поднять проект на PostgreSQL, Redis и Node.js, я просто ставил все к себе на машину, настраивал и работал. Проблемы появлялись с приходом нового проекта с другим стеком технологий. Приходилось опять все ставить и настраивать, потом приходил еще проект, затем еще один, и еще... А когда надо было переключаться между проектами, так вообще хотелось пойти и утопиться, так как необходимо было помнить большое количество команд или постоянно перечитывать Readme файлы для запуска сервисов. Или же из-за смены версии что-то переставало работать, и приходилось тратить время на выявление проблем вместо того, чтобы заниматься необходимыми делами.

Все это порождало и другие проблемы. Через какое-то время мой компьютер был заполнен программами, большая часть из котороых использовалась редко, а некоторые — всего один раз. Программы не только занимали место на жёстком диске, но и висели в трее, а их процессы забивали ОЗУ и загружали процессор, это жутко бесило.

Года 3 назад я открыл для себя Vagrant и Ansible, эти инструменты упростили мою жизнь в разы. Я перестал устанавливать все на свой компьютер, вместо этого я просто описывал настройку рабочей среды Ansible скриптами и поднимал все на виртуальной машине через Vagrant.

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

Из всех команд, которые нужно было помнить, осталось всего две vagrant up и vagrant halt. Больше не нужно было вспоминать: “Какую базу использует проект: Mongo или PostgreSQL?”, не нужно было запускать отдельно каждый сервис в табах терминала. В идеале все сводилось к концепции: пришел утром на работу, запустил vagrant up, и волшебным образом поднялось все необходимое для работы с проектом, уходя вечером, запускал vagrant halt, и все само закрывалось и не висело в трее или еще где-нибудь.
Я увидел в этом подходе большие плюсы не только для себя, но и для команды. Мы перевели на Vagrant практически все имеющиеся проекты, а в корпоративном Gitlab создали базу bootstrap-проектов с различным набором технологий. Благодаря этому поднятие и настройка среды разработки занимали минимальное количество времени, а разработчики могли фокусироваться непосредственно на задачах, а не на установке зависимостей и плясках с бубном при настройке сервера.

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

Плюсов в работе с Vagrant было больше, чем минусов, но все же хотелось найти инструмент еще более гибкий, более быстрый. И такой инструмент мы нашли — это Docker. Я читал о нем и раньше, но пользоваться стали примерно год назад, когда появилось полноценное приложение под MacOS.

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

Docker — это user-space демон, который предоставляет удобный интерфейс работы с контейнерами, а Vagrant управляет виртуальными машинами, поэтому Docker в разы быстрей и легковесней. Он также позволяет быстро поднимать изолированные окружения, открывать порты, создавать свои образы, деплоить и многое другое.

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

0