Технологический консалтинг и разработка ПО
87,64
рейтинг
9 августа 2015 в 16:40

Разработка → Vagrant, Python, Pycharm = (удобная, работа, Windows)



Введение

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 представляет собой еще один ценный инструмент в руках разработчика, в дальнейшем мы постараемся осветить и другие аспекты работы с ним.
Автор: @DataArt
DataArt
рейтинг 87,64
Технологический консалтинг и разработка ПО

Комментарии (38)

  • 0
    А вы не сталкивались с крайне медленной работой файловой подсистемы? Мы пользуем django pipeline и страницы грузятся ну очень долго с ним. Я попробовал подключить каталог через SMB, получил 5х ускорение, но загрузка страниц по 10 секунд это тоже не очень приятно.
    • 0
      Использую NFS под линукс и помогло ускорить вот эта статья.
      • 0
        Я пробовал работать таким образом — когда PyCharm начинает делать индексацию, то это очень затягивается. Очень напрягает когда надо несколько раз переключаться между разными ветками.
        • 0
          А если sources хранить локально, толкать их в Git и потом забирать (возможно через fabric/git hooks автоматически) в vagrant боксе?
          • 0
            Тогда обновление будет проходить только с коммитом, мне хотелось бы чаще.

            Ниже предложили вариант со скриптом который смотрит за модификацией файлов и делает rsync. Я думаю это будет самый быстрый вариант.

            По моему в каких то ИДЕ даже видел настройку заливать сразу файлы на sftp после сохранения. Можно и без доп скрипта значит.

            Но я в итоге держу код на хосте, монтирую его в виртуалке вагрантом, и скорость вроде устраивает.
            • 0
              Вспомнил один нюанс — мы используем virtualenvwrapper, и поэтому на шаре только код проекта, а все пакеты через pip ставятся во внутреннюю память виртуалки. Мне кажется это дает приличный прирост в скорости.
      • 0
        Плохой совет, тогда тормоза будут на стороне IDEA, а при копировании файлов по SFTP — десинхронизация при их изменении.
        Лучше пусть страница вместо 0.1с будет секунду выполняться (по 10 секунд никогда не было у меня, работаю по данной схеме больше года, с разными фреймворками на PHP и Rails)
        • 0
          тогда тормоза будут на стороне IDEA
          Не уверен на счет Windows, но в Линуксе это работает почти так же как с локальными дисками (синхронизация NFS/SSHFS). Несколько лет по такой схеме работаю с PhpStorm. При создании нового проекта (несколько тысяч файлов) первоначальная индексация может занимать несколько секунд, но потом работает почти мгновенно.

          Лучше пусть страница вместо 0.1с будет секунду выполняться
          Чем это лучше?
        • 0
          Проблема проявляется только при использовании django-pipeline. Оно внутри делает manage.py collectstatic, который проверяет (или копирует) много сотен статических файлов. С другой библиотекой (django-compressor) всё работает шустро как на локалке, но заказчику хотелось каких-то плюшек из django-pipeline (уже не помню чем конкретно аргументировали).

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

          К слову, сейчас PyCharm индексирует virtualenv через виртуалку и особых неудобств в работе нет (кроме, как выше заметили, первого запуска).
  • 0
    Vagrant не только для разработки под windows удобен, он по сути всего лишь автоматизирует и упрощает процесс.
    • 0
      А еще Vagrant создает среду, независимую операционки «носителя». У нас в команде есть и маки, линуксы, но проблемы с окружением в вагранте решаются везде одинаково. Это чертовски удобно.
  • 0
    Я конечно не спец по винде, но для линукса есть возможность пробрасывать папку из гостя в хост машину. Может и для винды такое есть?
    • 0
      Есть, но работает крайне медленно и в линуксе.
      • 0
        Не думаю, что скорость критична гонять py файлы туда-сюда.
        • 0
          Скажу так, что я сталкивался, что как раз через sharedfolders, как вы указали ниже, проект ужасно лагает. Да и не только там py там и статика и многое другое может быть. Можете набрать в гугле запрос: virtualbox sharedfolders slow, что проблемой страдают многие.
        • 0
          У меня хост — Линукс, ВМ — тоже Линукс (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, я так понимаю, у них там много своих скриптов для удобства. Возможно у них самих есть какие-то готовые решения.
    • 0
  • –1
    DataArt, а у вас идет разработка под windows? Почему? Видел ваши вакансии, интересно.
    • 0
      У нас под всем и под все практически, на самом деле. Разные предпочтения, разные проекты.
  • –1
    Не очень понял статью. Почему нельзя просто полноценную виртуалку с любимым линуксом поднять, поставить на неё всё что нужно, включая PyCharm, развернуть на весь экран и дальше работать без всяких извращений? Я может задачу вашу не понял — зачем PyCharm включать на одной машине, а Python — на другой?
    • +1
      Потому что PyCharm в виртуалке это и есть извращение не?) Виртуалка нужна, чтобы поднять изолированное окружение, с необходимым дистрибутивом, пакетами, а не среду разработки, иксы на сервере в большинтсве случаев не к чему, а если 5 проектов, в каждом по пючарму? А если один, но надо проверить в 5 сборках…
      • +4
        Потому что PyCharm в виртуалке это и есть извращение не?)

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

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

        С этой частью утверждения полностью согласен: виртуалки очень круто помогают с изоляцией.

        а не среду разработки, иксы на сервере в большинтсве случаев не к чему, а если 5 проектов, в каждом по пючарму? А если один, но надо проверить в 5 сборках…

        Почему плохо ставить на виртуалку среду разработки? Откуда взялся сервер, иксами которого вы недовольны? :-)

        Дисклеймер: последние лет 7 активно использую виртуалки именно для девелопмента — ставлю всё что нужно для очередного проекта и работаю. При этом нет проблем сохранить на несколько месяцев виртуалку с предыдущим проектом, если вдруг понадобится помочь.
        • 0
          1. Это же избыточно, имхо. 2. Pycharm и его зависимости никак не относятся к проекту, а что если PyCharm потребуется вот какая-нибудь версия бибилиотеки одна, а проекту нужна другая версия. Одна из причин почему нынешний проект развернул под виртуалкой, хотя некоторые коллеги линуксоиды прям в своей системе, по той причине, что у меня ролинг релиз дистрибутив, и проекту требует совершенно иные версии пакетов(по старее) нежели среде разработки. Сложно придумать пример, но вот, например, захотели последнюю версию PyCharm, а проект работает под 14.04 убунтой, а последнему PyCharm например ява новее нужна, а в проекте завязано на версии, которая в 14.04.
          • 0
            Продолжу мысль, тут два варианта или обновлять яву, подключать там репозитории дополнительные, либо довольствоваться PyCharm постарее. Если первый вариант, подшаманили там, чтобы можно было работать, делаете фичи, потом выливается на 14.04 в jenkins на тестирование например и оказывается, что проект не работает, из-за того что в среде в которой производилась разработка были изменены какие то версии бибилотек и вот по ошибке заюзали фичу с более новой либы, которой нет в старой или вообще поломана совместимость между версиями.
            • 0
              Т.е. от сюда какая мысль у меня, здесь Удобство разработчика(вам вот удобно так) VS приближенные условия к боевым. Изоляция от того на чем пишет тот или иной разработчик, это не должно касаться проекта и его работоспособности. Под изоляцией я подразумевал не только изоляцию от других проектов и хост системы, а как раз что окружение приближенно к боевым и нет необходимости обновлять или ставить какую либо бибилиотеку из-за того что моей среде разработки это надо или смотрелке диффов например. Но это на более менее большие проекты критично.
  • 0
    Я даже не знаю, что должно произойти, чтобы я начал использовать Windows для работы. Ведь все эти действия имеют конечной целью сделать среду разработки *nix-like. Так зачем тратить время, чтобы сделать Windows таковой? Чтобы в танки потом поиграть, наверное.
    • 0
      Приходите вы на новую работу, а там корпоративный стандарт — Windows.
      • +1
        Полный социальный пакет и страдания?
      • +1
        Если в компании используется одна ОС для всех, то это уже дурной звоночек.
  • 0
    В частности, в них не Django, и для его установки приходится совершать некие не совсем очевидные действия.

    Впервые об этом узнал из этого поста. Пару лет работаю с питоном и джангой на виндах, никогда никаких проблем не было. Все ставится из консоли почти так же как в никсы и просто работает.
  • 0
    Лично у меня из под винды были только проблемы с виртуальными окружениями(из под линукса обычно за 2 команды все разворачивается и настраивается), как-то не получилось настроить нормально. А так в Pycharm выбирал нужное виртуальное окружение и вполне комфортно работал.
  • 0
    У нас на проекте и так используется Vagrant и виртуалка для создания окружения с нужными версиями пакетов и т.д. На работе я выходит сидя под Ubuntu поднимаю виртуалку с еще одной Ubuntu и работаю в ней. Если вдруг надо поработать с ноутбука, то делаю то же самое с Windows-хоста.

    При этом правда возникают проблемы с CRLF/LF и с ссылками закомиченными в репозиторий
  • 0
    Ну еще я бы посоветовал вместо архаичного putty использовать xshell.
  • 0
    В частности, в них не Django, и для его установки приходится совершать некие не совсем очевидные действия.

    Это какие?

    production.txt:
    Django==1.8.3

    Переключаемся на любой .py файл, жмем на install во всплывающем окне. Profit.

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

    Вообще-то python создавался как кросс-платформенный язык, то есть вы сами нарушаете идеологию языка, ваш проект должен работать на любой платформе.

    Не так много надо допилить для Джанго проекта, чтобы он работал как в винде, так и в линуксе.
  • 0
    Vagrant — это же всего лишь надстройка над VM: в связи с этим не понял Вашу мысль в начале статьи, что типа «VM — тяжело, а vagrant — в самый раз».
  • 0
    Вопрос, настроил примерно такую связку. Но есть засада — сторонние приложения Pycharm ом распознаются (пути прописаны в интерпретаторе), даже открываются по ctrl+b через pycharm_helpers.
    НО их нет в дереве проекта в external libraries. Очень неудобно, даже можно сказать критично неудобно :(
    Может надо где-то, что- подкрутить?
    • 0
      Сам себе и отвечу. :) Remote libraries заработали после того, как я указал директорию с джанго проектом в дереве «Mark Directory As» -> «Sources root». Как это связано — непонятно, но факт остается фактом.

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

Самое читаемое Разработка