Развертывание кода на нескольких интерфейсных серверах

У нас есть ситуация, когда у нас есть несколько серверов с балансировкой нагрузки, указывающих на общую базу данных.

В нормальном режиме это работает нормально и дает избыточность, масштабируемость и т. Д.

Тем не менее, мы считаем, что развертывание будет немного хлопотно.

Мы широко используем функции и пытаемся автоматизировать развертывание. Развертывание на данный момент не очень надежно.

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

1. Обновить файлы

2. Восстановить функции (которые будут управлять зависимостями, изменениями настроек и т. Д.)

Существуют ли рекомендации по развертыванию на нескольких серверах, не приводя их в несогласованное состояние?

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

Вероятно, вам стоит взглянуть на Aegir , которая на сегодняшний день является самой гибкой и мощной системой управления / развертывания сайтов в Drupal. Он может управлять «платформами», охватывающими несколько веб-заголовков или «кластеров», а также множеством других конфигураций.

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

Вы также можете получить хорошую поддержку на канале #aegir IRC.

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

В нашей компании мы поддерживаем МНОГО сайтов Drupal, наша текущая настройка выглядит примерно так:

• Кодовая база каждого сайта имеет собственное git-репо
• Новые функции, которые вряд ли будут достаточно стабильными для следующего выпуска, получат свою собственную ветку функций в git

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

В нашей компании мы делаем специальное пакетирование сайтов для развертывания с помощью специальной команды drush - « Drush Debian Packaging ».

Drush Debian Packaging предоставляет команду Drush для создания пакетов Debian для сайтов Drupal в качестве средства развертывания сайтов Drupal на серверах Debian или Ubuntu.

Drush Debian Packaging использует систему ловушек Drupal для создания пакета Debian, который наилучшим образом соответствует потребностям ваших сайтов. Особенности включают в себя:

• Автоматическая настройка виртуального хоста для веб-серверов Apache2 и Nginx
• Настройка Cron в /etc/cron.d
• Автоматическое развертывание кода с разделением на разделы для сайтов / default / files
• Автоматическая настройка через инструмент настроек dpkg debconf
• Автоматизированный процесс развертывания
• пользовательский обработчик Git VCS для сборки пакетов из Git

Что это значит?

Чтобы создать релиз:

cd /path/to/drupal-root
drush dh-make

Чтобы развернуть выпуск, сначала отправьте SCP-файл .deb на все веб-серверы в кластере. Затем на всех веб-серверах запустите (вы можете использовать пакет Linux cssh, чтобы ввести команду для всех серверов в ферме одновременно):

sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb

На одном веб-сервере запустите:

cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron

Выполнено

Конечно, откатить это теперь тривиально с точки зрения кодовой базы, просто установите предыдущую версию .deb на все веб-серверы и откатите базу данных.

С удовольствием отвечу на любые вопросы по этому поводу

Какая часть процесса развертывания является рутинной / ненадежной?

Если это проблема «сервера обновлений A, то B / несогласованность», как насчет размещения страницы обслуживания на время ваших попыток? Страница обслуживания вверх, обновить код на обеих веб-страницах, запустить update.php на одной из них, страницу обслуживания вниз. Это довольно легко в сценарии.

Другой вариант: в зависимости от типа сайта, который вы запускаете, вы можете создать «режим только для чтения», который отключит всех пользователей от сети и отключит вход / регистрацию. Клонируйте свою БД во вторую БД в том же самом блоке БД, клонируйте свой внешний интерфейс в новый доку-кор, сделайте там свои обновления, затем вставьте символическую ссылку Apache в новый документооборот внешнего интерфейса. Рабочий процесс что-то вроде:

1. Режим только для чтения включен
2. ВЫБЕРИТЕ current_db INTO new_db
3. cp -R current_docroot new_docroot
4. new.yourdomain.com ==> / new_docroot
5. обновить код в new_docroot
6. update.php
7. symlink / new_docroot ==> current_docroot
8. Режим только для чтения отключен.

Это будет зависеть от изменений, которые вы делаете, как предлагает Entendu. Какую долю обновлений кода можно запускать без ошибок, если база данных еще не обновлена? Для всего, что не зависит от обновлений базы данных (и, возможно, вы можете немного изменить процесс разработки, чтобы сделать это более распространенным), на самом деле ничего особенного делать не приходится. Я предполагаю, что вы хотите выполнять развертывание с минимальным временем простоя, в противном случае это просто потребует некоторых основных операций синхронизации. В этом случае всегда будет какое-то время с нежелательными эффектами (даже если сайт просто находится в режиме только для чтения), но я думаю, что большую часть времени он может быть довольно небольшим.

Вы можете выполнить базовую оптимизацию, например, заранее установить «новый» каталог на каждом сервере, а затем переключить их все, чтобы одновременно указывать на новый каталог (возможно, используя символические ссылки, как в ответе Entendu), чтобы вы могли получить все серверы переключаются на новые файлы в течение 5-10 секунд.

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

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

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

Aegir полезен для управления сетью сайтов. Я использовал его для развертывания и управления более 2000 сайтов для одного клиента.

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

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

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

С точки зрения вашей стратегии развертывания, вы должны иметь Drush в качестве первого инструмента в вашем списке. С помощью drush вы сможете автоматизировать этапы развертывания. Вам следует подумать о добавлении Jenkins в смесь, чтобы можно было отслеживать задания развертывания и определять шаблоны в случае неудачи. Capistrano может быть полезен для автоматизации этапов развертывания. Если вы все делаете правильно, вы можете сделать это так, чтобы ваши пользователи даже не знали, что вы сделали развертывание.