Эта статья была написана мной уже давно — не менее полутора лет назад. Написана прежде всего для меня самого, ведь я не профессиональный программист, а лишь любитель, и мне просто необходимы справочники и пошаговые инструкции в жанре «How to…» . Кое что в статье может быть уже не актуально ни для меня, ни для людей. Однако общий подход к быстрому развертыванию приличного workflow разработки с одновременным использованием возможностей windows и linux всё ещё актуален.

При всех недостатках windows, есть у него один важный плюс: я к нему привык. А также я привык к программульке под названием Crunch!, где очень удобно работать с css-фреймворками, исходники которых написаны в less.

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

Установка гостевой ОС

Что нужно сделать, когда возникает необходимость в использовании двух операционных систем одновременно? Правильно, нужно одну из них водрузить на виртуальную машину. И добрые товарищи из Oracle снабдили нас бесплатнораспространяемой прогаммой VirtualBox, которая отлично справляется с этой ролью.

Итак, устанавливаем под windows свежую стабильную версию виртуалбокс, создаем виртуальную машину с настройками под debian64 (важно: в настройках сети нужно выставить тип подключения «Сетевой мост», иначе запущенный в гостевой ОС сервер нельзя будет увидеть из домашней ОС), и устанавливаем на машину этот самый debian64. Я, по наущению опытного в сисадминских делах тимлидера нашей сборной, для виртуальной машины использую консольную версию — то есть не устанавливаю «десктопные навороты» вообще. Кроме этого, настоятельно рекомендую не устанавливать web-сервер — по умолчанию устанавливается apache, а счастья в нем никакого нет для нас, будет только мешаться.

Клонирование репозитория

Я застал еще те времена, когда для запуска виндоус приходилось писать в консоли MS-DOS команду win, и все следующие 20 лет моё юзерское сознание развивалось вместе с развитием виндоус. Кроме этого, по роду занятий я долгое время был дизайнером полиграфии… В общем, я использую в обиходе много чего, что работает только под Windows или под MacOS. Вот и для системы контроля версий я использую SourceTree — надстройку над Git, представляющую его возможности в оконном виде. SourceTree тщательно изготовлен ребятами, поддерживающими общественный удаленный репозитарий Bitbacket.org, что гарантирует отсутствие проблем при одновременной работой с ними обоими.

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

Даже когда проект я начинаю с нуля, я все равно сначала создаю удаленный репозитарий на битбакет и клонирую его (ну и что, что пустой) в рабочую папку. Этот способ проще для установления связи локального и удаленного репозитариев.

Общая папка

Но конечно же радость наша будет не полной, пока с данными, с любовью расположенными в виндовой папке, не сможет полноценно общаться наша гостевая ОС.

Для виртуальной машины в VirtualBox подключаем общую папку (эту самую, с проектом), и говорим, что подключение это автоматическое, и доступ у машины к папке — полный. Запоминаем, какое у папки имя — это важно.

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

Во-первых, логинимся под рутом. Устанавливаем sudo:

aptitude install sudo

и добавляем своего пользователя в список судоеров:

sudo adduser username sudo

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

Во-вторых, создаем папку, в которую будет смонтирована общая папка, созданная под виндой:

mkdir /home/username/foldername
(или sudo mkdir /home/username/foldername, если уже успели перелогиниться под обычным пользователем)

В-третьих, открываем для редактирования файл fstab для автоматического монтирования общей папки при загрузке системы:

nano /etc/fstab
(sudo nano /etc/fstab)

Добавляем строчку:

sharename mountpoint vboxsf defaults 0 0

где sharename — имя общей папки (которое запоминали)
mountpoint — адрес только что созданной папки (/home/username/foldername)
vboxsf — тип файловой системы

Сохраняем изменения и перезагружаем гостевую ОС. После перезагрузки общая папка станет действительно общей, и данные в ней будут одни и те же и для windows, и для debian.

Настройка nginx

