Какова лучшая практика для развертывания нового кода на сайте (электронной коммерции)?
На данный момент я остановил apache на +/- 10 секунд при переименовании директории public_html_new
в public_html
и старой в public_html_old
. Это создает короткое время простоя, прежде чем я снова запускаю Apache.
Тот же вопрос возникает, если с помощью Git вытащить новый репозиторий в директорию live. Можно ли вытащить репо, пока сайт активен? А как насчет того, если мне нужно скопировать БД?
Во время сжатия tar (резервное копирование) живого сайта я заметил, что в каталоге media произошли изменения. Это указывало на то, что файлы периодически меняются. И если эти изменения могут помешать, если Apache не остановлен во время развертывания.
Самый быстрый и простой способ - использовать каталог версий, такой как
и использовать текущую символическую ссылку в качестве html_root:
Этот метод прекрасно интегрируется в систему контроля версий (svn, git, mercurial, ...), так как вы можете извлекать ветки и теги, изменять символическую ссылку и перезагружать Apache. Время простоя при использовании этой техники минимально и позволяет очень легко выполнить откат .
Он также хорошо интегрируется с более сложной системой развертывания, такой как RPM-пакеты, или инфраструктурой управления изменениями конфигурации (chef, puppet и т. Д.).
источник
ln -snf
на исходную символическую ссылку, основная операция - этоunlink
иsymlink
. У пользователей есть шанс получить 404 во время обновления. Это не лучше, чем просто переименовать исходный каталог и переименовать новый на место (при условии, что вы не пересекаете файловые системы). См. Ответ выше с галочкой рядом с ним, которая решает эту проблему.Переименование каталогов без отключения 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.rename
python или чего-нибудь еще, что вызоветrename
системный вызов, не пытаясь быть умным.Что делать с базой данных, зависит от того, какую базу данных вы используете, и для чего вы ее используете. Вам нужно предоставить гораздо больше информации о базе данных, прежде чем мы сможем дать вам хороший ответ на эту часть вашего вопроса.
источник
mv
есть-T
опция, которая не позволяет ему следовать символической ссылке. Это позволит вам атомарно переименоватьpublic_html.new
болееpublic_html
, если предположить , как мягкие ссылки.Симлинки и mv - ваши друзья, однако, если вам действительно нужно, чтобы конечные пользователи не получали страницу с ошибкой при развертывании новой версии, у вас должен быть обратный прокси-сервер или балансировщик нагрузки, по крайней мере, перед двумя бэкэнд-серверами (apache в твоем случае).
Во время развертывания вам просто нужно останавливать по одному бэкэнду за раз, развертывать новый код, перезапускать его, а затем выполнять итерации оставшихся бэкэндов.
Конечные пользователи всегда будут перенаправлены на хороший сервер.
источник
Если вы регулярно вносите изменения в производственную систему, я бы позаботился о структурированном жизненном цикле. Хорошей практикой является Capistrano http://capistranorb.com/ . Это решение с открытым исходным кодом для развертывания программного обеспечения на одном или нескольких серверах на нескольких платформах и в разных конфигурациях.
Для Magento есть даже плагин: https://github.com/augustash/capistrano-ash/wiki/Magento-Example
Для одного сервера и практически бесшовных переходов я рекомендую использовать символические ссылки.
источник
То, как я это делаю, это фиксирует мои изменения из локальной среды разработки в онлайн-хранилище Git, таком как Github. Моя производственная среда запускается из удаленного репозитория, поэтому все, что мне нужно, это подключиться к серверу по ssh и запустить его,
git pull
чтобы отключить последние изменения. Не нужно останавливать ваш веб-сервер.Если в вашем проекте есть файлы, настройки и / или содержимое которых отличаются от локальной версии (например, файлы конфигурации и загрузка мультимедиа), вы можете использовать переменные среды и / или добавить эти файлы / каталоги в
.gitignore
файл, чтобы предотвратить синхронизацию с репозиторием.источник
Моя первая идея:
Хорошим решением было использовать rsync. Это изменило только действительно измененные файлы. Осторожно, косые черты в конце дорожек здесь важны.
Обычно apache не требует перезагрузки, это не мир Java. Он проверяет изменения каждого php-файла по запросу и автоматически перечитывает (и повторно токенизирует) изменения.
Git Pull были похожи эффективны, хотя это было немного сложнее для сценария. Конечно, это позволило широкий спектр различных возможностей обнаружения слияния / изменения.
Это решение будет беспрепятственно только в том случае, если нет действительно серьезных изменений - если в развертывании произошли большие изменения, небольшая опасность не может быть закрыта, потому что существует немалый интервал времени, когда код будет частично изменен и частично нет.
Если есть большие изменения, мое предложение было вашим первоначальным решением (два переименовать).
Вот немного хардкорное, но 100% атомное решение:
(1) сделайте альтернативное монтирование вашей файловой системы, где находится ваше magento:
(2) выполните
--bind
монтирование вашего public_html_new в public_html:С этого момента apache увидит ваше новое развертывание. Любое изменение 404 невозможно.
(3) выполнить синхронизацию с rsync, но в альтернативной точке монтирования):
(4) снять крепление
источник
public_html
находится в несогласованном состоянии, и вы не хотите использовать этот шанс.Перемещение / замена
http_public
папки может быть достигнуто с помощью простыхmv
илиln -s
команд или эквивалентных, пока ваш http-сервер продолжает работать. Вы можете сделать некоторые сценарии, чтобы значительно сократить время простоя, но тщательно проверяйте коды возврата ваших команд в сценарии, если вы автоматизируете процесс.Тем не менее, если вы хотите избежать простоя, ваше приложение также должно его поддерживать. Большинство приложений использует базу данных для постоянства. Использование версии N вашего приложения в сочетании с версией N + 1 (или наоборот) вашей модели данных может привести к поломке, если это не предусмотрено командой разработчиков.
По опыту, поддержание такой согласованности с помощью обновлений не подходит для большинства приложений. Правильное отключение, несмотря на время простоя, является хорошим способом избежать проблем с согласованностью.
источник