Как опытные веб-разработчики внедряют Django в производство на EC2?

Question

Я никогда не работал в компании, которая развертывает приложение Django (с большой базой пользователей), и мне интересно узнать, как лучше всего это сделать.

Сейчас я хостингДжанго приложение на EC2.Код для приложения находится в моей учетной записи GitHub.У меня есть nginx, обслуживающий статический контент, а за ним - единственный сервер Apache, на котором работает django + mod_wsgi.

Я пытаюсь выяснить, что лучше всего использовать для «непрерывного развертывания».Прямо сейчас, после добавления дополнительной функциональности, я делаю следующее на EC2:

1) git reset HEAD --hard

2) git pull

3) перезапустите apache

4) перезагрузите nginx

У меня есть собственная логика в моем файле settings.py, так что, если я работаю на EC2, для отладки устанавливается значение False и мои базы данных переключаются с sqlite3 (разработка)в mysql (производство).

Кажется, сейчас это работает для меня, но мне интересно, что не так с этим процессом и как я могу улучшить его.

Спасибо

Answer 1

Я работал с системами, которые используют Fabric для развертывания на нескольких серверах

Answer 2

Я бывший ведущий разработчик в Texas Tribune , что на 100% Django.Мы развернули в EC2, используя RightScale .Я лично не писал сценарии развертывания, но это позволило нам очень, очень быстро вводить новые экземпляры в ротацию и масштабировать по требованию.это не дешево, но, на мой взгляд, стоило каждой копейки.

Answer 3

Есть еще один хороший способ, как справиться с этим.Для Ubuntu / Debian Amis это хорошо для управления версиями и развертывания, упаковав ваше приложение в .deb

Answer 4

Я бы согласился с Джоном и сказал бы, что Ткань - это инструмент для комфортного выполнения подобных задач. Возможно, вы не хотите настраивать git для автоматического развертывания с помощью ловушки после фиксации, но вы можете настроить команду фабрики для локального запуска набора тестов, а затем перейти к работе, если она пройдет.

Многие люди запускают отдельные файлы настроек и производственных настроек, вместо того чтобы использовать собственную логику, чтобы определить, находится ли она в производственной среде. Вы можете унаследовать от объединенного файла, а затем переопределить биты, которые отличаются между dev и production. Затем вы запускаете сервер, используя рабочий файл, а не полагаясь на единый файл settings.py.

Если вы просто используете Apache для размещения приложения, вы можете воспользоваться более легким решением. Использование fastcgi с nginx позволит вам полностью избавиться от издержек apache. Есть также модуль wsgi для nginx, но я не знаю, готов ли он к этому моменту.