Джанго и многоступенчатые серверы - PullRequest
10 голосов
/ 09 октября 2011

Я работаю с клиентом, который требует многоэтапной настройки сервера: сервер разработки, сервер стадии и рабочий / рабочий сервер.

Этап должен быть настолько стабильным, насколько это возможно, для тестирования всех тех новых функций, которые мыразработайте на сервере разработки и в конце перенесите это на действующий сервер.

Мы используем git и github для управления версиями.Я использую Ubuntu Server Edition в качестве ОС.

Проблема в том, что я никогда не работал в таком многоступенчатом плане сервера.Какое программное обеспечение / проекты вы бы порекомендовали сделать для правильной обработки такой настройки, особенно развертывания и перемещения новой функции, разработанной на сцену, а затем на работающий сервер?

Ответы [ 3 ]

7 голосов
/ 09 октября 2011

Мы используем два разных метода перемещения кода из среды в среду. Первый - использовать ветки и триггеры с нашей системой контроля версий (в нашем случае, mercurial, хотя вы можете сделать то же самое с git). Другой способ - использовать fabric, библиотеку python для выполнения шелл-кода на нескольких серверах.

Используя управление исходным кодом, вы можете иметь несколько основных веток, например production development staging. Скажем, вы хотите переместить новую функцию в постановку. Я объясню в терминах mercurial, но вы можете перенести команды на git, и все должно быть в порядке.

hg update staging
hg merge my-new-feature
hg commit -m 'my-new-feature > staging'
hg push

Затем ваш сервер удаленного управления исходным кодом передает на все ваши веб-серверы с помощью триггера. Триггер на каждом веб-сервере затем выполнит обновление и перезагрузит веб-сервер.

Чтобы перейти от постановки к производству, это так же просто.

hg update production
hg merge staging
hg commit -m 'staging > production'
hg push

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

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

4 голосов
/ 18 октября 2011

Для git есть хорошая модель ветвления (например, она также используется самим github).Вы можете легко применить эту модель ветвления, используя git-flow , который является расширением git, которое позволяет вам применять некоторые высокоуровневые операции репозитория, которые вписываются в эту модель.Есть также хороший блог об этом.

Я не знаю, что именно вы хотите автоматизировать в вашем рабочем процессе развертывания, но если вы примените модель, упомянутую выше, большая часть правильной обработки версийделается git.

Чтобы добавить к этому дальнейшую автоматическую обработку, fabric - простой, но отличный инструмент, и вы найдете множество руководств по его использованию (также в сочетании с git).

Для обработки зависимостей Python использование virtualenv и pip , безусловно, очень хороший путь.

Если вам нужно что-то более сложное,например.для обработки более одного экземпляра django на одном компьютере и для обработки системных зависимостей и т. д. checkout puppet или chef .

2 голосов
/ 09 октября 2011

Попробуйте Gondor.io или Ep.io, они оба позволяют легко (gondor особенно выделяется в этой области) иметь два + экземпляра с очень похожим кодом из VCS - и перемещать данные вперед и назад. (если вам нужно приглашение, спросите в IRC, но если я вспомню, они оба открыты)

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