Как вы деплоите django приложение на сервер?

Привет, занимаюсь разработкой на django уже несколько лет. И до сих пор остается такое чувство, что я чего-то не знаю.

Задался недавно вопросом, а эффективно ли я деплою приложение на сервер?
Из арсенала, я использую fabric, vagrant.

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

Раньше у меня была практика постоянно поднимать новый сервер с 0, когда запускаю новую версию, но когда на одном сервере и база данных, и nginx и все, что относится к проекту, стало не очень прикольно синхронизировать постоянно.

Начал смотреть в сторону Docker'a или запускать все это добро на нескольких серверах, чтобы обновление было проще.
Я не использую Heroku, все запускаю на обычном выделенном сервере.

Напишите, как это делаете вы?
Какие используете тулзы, и какие видите минусы.

Если нужно больше деталей, я распишу свой подход.
  • Вопрос задан
  • 8353 просмотра
Пригласить эксперта
Ответы на вопрос 3
@artinnok
бекенд-программист
Исходя из вашего вопроса - "деплой" это разворот сервера с нуля до рабочего состояния.

Все зависит от количества деплоев:
1. Если вам достаточно задеплоить 1 сервак и забыть про него - проще поднять руками.
2. Если вы постоянно разворачиваете > 2 серваков - однозначно надо использовать автоматизированные инструменты.

Рассмотрим несколько популярных инструментов:
1. Ansible - на мой взгляд самый удобный инструмент для быстрой и удобноый работы с парком серверов, устанавливает весь софт и настройки на вашей VPS.
2. Docker - позволяет создать на вашей VPS еще одну виртуальную машину с заранее прописанными настройками и софтом, также его иногда используют для параллельного запуска нескольких БД / веб - серверов и т.д.
3. Также есть Puppet, Chef, Salt - ими не пользовался.

Рассмотрим другое толкование слова "деплой" - заливка изменений проекта на сервер, который находится в рабочем состоянии (т.е. имеется уже рабочий проект)

Тут все зависит от размеров проекта:
1. Если проект маленький / средний fabric вполне справляется с такими задачами, как подтянуть изменения из репозитория / собрать статику / перезагрузить nginx и т.д., но использовать его для разворота сервера - это тяжелая работа, которую проще делать с помощью других инструментов (описано выше). Сам я тоже использую fabric для обновления прода.
2. Если проект большой и приближается к хайлоаду - то надо использовать Continuous Integration, это позволит вам сделать автоматизированную выкладку кода на боевой сервер - к примеру, пушите коммиты в репозиторий на github, срабатывает хук, начинает работать Jenkins, идет прогон тестов, при успехе тестов обновляется прод.

Инструментов для CI много:
1. Jenkins - простой и бесплатный, с кучей расширений и прочих плюшек.
2. Travis-CI - бесплатный для опен сорс, платный для приватных проектов (69$ минимальный план).
3. Buildbot, tox - не использовал.

P.S. Я думаю, что понятие "деплой" - это выкладка изменений на боевой сервер. То, что делаете вы - создаете новый сервер, разворачиваете окружение - ближе к развороту сервера. Если так делается каждый раз, когда льются изменения на боевой сервак - надо менять workflow.
Ответ написан
@fesworkscience
Развернул django+uwsgi+nginx

На локали - все ветки и все push в мастер.
На VPS - git pull, makemigrations, migrate, collectstatic, touch uwsgi.ini

<30 сек
Ответ написан
dimonchik2013
@dimonchik2013
non progredi est regredi
ну Вы же понимаете, что универсального способа быть не может - все зависит от размеров проекта

главный вопрос, на который ищется ответ при деплое - "все ли работает", откуда два шага 1) обновление кода 2) тестирование

с (1) проблем нет: у нас Ansible, но, думаю, хоть fabric, хоть админ с командной строкой (хотя надо избегать такого из-за непередаваемости опыта) код обновит

а вот с (2) ... все проблемы: например, на тестах заглушка базы, и все отрабатывает, а на проде какой-нибудь новый автоинкремент/sequence и привет...

поэтому такой распределенный зоопарк продакшинов и тестировочных машин можно поддерживать только автоматически + сохраняя в репе те же конфиги Энсибла

плюс основная боль - на какие участки писать тесты, на "все где хочется" никогда не будет хватать времени

По-нормальному (по-взрослому), при выкатке на прод нужно использовать CI only, но даже там например, при распространенности JIRA, мы используем не Bamboo (Бамбу тоже, но эпизодически), а Jenkins - с ним банально больше умеющих тестировщиков, т.е. не так просто люди осваивают новые инструменты

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

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

Поэтому единственное, что полезное для Вас из этого топика - рекомендация использовать Ansible

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

Войдите, чтобы написать ответ

Похожие вопросы