Развертывание кода на нескольких серверах переднего плана
У нас сложилась ситуация, когда у нас есть несколько серверов с балансировкой нагрузки, указывающих на общую базу данных.
В обычном режиме это прекрасно работает и обеспечивает избыточность, масштабируемость и т.д.
Однако мы считаем, что развертывание - это немного тяжелая работа.
Мы широко используем функции и пытаемся автоматизировать развертывание. Развертывание на данный момент не очень надежно.
В упрощенной форме сценарий развертывания для каждого сервера имеет два этапы
Обновление Файлов
Отменить функции (которые будут управлять зависимостями, изменениями настроек и т.Д)
Существуют ли какие-либо рекомендации по развертыванию на нескольких серверах, не приводя их в несогласованное состояние?
Насколько я вижу, если вы развернете шаги 1 и 2 на сервере A, это приведет к поломке сервера B, если вы попробуете выполнить первый шаг на обоих серверах, прежде чем перейти к шагу 2, они оба будут некоторое время сломаны.
5 answers
Вероятно, вам следует изучить Aegir, которая на сегодняшний день является самой гибкой и мощной системой управления/развертывания сайтов Drupal. Он способен управлять "платформами", охватывающими несколько веб-головок или "кластеров", а также множеством других конфигураций.
Я бы предложил ознакомиться с их документацией сообщества , которая в целом довольно хороша, а также прочитать отличный обзор и вступительную статью mig5 и некоторые из его другие статьи, такие как эта.
Вы также можете получить хорошую поддержку в IRC-канале #aegir.
Это будет небольшое изменение рабочего процесса, которое определенно может занять некоторое время, чтобы вы пришли в себя, но как только вы окажетесь там, вы не будете оглядываться назад.
В нашей компании мы поддерживаем МНОЖЕСТВО сайтов Drupal, наша текущая настройка выглядит примерно так:
- Кодовая база каждого сайта имеет собственное репозиторий git
- Новые функции, которые вряд ли будут достаточно стабильны для следующего выпуска, получат собственную ветвь функций в git
Вышесказанное, я бы сказал, довольно распространено для большинства сайтов Drupal.
Что мы делаем особенного в нашей компании, так это пакуем сайты debian для развертывания с помощью пользовательской команды drush - 'Drush Debian Упаковка'.
Пакет Debian Drush предоставляет команду Drush для создания пакетов Debian сайтов Drupal в качестве средства развертывания сайтов Drupal на серверах Debian или Ubuntu.
Упаковка Debian Drush использует систему Drupal hooks для создания пакета Debian, который наилучшим образом соответствует потребностям ваших сайтов. Особенности включают в себя:
- Автоматическая настройка виртуального хоста для веб-серверов Apache2 и Nginx
- Настройка Cron в /etc/cron.d
- Автоматическое развертывание кода с разделение разделов для сайтов/по умолчанию/файлов
- Автоматическая настройка с помощью инструмента настройки dpkg debconf
- Автоматизированный процесс развертывания
- пользовательский обработчик Git VCS для сборки пакетов из Git
Что это значит?
Для создания выпуска:
cd /path/to/drupal-root
drush dh-make
Чтобы развернуть выпуск, сначала запустите файл .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 с новым корневым каталогом. Рабочий процесс выглядит примерно так:
- Режим только для чтения включен
- ВЫБЕРИТЕ current_db В new_db
- cp-R текущий корень_докрута новый корень_докрута
- new.yourdomain.com ==>/новый корневой каталог
- обновить код в new_docroot
- update.php
- символическая ссылка /новый корневой каталог ==> текущий корневой каталог
- Режим только для чтения выключен.
Это будет зависеть от изменений, которые вы вносите, как предполагает Entendu. Какая доля обновлений кода может выполняться без ошибок, если база данных еще не обновлена? Для всего, что не зависит от обновлений базы данных (и, возможно, вы можете немного изменить процесс разработки, чтобы сделать это более распространенным), на самом деле ничего особенного делать не нужно. Я предполагаю, что вы хотите выполнять развертывания с минимальным временем простоя, в противном случае для этого потребовались бы лишь некоторые базовые операции синхронизации. В этом случае есть всегда будет какое-то время с нежелательными эффектами (даже если сайт просто находится в режиме только для чтения), но я бы подумал, что большую часть времени он может быть довольно небольшим.
Вы можете выполнить базовую оптимизацию, например, заранее настроить "новый" каталог на каждом сервере, а затем переключить их все, чтобы указать на новый каталог одновременно (возможно, используя символические ссылки, как в ответе Entendu), чтобы вы могли переключить все серверы на новые файлы в течение 5-10 секунд.
Что оставляет проблему обновления базы данных. Если они должны выполняться только с одного сервера, вы можете перевести остальные в режим обслуживания или настроить балансировщик нагрузки, чтобы не использовать их, пока это происходит. Конечно, если это невозможно сделать, пока пользователи активны на сайте, вам просто нужно, чтобы все было в режиме обслуживания, но для простых обновлений это может быть то, что вы можете сделать примерно за 30 секунд или меньше.
Возможно, стоит иметь разные сценарии развертывания для различные типы изменений, поэтому вы можете выполнить минимальный необходимый процесс, будь то простое копирование файлов, небольшое обновление базы данных или крупное изменение базы данных.
Если вы можете оптимизировать обновления файлов и баз данных и посмотреть, есть ли простые изменения, которые вы можете внести в способ разработки, это может приблизить вас, но я не знаю, является ли что-то из этого новым для вас:)
Aegir полезен для управления сетью сайтов. Я использовал его для развертывания и управления более чем 2000 сайтами для одного клиента.
Ваш вопрос предполагает, что вы хотите управлять одним сайтом с несколькими веб-заголовками. Если это так, то Эгир может оказаться для вас менее полезным. Вместо этого я бы предложил вам рассмотреть возможность использования файловой системы, поддерживающей сетевое взаимодействие. Это не только гарантирует синхронизацию вашего кода, но и означает, что ваши загрузки доступны на всех узлах.
Исторически люди имели используется NFS, которая позволяет совместно использовать файловую систему одного сервера с другими узлами. К сожалению, это приводит к единственной точке отказа, потому что, если сервер NFS блокируется или умирает, ваш сайт не может быть обслужен.
Если вы готовы немного снизить производительность ввода-вывода в пользу более надежного сервера, я бы рекомендовал GlusterFS. Я использовал в нескольких производственных средах. Это не идеально, но это лучше, чем NFS. Gluster позволяет веб-заголовку всегда читать локально, и записи затем реплицируются на другие узлы.
С точки зрения вашей стратегии развертывания у вас должен быть drush в качестве первого инструмента в вашем списке. С помощью drush вы сможете автоматизировать этапы развертывания. Вам следует рассмотреть возможность добавления Дженкинса в набор, чтобы вы могли отслеживать свои задания по развертыванию и выявлять закономерности в случае сбоя. Capistrano может быть полезен для автоматизации шагов, связанных с развертыванием. Если вы все делаете правильно, вы можете сделать это так ваши пользователи даже не знают, что вы выполнили развертывание.