#django #amazon-s3 #amazon-ec2 #amazon-web-services
#django #amazon-s3 #amazon-ec2 #amazon-веб-сервисы
Вопрос:
На самом деле я никогда не работал в компании, которая развертывает приложение Django (с большой базой пользователей), и мне любопытно, каков наилучший способ сделать это.
Прямо сейчас я размещаю приложение Django на EC2. Код для приложения находится в моей учетной записи github. У меня есть nginx, обслуживающий статический контент, а за ним один сервер apache, на котором работает django mod_wsgi.
Я пытаюсь выяснить, какова наилучшая практика для «непрерывного развертывания». Прямо сейчас, после того как я добавил дополнительную функциональность, я делаю следующее на EC2:
1) git reset HEAD -жесткий
2) git pull
3) перезапустите apache
4) перезапустите nginx
У меня есть пользовательская логика в моем settings.py файл, чтобы, если я работаю на EC2, для debug было установлено значение False, а мои базы данных переключались с sqlite3 (разработка) на mysql (производство).
Кажется, сейчас у меня это работает, но мне интересно, что не так с этим процессом и как я мог бы его улучшить.
Спасибо
Ответ №1:
Я работал с системами, которые используют Fabric для развертывания на нескольких серверах
Комментарии:
1. 1 fabric делает логику развертывания повторяемой, версионной и упрощает ее
2. похоже, что fabric — это правильный путь. я проверю это в эти выходные. спасибо за вашу помощь, ребята (включая всех, кто указан ниже)
Ответ №2:
Я бывший ведущий разработчик в Texas Tribune, которая на 100% состоит из Django. Мы развернулись на EC2, используя RightScale. Я лично не писал сценарии развертывания, но это позволило нам очень, очень быстро вводить новые экземпляры в ротацию и масштабировать по требованию. это недешево, но, на мой взгляд, стоило каждого пенни.
Комментарии:
1. Спасибо. я также проверю это, хотя я ищу бесплатное решение, если это возможно
Ответ №3:
Я бы согласился с Джоном и сказал, что Fabric — это инструмент для удобной работы с подобными вещами. Вероятно, вы не хотите настраивать git на автоматическое развертывание с помощью перехвата после фиксации, но вы можете захотеть настроить команду fabric для локального запуска вашего набора тестов, а затем запустить его в производство, если он пройдет успешно.
Многие люди запускают отдельные файлы настроек разработки и производства, вместо того, чтобы иметь там пользовательскую логику для определения, находится ли она в производственной среде. Вы можете наследовать из унифицированного файла, а затем переопределить биты, которые отличаются между разработкой и производством. Затем вы запускаете сервер, используя производственный файл, а не полагаясь на единый унифицированный settings.py .
Если вы используете apache только для размещения приложения, вам может пригодиться более легкое решение. Использование fastcgi с nginx позволило бы вам полностью избавиться от накладных расходов apache. Есть также модуль wsgi для nginx, но я не знаю, готов ли он к производству на данный момент.
Комментарии:
1. В чем преимущество полного отказа от apache? Я мог бы предположить, что это может ускорить запросы, потому что они не будут перенаправляться на другой порт через nginx (возможно)? У меня сложилось впечатление, что apache — гораздо более зрелый продукт по сравнению с nginx, и именно поэтому люди продолжают им пользоваться?
2. Apache — более функциональный продукт, именно поэтому люди продолжают им пользоваться. Устранение ненужных слоев в вашем стеке — хороший способ повысить скорость, и параллельно nginx убивает apache для задач, которые он может выполнять. Настраиваемый пользователем .htaccess, вероятно, является наиболее распространенной причиной, по которой люди используют apache. Снижение использования памяти — еще одна причина для устранения apache.
3. Кроме того, если у вас в стеке уже есть nginx, я не совсем понимаю комментарий «зрелый продукт». Если nginx выйдет из строя, вряд ли apache вмешается и возьмет верх.
Ответ №4:
Есть еще один хороший способ, как с этим справиться. Для ami ubuntu / debian полезно управлять версиями и выполнять развертывание, упаковывая ваше приложение в .deb
Комментарии:
1. я использую ubuntu? я немного смущен преимуществами этого?
2. Я не уверен, что вы используете ubuntu или какие-то другие цели. Преимущество может заключаться в простом управлении кодом, вы можете управлять объединением параметров конфигурации, автоматически управлять зависимостями. Может запускать сценарии предварительной / последующей установки для обновления конфигураций / базы данных и т.д.
3. Это ужасная идея. Это просто не то, как люди развертывают проекты на Python и Django. Для миграции мы используем pip и virtualenv, а также south.
4. Я думаю, это зависит от проекта, во многих случаях это должно быть сделано как часть проекта.
5. @PaulMcMillan То, что «просто не так люди развертывают проекты Python и Django», не означает, что это ужасная идея. Элитарные взгляды, подобные этому, препятствуют прогрессу, потенциально продуктивному обсуждению и инновациям.