Развертывание нового кода в реальном времени

Какова лучшая практика для развертывания нового кода на сайте (электронной коммерции)?

На данный момент я остановил apache на +/- 10 секунд при переименовании директории public_html_newв public_htmlи старой в public_html_old. Это создает короткое время простоя, прежде чем я снова запускаю Apache.

Тот же вопрос возникает, если с помощью Git вытащить новый репозиторий в директорию live. Можно ли вытащить репо, пока сайт активен? А как насчет того, если мне нужно скопировать БД?

Во время сжатия tar (резервное копирование) живого сайта я заметил, что в каталоге media произошли изменения. Это указывало на то, что файлы периодически меняются. И если эти изменения могут помешать, если Apache не остановлен во время развертывания.

Использование балансировщика нагрузки - хорошая идея. Если сайт достаточно важен, чтобы беспокоиться о нескольких секундах простоя, то достаточно важно беспокоиться о отказоустойчивости.

Кроме того, если это в системе UNIX, вы можете приостановить работу Apache во время переименования (или обновления символической ссылки и т. Д.):

killall -STOP httpd  # Pause all httpd processes
mv public_html public_html_orig
mv public_html_new public_html
killall -CONT httpd  # Resume all httpd processes

Это не позволит Apache принимать новые запросы во время переименования. Если вы предпочитаете символические ссылки или какой-либо другой подход, можно использовать ту же идею:

killall -STOP httpd  # Pause all httpd processes
rm /var/www/html
ln -s /var/www/version/03 /var/www/html
killall -CONT httpd  # Resume all httpd processes

Обратите внимание, что любые ожидающие соединения или пакеты будут поставлены в очередь в ОС. Для чрезвычайно загруженного сайта рассмотрите возможность настройки ListenBacklog, если это соответствует вашему рабочему типу httpd, и проверьте настройки ОС, связанные с журналом ожидания прослушивания TCP.

Вы также можете изменить DocumentRoot в httpd.conf и выполнить аккуратный перезапуск ( apachectl graceful). Недостатком здесь является повышенный риск ошибок, так как вам также придется обновить любую Directoryконфигурацию.

Самый быстрый и простой способ - использовать каталог версий, такой как

/var/www/version/01
/var/www/version/02

и использовать текущую символическую ссылку в качестве html_root:

/var/www/html -> /var/www/version/02

Этот метод прекрасно интегрируется в систему контроля версий (svn, git, mercurial, ...), так как вы можете извлекать ветки и теги, изменять символическую ссылку и перезагружать Apache. Время простоя при использовании этой техники минимально и позволяет очень легко выполнить откат .

Он также хорошо интегрируется с более сложной системой развертывания, такой как RPM-пакеты, или инфраструктурой управления изменениями конфигурации (chef, puppet и т. Д.).

Переименование каталогов без отключения Apache также должно работать. Это значительно сократит окно. mv public_html public_html_old && mv public_html_new public_htmlдолжно закончиться в доли секунды.

Пара недостатков состоит в том, что этот подход даст 404любой запрос, который все еще может произойти во время окна. И если вы запустите указанную выше команду без public_html_newкаталога, она не будет работать, и вам будет предоставлен сайт 404для каждого запроса.

Делать это атомарно с каталогами не поддерживается. Но вы можете сделать это с помощью символических ссылок. Вместо того, чтобы иметь каталог с именем public_html, имейте каталог с именем public_html.version-numberи символическую ссылку, public_htmlуказывающую на этот каталог. Теперь вы можете создать каталог с именем public_html.new-version-numberи новую символическую ссылку public_html.new.

Затем вы можете переименовать public_html.newв public_htmlпереключиться атомарно. Обратите внимание, что mvэто «слишком умно», чтобы выполнить это переименование, но это можно сделать с помощью os.renamepython или чего-нибудь еще, что вызовет renameсистемный вызов, не пытаясь быть умным.

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

Симлинки и mv - ваши друзья, однако, если вам действительно нужно, чтобы конечные пользователи не получали страницу с ошибкой при развертывании новой версии, у вас должен быть обратный прокси-сервер или балансировщик нагрузки, по крайней мере, перед двумя бэкэнд-серверами (apache в твоем случае).

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

Конечные пользователи всегда будут перенаправлены на хороший сервер.

Если вы регулярно вносите изменения в производственную систему, я бы позаботился о структурированном жизненном цикле. Хорошей практикой является Capistrano http://capistranorb.com/ . Это решение с открытым исходным кодом для развертывания программного обеспечения на одном или нескольких серверах на нескольких платформах и в разных конфигурациях.

Для Magento есть даже плагин: https://github.com/augustash/capistrano-ash/wiki/Magento-Example

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

То, как я это делаю, это фиксирует мои изменения из локальной среды разработки в онлайн-хранилище Git, таком как Github. Моя производственная среда запускается из удаленного репозитория, поэтому все, что мне нужно, это подключиться к серверу по ssh и запустить его, git pullчтобы отключить последние изменения. Не нужно останавливать ваш веб-сервер.

Если в вашем проекте есть файлы, настройки и / или содержимое которых отличаются от локальной версии (например, файлы конфигурации и загрузка мультимедиа), вы можете использовать переменные среды и / или добавить эти файлы / каталоги в .gitignoreфайл, чтобы предотвратить синхронизацию с репозиторием.

Моя первая идея:

# deploy into public_html_new, and then:
rsync -vaH --delete public_html_new/ public_html/

Хорошим решением было использовать rsync. Это изменило только действительно измененные файлы. Осторожно, косые черты в конце дорожек здесь важны.

Обычно apache не требует перезагрузки, это не мир Java. Он проверяет изменения каждого php-файла по запросу и автоматически перечитывает (и повторно токенизирует) изменения.

Git Pull были похожи эффективны, хотя это было немного сложнее для сценария. Конечно, это позволило широкий спектр различных возможностей обнаружения слияния / изменения.

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

Если есть большие изменения, мое предложение было вашим первоначальным решением (два переименовать).

Вот немного хардкорное, но 100% атомное решение:

(1) сделайте альтернативное монтирование вашей файловой системы, где находится ваше magento:

mount /dev/sdXY /mnt/tmp

(2) выполните --bindмонтирование вашего public_html_new в public_html:

mount --bind /path/to/public_html_new /path/to/public_html

С этого момента apache увидит ваше новое развертывание. Любое изменение 404 невозможно.

(3) выполнить синхронизацию с rsync, но в альтернативной точке монтирования):

rsync -vaH --delete /mnt/tmp/path/to/public_html_new/ /mnt/tmp/path/to/public_html/

(4) снять крепление

umount /path/to/public_html

Перемещение / замена http_publicпапки может быть достигнуто с помощью простых mvили ln -sкоманд или эквивалентных, пока ваш http-сервер продолжает работать. Вы можете сделать некоторые сценарии, чтобы значительно сократить время простоя, но тщательно проверяйте коды возврата ваших команд в сценарии, если вы автоматизируете процесс.

Тем не менее, если вы хотите избежать простоя, ваше приложение также должно его поддерживать. Большинство приложений использует базу данных для постоянства. Использование версии N вашего приложения в сочетании с версией N + 1 (или наоборот) вашей модели данных может привести к поломке, если это не предусмотрено командой разработчиков.

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