Одно из преимуществ линуксовых систем — установка необходимого программного обеспечения из пакетов. При этом при установке пакета строится дерево зависимостей (то есть список других пакетов, без которых устанавливаемый не будет работать), и устанавливая пакет вы можете быть на 100% уверены, что он установится и будет работать, либо не установится вообще (если вы не захотите разрешить ему установить зависимости). Правда здорово?

Чтобы установить nginx просто напишите команду

aptitude install nginx
(sudo aptitude install nginx)

Далее нужно настроить проксирование сервера разработки, чтобы проект, разрабатываемый в вашей виртуальной ОС, можно было смотреть через браузер домашней операционки. Кстати, сервер получит адрес локальной сети (мы же пробросили сетевой мост через виртуалбокс!), и просматривать разрабатываемый сайт можно будет с любого устройства, подключенного к локальной сети. Очень удобно для отладки.

Для этого редактируем файл default, опрашиваемый конфигом nginx:

nano /etc/nginx/sites-enabled/default
(sudo nano /etc/nginx/sites-enabled/default)

В самом начале будет такой текст:

 # You may add here your
 server {
 ...
 }
 # statements for each...

Впишите сюда свой сервер — просто исправьте эту запись, чтобы получилось следующее:

server {
        listen 80;
        location / {
                proxy_pass http://127.0.0.1:8000;
        }
}

Дальше ничего можно не трогать — все необходимое уже сделано. Сохраняйтесь и перечитывайте конфиг nginx:

nginx -s reload
(sudo nginx -s reload)

Осталось только узнать, по какому адресу будет отвечать внутри сети ваш сервер разработки. Для этого наберите команду:

ifconfig
(sudo ifconfig)

и найдите в ответе требуемый адрес в формате IPv4 — когда запустите сервер разработки, именно этот адрес вам нужно будет вбить в адресную строку браузера родительской ОС, чтобы увидеть результат.

Развертывание проекта

Для разработки на django нам обязательно нужно установить набор отверток для разработчика python-dev и альтернативный питоновский инсталлятор, существенно облегчающий жизнь, python-pip. Итак, пишем:

aptitude install python-pip python-dev
(sudo aptitude install python-pip python-dev)

Если клонированный вами из репозитария проект создавал хороший человек, а не какой-нибудь редиска, он наверняка создал специальный файлик со списком необходимых для развертывания проекта пакетов. Переходим в папку с проектом, смотрим наличие в нем файлика requirements.txt, и пишем команду:

pip install -r requirements.txt
(sudo pip install -r requirements.txt)

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

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

pip install django
(sudo pip install django)

Только не забудьте записать этот пакет в requirements, для чего зайдите в папку, куда клонировали репозитарий, и исполните команду:

pip freeze > requirements.txt
(sudo pip freeze > requirements.txt)

Если же вам не повезло, и проект создавал какой-то редиска, задумайтесь: а надо ли вам вообще связываться с таким проектом?

Есть еще небольшой нюанс с инициацией проекта при моем подходе к оформлению рабочего пространства. После того, как вы создадите проект при помощи команды django-admin.py startproject mysite, django создаст папку с названием проекта, в которую уложит служебные файлы и собственно папку с проектом под тем же названием. Получится излишняя вложенность. Однако первая папка является всего лишь оберткой, контейнером, и никак не участвует в функционировании проекта. А значит ее содержимое мы можем безболезненно перенести на 1 уровень выше, а саму папку удалить и избавиться таким образом от излишней вложенности.

Запуск сервера разработки

Войдите в консоли в папку с вашим проектом (в этой папке у вас должен находиться файл manage.py) и исполните команду:

python manage.py runserver

Если все было сделано правильно, вы увидите сообщение, что сервер запущен по адресу http://127.0.0.1:8000, а именно этот адрес nginx и проксирует в родительскую ОС под локальным сетевым адресом, выясненным нами при помощи команды ifconfig. Идем в родительскую ОС, вбиваем локальный сетевой адрес сервера разработки, и наслаждаемся успешно проделанной подготовкой к разработке сайта на django.

На этом все.