Введение
Django — широко известный и один из наиболее развитых фреймворков для веб-разработки. Django написан на Python и, следовательно, для работы с ним потребуется установленный интерпретатор Python. Это не представляет никаких проблем, если мы работаем в среде Linux. Однако события принимают совсем другой оборот, если приходится заниматься разработкой на Python под Windows.
Для Windows есть готовые сборки Python, среди которых стоит отметить Enthought Python, Anaconda Python, PythonXY.
Есть и более простые пути.
Основной их недостаток по сравнению со «стандартным» Python в Linux — ограниченность набора библиотек, доступных для установки. В частности, в них не Django, и для его установки приходится совершать некие не совсем очевидные действия.
Один из возможных вариантов решения проблемы — установка виртуальной машины с Linux на борту. Работа с виртуальной машиной, несмотря на простоту ее установки и настройки, привносит ряд неудобств.
Так, виртуальная машина может оказаться довольно требовательной к ресурсам компьютера и временами работать медленно, создавая дискомфорт разработчику. Особенно сильно это раздражает, если торможение начинается в самый напряженный момент работы (а именно тогда это чаще всего и происходит!). Кроме того, даже на очень хорошем железе такое IDE, как PyCharm, работает в режиме далеком от того, который принято считать комфортным.
Повысить быстродействие можно за счет установки только необходимых пакетов, отсутствия оконного менеджера и тому подобных проблем. Т. е., необходимо правильно сконфигурировать виртуальную машину. И в этом деле на помощь приходит Vagrant — утилита для создания полностью готовых рабочих окружений на основе виртуальных машин (VirtualBox, VmWare Player/Workstation). Vagrant не только устанавливает виртуальную машину, но и позволяет с легкостью создавать новые, используя текущую конфигурацию пользователя.
В следующем разделе рассматривается установка и настройка рабочего окружения Vagrant для использования его в качестве удаленного Python интерпретатора для проектов PyCharm.
Работа с Vagrant в Windows
Установка Vagrant и загрузка окружения
Установка Vagrant выполняется очень просто. Все, что необходимо, — скачать установщик с сайта и запустить его. Кроме того, для работы Vagrant требуется установить одну из виртуальных машин VirtualBox или VMware.
После того, как Vagrant установлен, мы переходим к созданию рабочего окружения. Основа его построения — «коробка» Vagrant (box). »Коробка» Vagrant представляет собой файл с расширением box. Этот файл есть не что иное, как архив tar, возможно сжатый с помощью gzip. Внутри архива хранятся образ виртуальной машины и файлы, необходимые для ее корректного запуска.
На официальном сайте Vagrant есть значительное число готовых «коробок» с различными версиями Linux и установленным ПО. Их список можно посмотреть на VagrantCloud.
Еще больше готовых окружений доступно на www.vagrantbox.es.
Для наших целей вполне подойдет стандартная версия Ubuntu — hashicorp/precise64 с предустановленными Chef и Puppet (которые нам, к слову сказать, не понадобятся) из официального репозитория. Перед тем как устанавливать окружение, создадим директорию, где будет храниться файл с конфигурацией для него. Назовем ее Vagrant. Переходим в эту директорию и выполняем в консоли:
\Vagrant> vagrant init hashicorp/precise64
После этого в директории появится файл Vagrantfile, в котором содержится описание конфигурации данного окружения. Например, строчка config.vm.box = «hashicorp/precise64» определяет имя нашего окружения. Теперь все готово к тому, чтобы приступить к запуску окружения. Выполним
\Vagrant> vagrant up
и увидим сообщение о загрузке соответствующей «коробки». Т. к. это — первый запуск данного окружения, перед стартом его надо скачать из репозитория на локальный диск. Следует заметить, что в приведенном выше примере аргумент команды init — имя окружения — совпадает с таковым на сайте Vagrant. Это соответствие необязательно. Так, можно было бы сконфигурировать данное окружение (его версию без Chef и Puppet) и таким образом:
\Vagrant> vagrant init precise64
http://cloud-images.ubuntu.com/vagrant/precise/current/... .box
Второй аргумент init, как несложно заметить, представляет собой URL «коробки». Отметим также, что имена окружений, например, использованные выше hashicorp/precise64, precise64, фактически нужны для удобной ориентации среди установленных окружений, а сам Vagrant использует уникальные идентификаторы для запуска требуемого окружения (их значение хранится в файле action_set_name). Файлы рабочих окружений хранятся по умолчанию в директории ~/.vagrant.d}, где «~» в Windows — директория C:\Users\your_login\.
После того как мы выполнили vagrant up и дождались загрузки окружения, оно готово к использованию, в чем можно убедиться, проверив его статус:
\Vagrant> vagrant status
Для завершения работы окружения используется команда
\Vagrant> vagrant halt
Все установленные окружения Vagrnat можно просмотреть с помощью vagrant box list или непосредственно в VirtualBox (VMware).
Virtualbox с установленными виртуальными машинами Vagrant.
В заключение этого раздела отметим, что окружение Vagrant может быть добавлено с помощью команды vagrant box add. Подробнее о ней и о других консольных командах Vagrant можно прочитать на странице с официальной документацией.
Подключение к окружению Vagrant
При старте окружения (vagrant up) в папке .vagrant.d автоматически создается ключ insecure_private_key для подключения к окружению по протоколу ssh. Для использования протокола ssh в Windows нам потребуются программы PuTTY и PuTTYgen (для конвертирования ключа в формат, который PuTTY понимает). Запускаем PuTTYgen, открываем insecure_private_key и видим сообщение, что ключ был успешно импортирован. Теперь можно сохранить его в формате ppk как private key.
Из соображений удобства ключ можно сохранить в папку с файлом Vagrantfile для данного окружения. Теперь указываем PuTTY, какой ключ использовать, и подключаемся через порт 2222 (номер порта отображается при выполнении vagrant up). По умолчанию для подключения используется имя (login) — vagrant.
Если подключение прошло удачно, мы окажемся в консоли нашего Vagrant-окружения, откуда можно устанавливать библиотеки Python или системные приложения.
Сохранение ключа в PuTTYgen.
Настройка параметров соединения PuTTY.
Теперь, когда рабочие окружения скачаны и запущены, все готово к установке Python и собственно Django. Хорошая практика — использование виртуальных окружений для работы с Python (и не только с ним). В этом случае риск конфликтов с уже установленными в системе версиями интерпретатора и прочего ПО сводится к минимуму и появляется возможность одновременной работы с разными версиями интерпретатора Python, Django или любого другого пакета.
Для установки виртуального окружения выполняем в консоли Vagrant:
vagrant@vagrant sudo apt-get install python-virtualenv
После завершения установки создаем новое виртуальное окружение
vagrant@vagrant virtualenv venv
активируем его
vagrant@vagrant source /home/vagrant/venv/bin/activate
Теперь пришло время установить Django:
(venv)vagrant@vagrant pip install django
Можно указать версию пакета, которую мы хотим установить:
(venv)vagrant@vagrant pip install django==1.4
Django установлен, но осталась одна небольшая задача: научить PyCharm работать с интерпретатором Python, установленным в окружении Vagrant. Как это сделать, разбирается в следующем разделе.
Настройка PyCharm
Запустим PyCharm и создадим новый Django-проект. По умолчанию он создается в папке ~/PycharmProjects/. Пусть это будет проект Test. Далее в домашней директории рабочего окружения Vagrant создадим папку PycharmProjects (совпадение имен случайно и выбрано из соображений удобства).
Переходим в меню настроек проекта: File->Settings->Project Interpeter. Здесь добавляем новый интерпретатор: указываем его адрес (127.0.0.1), номер порта (2222), имя пользователя (vagrant), путь к интерпретатору /home/vagrant/venv/bin/python и, наконец, указываем путь к файлу с ключом для ssh.
Теперь необходимо настроить синхронизацию локальной папки с проектами и аналогичной папки в окружении Vagrant. Открываем для редактирования файл Vagrant и раскомментируем в нем строку с config.vm.synced_folder, исправляя ее на config.vm.synced_folder C:/Users/adolgikh/PycharmProjects, /home/vagrant/PycharmProjects. Теперь локальные файлы будут синхронизироваться с окружением, в котором установлен интерпретатор. Перезапускаем Vagrant
$ vagrant reload
и видим, что наша папка с проектом Test была успешно добавлена в папку с проектами в удаленном рабочем окружении.
Чтобы текущие изменения, сделанные по ходу работы над проектом, сразу отправлялись в удаленную среду, необходимо сделать дополнительные настройки в проекте Pycharm. Заходим в меню Run->Edit Configuration и корректируем Path Mapping так, как это показано на скриншоте.
Упоминания заслуживает возможность запуска ssh-консоли в Pycharm. Она запускается из меню Tools и подключается по ssh к окружению, которое указано в настройках удаленного интерпретатора. Таким образом, нам нет необходимости использовать PuTTY с корректно настроенным проектом в Pycharm.
Настройка Path Mapping в Pycharm
Заключение
Несомненно, Vagrant хорош не только тем, что позволяет существенно повысить удобство Python-разработки в Windows. Устанавливая Vagrant, мы получаем возможность создавать, конфигурировать и сохранять полностью функциональные рабочие окружения. Более того, мы можем создавать конфигурации, где одновременно работают несколько Vagrant окружений с различными конфигурациями.
Таким образом, появляется возможность достаточно точно смоделировать предполагаемое рабочее окружение, используемое в production. Одним словом, Vagrant представляет собой еще один ценный инструмент в руках разработчика, в дальнейшем мы постараемся осветить и другие аспекты работы с ним.
Комментарии (36)
lybin
09.08.2015 19:44Vagrant не только для разработки под windows удобен, он по сути всего лишь автоматизирует и упрощает процесс.
avk1651
10.08.2015 14:21А еще Vagrant создает среду, независимую операционки «носителя». У нас в команде есть и маки, линуксы, но проблемы с окружением в вагранте решаются везде одинаково. Это чертовски удобно.
greg_fat
09.08.2015 19:50Я конечно не спец по винде, но для линукса есть возможность пробрасывать папку из гостя в хост машину. Может и для винды такое есть?
lybin
09.08.2015 19:55Есть, но работает крайне медленно и в линуксе.
greg_fat
09.08.2015 20:00Не думаю, что скорость критична гонять py файлы туда-сюда.
lybin
09.08.2015 20:24Скажу так, что я сталкивался, что как раз через sharedfolders, как вы указали ниже, проект ужасно лагает. Да и не только там py там и статика и многое другое может быть. Можете набрать в гугле запрос: virtualbox sharedfolders slow, что проблемой страдают многие.
grafmishurov
10.08.2015 09:52У меня хост — Линукс, ВМ — тоже Линукс (KVM). Редактирую файлы на гостевой. Для синхронизации файлов я использую шелл-скрипт, использующий inotify-tools, который при каждом изменении файла на гостевой машине запускает rsync по ssh, работает мгновенно. Для Windows есть наверняка какие-то вотчеры, которые могут по изменению файлов какой-то код запускать, BAT-файлы какие-нибудь можно написать для автоматизации.
До того, когда перешел полностью на Линукс и консольный Vim в разработке, использовал MacOS и PyCharm, в PyCharm были настройки что-то типа Creating a Remote Server Configuration, Customizing Upload/Download, там можно было по FTP, SFTP конфигурировать синхронизацию. Работало, насколько я помню, быстро. Был Suse в VMWare Player/Workstation — точно так же, через PyCharm люди, работавшие в Windows, синхронизацию настраивали. Еще наш техдир в VMWare виртуальный HDD не разбивал на несколько маленьких файлов, а использовал один большой, говорил, что так быстрее.
NFS пробовал использовать для других задач, сложно сказать что-то определенное, помню только, что по вай-фаю медленно большие файлы передавались, для разработки возможно подойдет, т.к. требования для передачи данных другие.
Не знаю, насколько это может пригодится в Vagrant, я так понимаю, у них там много своих скриптов для удобства. Возможно у них самих есть какие-то готовые решения.
js605451
09.08.2015 20:42-1Не очень понял статью. Почему нельзя просто полноценную виртуалку с любимым линуксом поднять, поставить на неё всё что нужно, включая PyCharm, развернуть на весь экран и дальше работать без всяких извращений? Я может задачу вашу не понял — зачем PyCharm включать на одной машине, а Python — на другой?
lybin
09.08.2015 20:59+1Потому что PyCharm в виртуалке это и есть извращение не?) Виртуалка нужна, чтобы поднять изолированное окружение, с необходимым дистрибутивом, пакетами, а не среду разработки, иксы на сервере в большинтсве случаев не к чему, а если 5 проектов, в каждом по пючарму? А если один, но надо проверить в 5 сборках…
js605451
09.08.2015 22:09+4Потому что PyCharm в виртуалке это и есть извращение не?)
Нет. Вы кажется наделяете виртуалки какими-то неизвестными мне свойствами. На современных процессорах производительность виртуалки и физической машины практически не отличается. По крайней мере на глаз это отличить невозможно.
Виртуалка нужна, чтобы поднять изолированное окружение, с необходимым дистрибутивом, пакетами,
С этой частью утверждения полностью согласен: виртуалки очень круто помогают с изоляцией.
а не среду разработки, иксы на сервере в большинтсве случаев не к чему, а если 5 проектов, в каждом по пючарму? А если один, но надо проверить в 5 сборках…
Почему плохо ставить на виртуалку среду разработки? Откуда взялся сервер, иксами которого вы недовольны? :-)
Дисклеймер: последние лет 7 активно использую виртуалки именно для девелопмента — ставлю всё что нужно для очередного проекта и работаю. При этом нет проблем сохранить на несколько месяцев виртуалку с предыдущим проектом, если вдруг понадобится помочь.lybin
09.08.2015 22:271. Это же избыточно, имхо. 2. Pycharm и его зависимости никак не относятся к проекту, а что если PyCharm потребуется вот какая-нибудь версия бибилиотеки одна, а проекту нужна другая версия. Одна из причин почему нынешний проект развернул под виртуалкой, хотя некоторые коллеги линуксоиды прям в своей системе, по той причине, что у меня ролинг релиз дистрибутив, и проекту требует совершенно иные версии пакетов(по старее) нежели среде разработки. Сложно придумать пример, но вот, например, захотели последнюю версию PyCharm, а проект работает под 14.04 убунтой, а последнему PyCharm например ява новее нужна, а в проекте завязано на версии, которая в 14.04.
lybin
09.08.2015 22:37Продолжу мысль, тут два варианта или обновлять яву, подключать там репозитории дополнительные, либо довольствоваться PyCharm постарее. Если первый вариант, подшаманили там, чтобы можно было работать, делаете фичи, потом выливается на 14.04 в jenkins на тестирование например и оказывается, что проект не работает, из-за того что в среде в которой производилась разработка были изменены какие то версии бибилотек и вот по ошибке заюзали фичу с более новой либы, которой нет в старой или вообще поломана совместимость между версиями.
lybin
09.08.2015 22:53Т.е. от сюда какая мысль у меня, здесь Удобство разработчика(вам вот удобно так) VS приближенные условия к боевым. Изоляция от того на чем пишет тот или иной разработчик, это не должно касаться проекта и его работоспособности. Под изоляцией я подразумевал не только изоляцию от других проектов и хост системы, а как раз что окружение приближенно к боевым и нет необходимости обновлять или ставить какую либо бибилиотеку из-за того что моей среде разработки это надо или смотрелке диффов например. Но это на более менее большие проекты критично.
Merlen_Gross
09.08.2015 22:00Я даже не знаю, что должно произойти, чтобы я начал использовать Windows для работы. Ведь все эти действия имеют конечной целью сделать среду разработки *nix-like. Так зачем тратить время, чтобы сделать Windows таковой?
Чтобы в танки потом поиграть, наверное.js605451
09.08.2015 22:10Приходите вы на новую работу, а там корпоративный стандарт — Windows.
Arseny_Info
10.08.2015 08:28+1Если в компании используется одна ОС для всех, то это уже дурной звоночек.
Toshiro
09.08.2015 23:11В частности, в них не Django, и для его установки приходится совершать некие не совсем очевидные действия.
Впервые об этом узнал из этого поста. Пару лет работаю с питоном и джангой на виндах, никогда никаких проблем не было. Все ставится из консоли почти так же как в никсы и просто работает.
boo_v2
10.08.2015 09:12Лично у меня из под винды были только проблемы с виртуальными окружениями(из под линукса обычно за 2 команды все разворачивается и настраивается), как-то не получилось настроить нормально. А так в Pycharm выбирал нужное виртуальное окружение и вполне комфортно работал.
Yngvie
10.08.2015 11:57У нас на проекте и так используется Vagrant и виртуалка для создания окружения с нужными версиями пакетов и т.д. На работе я выходит сидя под Ubuntu поднимаю виртуалку с еще одной Ubuntu и работаю в ней. Если вдруг надо поработать с ноутбука, то делаю то же самое с Windows-хоста.
При этом правда возникают проблемы с CRLF/LF и с ссылками закомиченными в репозиторий
vermus
11.08.2015 11:16В частности, в них не Django, и для его установки приходится совершать некие не совсем очевидные действия.
Это какие?
production.txt:
Django==1.8.3
Переключаемся на любой .py файл, жмем на install во всплывающем окне. Profit.
Единственная проблема например у меня, драйвер для постгреса, но он есть скомпилированный.
Вообще-то python создавался как кросс-платформенный язык, то есть вы сами нарушаете идеологию языка, ваш проект должен работать на любой платформе.
Не так много надо допилить для Джанго проекта, чтобы он работал как в винде, так и в линуксе.
Stas911
18.08.2015 21:28Vagrant — это же всего лишь надстройка над VM: в связи с этим не понял Вашу мысль в начале статьи, что типа «VM — тяжело, а vagrant — в самый раз».
bohdan4ik
А вы не сталкивались с крайне медленной работой файловой подсистемы? Мы пользуем django pipeline и страницы грузятся ну очень долго с ним. Я попробовал подключить каталог через SMB, получил 5х ускорение, но загрузка страниц по 10 секунд это тоже не очень приятно.
lybin
Использую NFS под линукс и помогло ускорить вот эта статья.
E_STRICT
Храните все файлы в гостевой системе.
Yngvie
Я пробовал работать таким образом — когда PyCharm начинает делать индексацию, то это очень затягивается. Очень напрягает когда надо несколько раз переключаться между разными ветками.
hudson
А если sources хранить локально, толкать их в Git и потом забирать (возможно через fabric/git hooks автоматически) в vagrant боксе?
Yngvie
Тогда обновление будет проходить только с коммитом, мне хотелось бы чаще.
Ниже предложили вариант со скриптом который смотрит за модификацией файлов и делает rsync. Я думаю это будет самый быстрый вариант.
По моему в каких то ИДЕ даже видел настройку заливать сразу файлы на sftp после сохранения. Можно и без доп скрипта значит.
Но я в итоге держу код на хосте, монтирую его в виртуалке вагрантом, и скорость вроде устраивает.
Yngvie
Вспомнил один нюанс — мы используем virtualenvwrapper, и поэтому на шаре только код проекта, а все пакеты через pip ставятся во внутреннюю память виртуалки. Мне кажется это дает приличный прирост в скорости.
OnYourLips
Плохой совет, тогда тормоза будут на стороне IDEA, а при копировании файлов по SFTP — десинхронизация при их изменении.
Лучше пусть страница вместо 0.1с будет секунду выполняться (по 10 секунд никогда не было у меня, работаю по данной схеме больше года, с разными фреймворками на PHP и Rails)
E_STRICT
Чем это лучше?
bohdan4ik
Проблема проявляется только при использовании django-pipeline. Оно внутри делает manage.py collectstatic, который проверяет (или копирует) много сотен статических файлов. С другой библиотекой (django-compressor) всё работает шустро как на локалке, но заказчику хотелось каких-то плюшек из django-pipeline (уже не помню чем конкретно аргументировали).
Что касается нашего проекта, то пока оставил как есть, ибо сейчас пилю только бекенд, а остальные разработчики запускают его вне виртуальных машин. Попробую потом посмотреть настройки vagrant, и, если оно может цеплять rsa ключ системы, имя пользователя и прочие — попробую перенести исходники вовнутрь.
К слову, сейчас PyCharm индексирует virtualenv через виртуалку и особых неудобств в работе нет (кроме, как выше заметили, первого запуска).