Структура и соглашения сервера Django

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

• Наличие системной учетной записи для каждого «сайта» может быть удобно, если сайты «принадлежат» разным людям — если вы веб-дизайнер или программист с несколькими клиентами, вам может быть полезно разделение.
• Если ваши сайты связаны между собой, например сайт форума, сайт блога и т. д., вам может быть полезна единая система развертывания (например, наша).
• для библиотек, если они размещены на авторитетных источниках (pypy, github и т. д.), вероятно, можно оставить их там и развернуть из них — если они находятся на хитрых хостах, которые работают или не работают, мы берем копию и помещаем их в папке / ThirdParty в нашем репозитории git.

FABRIC Fabric просто великолепен, если он настроен правильно для вас:

• У нас есть политика, которая означает, что никому никогда не нужно входить на сервер (что в основном верно — бывают случаи, когда мы хотим посмотреть необработанный файл журнала nginx, но это редкость).
• У нас есть структура, настроенная так, что есть отдельные функциональные блоки (restart_nginx, restart_uwsgi и т. д.), но также
• «бизнес»-функции более высокого уровня, которые запускают все маленькие блоки в правильном порядке — для обновления всех наших серверов мы просто набираем «fab -i secretkey live deploy» — live устанавливает настройки для живых серверов и развертывает ldeploys ( -i необязателен, если у вас правильно настроены ключи .ssh)
• У нас даже есть контрольный флаг, который, если используется живая настройка, будет спрашивать «вы уверены» перед выполнением развертывания.

Наш макет кода

Итак, наш базовый макет кода выглядит примерно так:

/         <-- folder containing readme file etc
/bin/     <-- folder containing nginx & uwsgi binaries (!)
/config/  <-- folder containing nginx config and pip list but also things like pep8 and pylint configs 
/fabric/  <-- folder containing fabric deployment
/logs/    <-- holding folder that nginx logs get written into (but not committed)
/src/     <-- actual source is in here!
/thirdparty/ <-- third party libs that we didn't trust the hosting of for pip

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

Как работает наше развертывание:

Весь наш исходный код размещен в частном репозитории Bitbucket (у нас много репозиториев и несколько пользователей, поэтому битбакет для нас лучше, чем github). У нас есть учетная запись пользователя для «серверов» с собственным ключом ssh для битбакета.

Развертывание в структуре выполняет следующие действия на каждом сервере:

• irc-бот анонсирует начало в irc-канале
• git тянуть
• pip deploy (из списка пипсов в нашем репозитории)
• синхронная база данных
• мигрировать на юг
• перезагрузка uwsgi
• сельдерей перезагрузка
• irc-бот объявляет о завершении в irc-канал
• начать тестирование доступности
• объявить результаты тестирования доступности (и опубликовать отчет в приватной вставке)

«Тест доступности» (например, модульный тест, но против реального сервера) — проверяет все веб-страницы и API в «тестовой» учетной записи, чтобы убедиться, что он возвращает нормальные данные, не влияя на статистику в реальном времени.

У нас также есть служба резервного копирования git, поэтому, если битбакет не работает, он изящно переключается на него, и у нас даже есть интеграция с jenkins, которая при фиксации в ветке «развертывание» вызывает выполнение развертывания.

Страшный момент

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