Как эффективно управлять несколькими установками веб-приложения?
По моему опыту, одна из самых больших проблем, с которыми мы сталкиваемся в процессе нашей веб-разработки, заключается в обновлении и обеспечении безопасности различных настроек на разных серверах.
У моей компании есть собственная CMS, которая в настоящее время установлена на более чем 100 серверах. На данный момент мы используем хакерский подход на основе FTP в сочетании со сценариями обновления в определенных местах для обновления всех наших настроек CMS. Эффективное управление этими установками становится все более трудным и рискованным, когда задействовано несколько пользовательских модулей.
- Каков наилучший способ обеспечить безопасность и актуальность нескольких настроек веб-приложения?
- Как вы это делаете?
- Есть ли какие-либо конкретные советы относительно модульности приложений, чтобы сохранить гибкость по отношению к нашим клиентам, но при этом иметь возможность эффективно управлять несколькими "ветвями" приложения?
Некоторая контекстуальная информация: мы в основном разрабатываем на стеке ЛАМП. Один из основных факторы, которые помогают нам продавать нашу CMS, заключаются в том, что мы можем подключать практически все, что хочет наш клиент. Это может быть от 10 до 10 000 строк пользовательского кода.
Большая часть пользовательской работы состоит из очень маленьких фрагментов кода; управление всеми этими небольшими фрагментами кода в Subversion кажется мне довольно утомительным и неэффективным (поскольку мы доставляем около 2 веб-сайтов каждую неделю, это приведет к множеству ветвей).
Если есть что-то, что я упускаю из виду, я бы с удовольствием услышу это от тебя.
Заранее благодарю.
Раундап: прежде всего, спасибо за все ваши ответы. Все это действительно полезно.
Я, скорее всего, буду использовать подход на основе SVN, который делает решение бенламли наиболее близким к тому, что я буду использовать. Поскольку ответ на этот вопрос может отличаться в других случаях использования, я приму ответ с наибольшим количеством голосов в конце пробега.
Пожалуйста, изучите ответы и проголосуйте за те, которые, по вашему мнению, имеют наибольшую добавленную стоимость.
13 answers
Я думаю, что использование системы контроля версий и "ветвление" части кодов, которые вы должны изменить, может оказаться наилучшим подходом с точки зрения надежности и эффективности.
Распределенная система версий может наилучшим образом соответствовать вашим потребностям, поскольку она позволит вам легко обновлять свои "основные" функции в разных "ветвях", сохраняя при этом некоторые изменения локальными, если это необходимо.
Редактировать: Я почти уверен, что поддержание всего этого в актуальном состоянии с помощью распределенного система версий будет гораздо менее утомительной, чем вы, по-видимому, ожидаете: вы можете сохранить изменения, которые, как вы уверены, вам никогда не понадобятся в другом месте, локальными, а распределенный аспект означает, что каждое ваше развернутое приложение фактически независимо от других и будет распространяться только исправление, которое вы хотите распространить.
Если настройка вашего приложения включает в себя изменение множества небольших фрагментов кода, это может быть признаком того, что дизайн вашего приложения несовершенен. Ваше приложение должно иметь набор стабильного основного кода, точки расширения для подключения пользовательских библиотек, возможность изменять внешний вид с помощью шаблонов, а также возможность изменять поведение и устанавливать плагины с помощью файлов конфигурации. Таким образом, вам не нужна отдельная ветвь SVN для каждого клиента. Скорее, сохраните основной код и библиотеки плагинов расширений в системе управления версиями в обычном режиме. В другом репозитории создайте папку для каждого клиента и храните там все их шаблоны и файлы конфигурации.
На данный момент создание ветвей SVN может быть единственным решением, которое поможет вам сохранить здравомыслие. В вашем нынешнем состоянии почти неизбежно, что вы совершите ошибку и испортите сайт клиента. По крайней мере, с филиалами у вас гарантированно будет стабильная кодовая база для каждого клиента. Единственная проблема с ветвями SVN - это если вы перемещаете или переименовываете файл в ветке, невозможно объединить это изменение обратно в магистраль (вам придется сделать это вручную).
Удачи!
РЕДАКТИРОВАТЬ: Пример хорошо разработанного приложения, использующего все принципы, которые я изложил выше, см. Электронная коммерция Magento. Magento - это самое мощное, расширяемое и простое в настройке веб-приложение, с которым я работал до сих пор.
Возможно, я ошибаюсь, но мне кажется, что Арону нужно , а не контроль версий. Управление версиями - это здорово, и я уверен, что они уже используют его, но для управления обновлениями в сотнях настроенных установок вам нужно что-то другое.
Я думаю о чем-то вроде специально построенной системы пакетов . Вы захотите, чтобы каждая версия модуля отслеживала свои индивидуальные зависимости и "гарантированную совместимость", и используйте эту информацию для автоматически обновляйте только "безопасные" модули.
Например, допустим, вы создали новую версию 3 своего модуля "Вики". Вы хотите распространить новую версию на все серверы, на которых запущено ваше приложение, но вы внесли изменения в один из интерфейсов в модуле Wiki с версии 2. Теперь для всех установок по умолчанию это не проблема, но это нарушило бы установку с пользовательскими расширениями поверх старого интерфейса. Хорошо спланированная система пакетов позаботится о этот.
Чтобы решить вопрос безопасности, вам следует изучить возможность использования цифровых подписей на ваших патчах. Существует множество хороших библиотек, доступных для подписей на основе открытого ключа, поэтому просто используйте то, что кажется стандартным для выбранной вами платформы.
Не уверен, говорил ли кто-то это, здесь много длинных ответов, и я не читал их все.
Я думаю, что лучшим подходом к вашему контролю версий было бы, чтобы ваша CMS находилась отдельно в своем собственном репозитории, а каждый проект - в своем собственном. (или, я думаю, все они могут быть вложенными папками в одном репозитории)
Затем вы можете использовать его магистраль (или определенную ветвь/тег, если хотите) в качестве svn:внешнего в каждом проекте, который этого требует. Таким образом, любые обновления, которые вы делаете для CMS может быть зафиксирован обратно в свой репозиторий и будет затянут в другие проекты по мере обновления svn (или внешний - svn:switch'ed).
Чтобы упростить это, вам нужно будет убедиться, что CMS и пользовательские функции находятся в разных папках, чтобы внешние svn работали правильно.
Т.Е.:
project
project/cms <-- cms here, via svn external
project/lib <-- custom bits here
project/www <-- folder to point apache/iis at
(при необходимости у вас могут быть cms и библиотека в папке www)
Это позволит вам разветвлять/помечать каждый проект по своему усмотрению. Ты можешь также переключите svn:внешнее местоположение для каждой ветви/тега.
Что касается живого внесения изменений, я бы посоветовал вам немедленно избавиться от ftp и использовать rsync или svn для проверки/экспорта. Оба работают хорошо, выбор за вами.
У меня больше всего опыта работы с маршрутом rsync, синхронизирующим экспорт svn на сервер. Если вы пойдете по этому пути, напишите несколько сценариев оболочки, и вы можете создать тестовый сценарий оболочки, чтобы показать вам файлы, которые он будет загружать, не загружая их также, используя флаг -n. Обычно я использую пару сценариев для каждой среды - один для тестирования, а другой для фактического выполнения.
Аутентификация с общим ключом, чтобы вам не требовался пароль для отправки загрузок, также может быть полезна, в зависимости от того, насколько безопасен сервер, к которому будет предоставлен доступ.
Вы также можете поддерживать другой сценарий оболочки для выполнения массовых обновлений, который просто вызывает соответствующий сценарий оболочки для каждого проекта, который вы хотите обновить.
Вы смотрели на Drupal? Нет, не для развертывания и замены того, что у вас есть, а для того, чтобы посмотреть, как они обрабатывают настройки и модули для конкретного сайта?
В принципе, есть папка "сайты", в которой есть каталог для каждого сайта, который вы размещаете. Внутри каждой папки находится отдельный settings.php что позволяет вам указать другую базу данных. Наконец, вы можете (необязательно) иметь папки "темы" и "модули" на сайтах.
Это позволяет выполнять настройки для конкретного сайта определенные модули и ограничивать определенные модули этими сайтами. В результате вы получаете сайт, на котором подавляющее большинство всего абсолютно идентично, и дублируются только различия. Объедините это с тем, как он обрабатывает обновления и обновления, и у вас может получиться жизнеспособная модель.
Встроите в код процесс самообновления.
Он будет проверять наличие обновлений и запускать их, когда/где/как вы настроили его для клиента.
Вам нужно будет создать какой-то список модулей (пользовательских или нет), которые необходимо протестировать с новой сборкой до развертывания. При развертывании обновления вам необходимо будет убедиться, что они протестированы и правильно интегрированы. Надеюсь, ваш дизайн справится с этим.
Обновления в идеале представляют собой несколько ключевых шагов.
-
A) Резервное копирование, чтобы вы могли отказаться. Вы должны иметь возможность отказаться от всего обновления в любое время. Таким образом, это означает, что сначала необходимо создать локальный архив приложения и базы данных.
Б) Процесс мониторинга обновлений - Попросите системный телефон CMS позвонить домой, чтобы найти новую сборку.
C) Запланируйте обновление по доступности - Скорее всего, вы не хотите, чтобы обновление запускалось в ту секунду, когда оно доступно. Это означает, что вам придется создать cron/агента что-то вроде автоматического обновления системы посреди ночи. Вы также можете рассмотреть требования клиентов для обновления по выходным или в определенные дни. Вы также можете постепенно развертывать свои обновления, чтобы не обновлять 1000 клиентов за 1 день и не получать адскую техническую поддержку. Какое-то поэтапное развертывание может быть полезным для вас.
D) Добавить режим обслуживания для обновления сайта - Перевести сайт в режим обслуживания.
E) Проверка SVN или загрузка пакеты -- в идеале вы можете развернуть с помощью svn checkout, а если нет, настройте свой сервер для доставки пакетов, сгенерированных svn, в архив, который можно развернуть на клиентских сайтах.
F) Развертывание сценариев БД - Резервное копирование баз данных, их обновление, их заполнение
G) Обновить код сайта - Вся эта работа выполняется за один шаг.
H) Запустите на нем несколько тестов. Если в ваш код встроены самотесты, это было бы идеально.
Вот что я делаю...
Специфичный для клиента путь включения
- Общий, общий код находится в общий/current_version/lib/
- Код конкретного сайта находится в клиентах/foo.com/lib
- Путь включения настроен на включение из клиентов/foo.com/lib, а затем общий доступ/lib
- Все дело в системе управления версиями
Это гарантирует, что код использует общие файлы везде, где это возможно, но если мне нужно переопределяя определенный класс или файл по какой-то причине, я могу написать конкретную версию клиента в их папке.
Псевдоним общих файлов
Моя конфигурация виртуального хоста будет содержать строку типа
Alias /common <path>/shared/current_version/public_html/common
, Который позволяет совместно использовать общие элементы пользовательского интерфейса, значки и т.д. в разных проектах
Помечайте общий код с каждым выпуском сайта
После каждого выпуска сайта я помечаю общий код, создавая ветвь, чтобы эффективно заморозить этот момент времени. Это позволяет мне развернуть /общий доступ/version_xyz/ к действующему серверу. Затем я могу попросить виртуальный хост использовать определенную версию общих файлов или оставить ее указывающей на current_version, если я хочу, чтобы она получала последние обновления.
Вы смотрели на такие инструменты, как Марионетка (для системного администрирования вкл. развертывание приложений) или Capistrano (развертывание приложений в RubyOnRails, но не ограничиваясь ими)?
Одним из вариантов было бы настроить систему управления версиями только для чтения (Subversion). Вы можете интегрировать доступ к хранилищу в свою CMS и вызывать обновления через меню или автоматически, если вы не хотите, чтобы у пользователя был выбор в отношении обновления (может быть критичным). Использование системы контроля версий также позволит вам легко сохранять различные ветви
Как люди уже упоминали, использование контроля версий (я предпочитаю Subversion из-за функциональности) и ветвления было бы лучшим вариантом. Другое программное обеспечение с открытым исходным кодом, доступное на sourceforge, называется cruisecontrol. Это удивительно, вы настраиваете cruisecontrol с помощью subversion таким образом, чтобы любая модификация кода или новый код, добавленный в serversion, круиз-контроль знал автоматически и выполнял сборку для вас. Это сэкономит вам чертовски много времени.
Я сделал то же самое в моя компания. у нас есть четыре проекта, и мы должны развернуть этот проект на разных серверах. Я настроил cruiseconrol таким образом, что любое изменение в базе кода запускает автоматическую сборку. и другой скрипт развернет эту сборку на сервере. вы готовы идти.
Если вы используете стек LAMP, я бы определенно превратил файлы решений в пакет вашего дистрибутива и использовал его для распространения изменений. Я рекомендую в этом отношении Redhat/Fedora из-за RPM, и это то, в чем у меня есть опыт. В любом случае, вы также можете использовать любой дистрибутив на основе Debian.
Некоторое время назад я создал решение LAMP для управления серверами хостинга провайдера. У них было несколько серверов для веб-хостинга, и мне нужен был способ развернуть изменения моего менеджера, потому что каждая машина была автономной и имела онлайн-менеджера. Я сделал пакет RPM, содержащий файлы решений (в основном php) и некоторые сценарии развертывания, которые запускались с помощью RPM.
Для автоматического обновления у нас был собственный репозиторий RPM, установленный на каждом сервере в yum.conf. Я установил задание crontab для ежедневного обновления серверов последними RPM из этого надежного хранилища.
Доверия также можно достичь, потому что вы можете использовать параметры доверия в пакетах RPM, например, подписывать их с помощью ваш файл открытого ключа и принимающий только подписанные пакеты.
Хм, может быть, стоит добавить файлы конфигурации? Вы написали, что множество маленьких сценариев что-то делают. Теперь, если бы вы встроили их в исходные файлы и управляли ими с помощью файлов конфигурации, не должно ли это "облегчить" это?
С другой стороны, наличие филиалов для каждого клиента выглядит для меня как экспоненциальный рост. И как бы вы "узнали", в каких областях вы что-то сделали, и не забыли "внести" изменения и во все остальные отрасли. Это выглядит довольно уродливо для я.
Похоже, что сочетание элементов управления версиями, параметров конфигурации и/или квитанций о развертывании кажется "хорошей" идеей.....
С таким количеством вариаций вашего основного программного обеспечения, я думаю, вам действительно нужна система контроля версий, чтобы оставаться в курсе отправки обновлений из магистрали на отдельные клиентские сайты.
Так что, если вы думаете, что подрывная деятельность будет утомительной, у вас есть хорошее представление о том, какими будут болевые точки... Лично я бы не рекомендовал Subversion для этого, так как он не очень хорош в управлении и отслеживании филиалов. Хотя предложение Бенламли использовать внешние компоненты для вашего основного программного обеспечения это хороший вариант, он ломается, если вам нужно настроить основной код для ваших клиентских сайтов.
Загляните в Git для контроля версий, он создан для ветвления и работает быстро.
Ознакомьтесь с Capistrano для управления развертываниями. Это скрипт ruby, часто используемый с Rails, но его можно использовать для всех видов управления файлами на удаленных серверах, даже на сайтах, не связанных с ruby. Он может передавать контент на удаленный конец с помощью различных интерфейсов, включая ftp, scp, rsync, а также автоматически проверьте последнюю версию из вашего репозитория. Приятные функции, которые он предоставляет, включают в себя перехватчики обратного вызова для каждого этапа процесса развертывания (например, чтобы вы могли копировать файлы конфигурации для конкретного сайта, которые могут отсутствовать в системе управления версиями), а также систему регистрации выпусков - с помощью символических ссылок - чтобы вы могли быстро вернуться к предыдущему выпуску в случае проблем.
Я бы рекомендовал файл конфигурации со списком филиалов и их размещенным местоположением, а затем запустить его с помощью сценария, который проверяет каждую ветвь по очереди и загружает последние изменения. Это может быть связано с автоматическим обновлением по ночам.