Как эффективно управлять несколькими установками веб-приложения?

Question

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

Моя компания имеет собственную CMS, которая в настоящее время установлена ​​на более чем 100 серверах. На данный момент мы используем взломанный подход на основе FTP в сочетании со сценариями обновления в определенных местах для обновления всех наших настроек CMS. Эффективное управление этими настройками становится все более трудным и рискованным, когда задействовано несколько пользовательских модулей.

• Каков наилучший способ обеспечения безопасности и актуальности нескольких настроек веб-приложения?
• Как вы делаете это?
• Существуют ли какие-либо конкретные советы относительно модульности приложений, чтобы обеспечить гибкость для наших клиентов, но при этом иметь возможность эффективно управлять несколькими "ветвями" приложения?

Некоторая контекстная информация: мы в основном разрабатываем на LAMP-стеке. Одним из основных факторов, который помогает нам продавать нашу CMS, является то, что мы можем подключить практически все, что хочет наш клиент. Это может очень от 10 до 10 000 строк пользовательского кода.

Большая часть пользовательской работы состоит из очень маленьких кусочков кода; Управление всеми этими небольшими кусочками кода в Subversion кажется мне довольно утомительным и неэффективным (поскольку мы предоставляем около 2 веб-сайтов в неделю, это приведет к лоту веток). Если я что-то упускаю из виду, я бы хотел услышать это от вас.

Заранее спасибо.

---

Сводка новостей: Прежде всего, спасибо за все ваши ответы. Все это действительно полезно.

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

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

Answer 1

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

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

Редактировать: Я почти уверен, что поддерживать все это в актуальном состоянии с системой распределенных версий будет гораздо менее утомительно, чем вы ожидаете: вы можете сохранить изменения, в которых вы уверены, что ' Он никогда не понадобится в других местах, и распределенный аспект означает, что каждое развернутое приложение фактически не зависит от других, и будет распространяться только то исправление, которое вы намереваетесь распространять.

Answer 2

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

На данный момент создание веток SVN может быть единственным решением, которое поможет вам сохранить здоровье. В вашем текущем состоянии почти неизбежно, что вы допустите ошибку и испортите сайт клиента. По крайней мере, с филиалами у вас гарантированно будет стабильная база кода для каждого клиента. Единственная проблема с ветвями SVN - если вы перемещаете или переименовываете файл в ветке, невозможно объединить это изменение обратно в ствол (вам придется сделать это вручную).

Удачи!

РЕДАКТИРОВАТЬ: Пример хорошо разработанного приложения, использующего все принципы, которые я изложил выше, см. Magento E-Commerce . Magento - самое мощное, расширяемое и простое в настройке веб-приложение, с которым я когда-либо работал.

Answer 3

Не уверен, что кто-то сказал это, здесь много длинных ответов, и я не прочитал их все.

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

Затем вы можете использовать его ствол (или определенную ветку / тег, если хотите) в качестве svn: external в каждом проекте, который в этом нуждается. Таким образом, любые обновления, которые вы вносите в CMS, могут быть зафиксированы обратно в ее репозиторий и будут добавляться в другие проекты по мере их обновления svn (или внешним является svn: switch 'ed).

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

IE:

project
 project/cms <-- cms here, via svn external
 project/lib <-- custom bits here
 project/www <-- folder to point apache/iis at

(в случае необходимости вы можете иметь cms и lib в папке www)

Это позволит вам ветвиться / отмечать каждый проект по вашему желанию. Вы также можете переключать расположение svn: external для каждой ветви / тега.

С точки зрения получения изменений, я бы посоветовал вам немедленно избавиться от ftp и использовать rsync или svn checkout / exports. Оба работают хорошо, выбор за вами.

У меня больше всего опыта работы с маршрутом rsync, rsyncing экспорта svn на сервер. Если вы пойдете по этому пути, напишите несколько сценариев оболочки, и вы можете создать тестовый сценарий оболочки, который покажет вам файлы, которые он будет загружать без загрузки, также используя флаг -n. Я обычно использую пару сценариев для каждой среды - один тест, а другой - для этого.

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

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

Answer 4

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

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

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

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

Answer 5

Вот что я делаю ...

Путь включения для конкретного клиента

• Общий, общий код находится в shared / current_version / lib /
• Код для конкретного сайта находится в clients / foo.com / lib
• Путь включения задается для включения из клиентов / foo.com / lib , а затем share / lib
• Все дело в системе контроля версий

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

Псевдоним, общие файлы

Моя конфигурация виртуального хоста будет содержать строку типа

Alias /common <path>/shared/current_version/public_html/common

Что позволяет использовать общие элементы интерфейса, значки и т. Д. Для всех проектов

Пометить общий код с каждым выпуском сайта

После каждого выпуска сайта я помечаю общий код, создавая ветку для эффективного замораживания этого момента времени. Это позволяет мне развертывать / shared / version_xyz / на работающем сервере. Затем я могу заставить виртуальный хост использовать определенную версию общих файлов или оставить указатель на current_version, если я хочу, чтобы он брал последние обновления.

Answer 6

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

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

В идеале обновления - это несколько ключевых шагов.

1. a) Резервное копирование, чтобы вы могли отступить. Вы должны быть в состоянии отступить все обновление в любое время. Так, это означает создание локального архива приложения и базы данных первый.

   b) Обновление процесса мониторинга - домашний телефон системы CMS будет искать новую сборку.

   c) Расписание обновления по доступности - Скорее всего, вы не хотите, чтобы обновление запускалось в тот момент, когда оно доступно. Это означает, что вам придется создать какой-нибудь cron / agent для автоматического обновления системы в середине ночи. Вы также можете учитывать требования клиентов к обновлению в выходные или в определенные дни. Вы также можете постепенно обновлять свои обновления, чтобы не обновлять 1000 клиентов за 1 день и не получить техническую поддержку. Пошаговое развертывание какого-либо рода может быть полезным для вас.

   d) Добавить режим обслуживания для обновления сайта - Перевести сайт в режим обслуживания.

   e) извлечение SVN или загружаемые пакеты - в идеале вы можете развернуть его через svn checkout, а если нет, настройте свой сервер для доставки сгенерированных svn пакетов в архив, который можно развернуть на клиентских сайтах.

   f) Развертывание сценариев БД - Резервное копирование баз данных, их обновление, заполнение

   г) Обновление кода сайта - Вся эта работа за один шаг.

   h) Запустите на нем несколько тестов. Если в ваш код встроены самопроверки, было бы идеально.

Answer 7

Вы смотрели на Drupal? Нет, не для развертывания и замены того, что у вас есть, а для того, чтобы увидеть, как они обрабатывают настройки и специфичные для сайта модули?

По сути, есть папка "sites", в которой есть каталог для каждого сайта, который вы размещаете. Внутри каждой папки есть отдельный файл settings.php, который позволяет вам указать другую базу данных. Наконец, вы можете (опционально) иметь папки "themes" и "modules" на сайтах.

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

Answer 8

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

Так что, если вы думаете, что Subversion будет утомительной, у вас есть четкое представление о том, какими будут болевые точки ... Лично я бы не рекомендовал Subversion для этого, поскольку он не очень хорош в управлении и отслеживании. ветви. Хотя предложение Бенлумли использовать внешние компоненты для вашего основного программного обеспечения является хорошим, оно не работает, если вам нужно настроить основной код для своих клиентских сайтов.

Посмотрите на Git для контроля версий, он создан для ветвления и работает быстро.

Проверьте Capistrano для управления вашими развертываниями. Это скрипт ruby, часто используемый с Rails, но его можно использовать для всех видов управления файлами на удаленных серверах, даже на сайтах без ruby. Он может доставлять контент на удаленный конец через различные стратегии, включая ftp, scp, rsync, а также автоматически извлекать последнюю версию из вашего хранилища. К приятным возможностям, которые он предоставляет, относятся перехватчики обратных вызовов для каждого шага процесса развертывания (например, чтобы вы могли скопировать файлы конфигурации для своего сайта, которые могут отсутствовать в управлении версиями), а также система журналов выпуска - с помощью символических ссылок - чтобы вы могли может быстро вернуться к предыдущему выпуску в случае проблем.

Я бы порекомендовал файл конфигурации со списком ветвей и их размещением, а затем запустил его с помощью скрипта, который проверяет каждую ветку по очереди и загружает последние изменения. Это может быть cron'd, чтобы делать ночные обновления автоматически.

Answer 9

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

С другой стороны, наличие филиалов для каждого клиента выглядит для меня как экспоненциальный рост. И как бы вы «узнали», в каких областях вы что-то сделали, и не забудьте «внести» изменения и во все остальные ветви. Это выглядит довольно некрасиво для меня.

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

Answer 10

Если вы используете стек LAMP, я определенно превратил бы файлы решений в пакет вашего дистрибутива и использовал бы его для распространения изменений. Я рекомендую в этом отношении Redhat / Fedora из-за RPM, и это то, что у меня есть опыт. В любом случае вы также можете использовать любой дистрибутив на основе Debian.

Некоторое время назад я создал LAMP-решение для управления серверами ISP. У них было несколько серверов, чтобы заботиться о веб-хостинге, и мне нужен был способ развернуть изменения моего менеджера, потому что каждая машина была автономной и имела онлайн-менеджера. Я сделал RPM-пакет, содержащий файлы решения (в основном php) и несколько сценариев развертывания, которые запускались с RPM.

Для автоматического обновления у нас был свой собственный репозиторий RPM на каждом сервере в yum.conf. Я установил задание crontab для ежедневного обновления серверов последними RPM из этого доверенного хранилища.

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