Мы небольшая софтверная компания, у которой всего один продукт - веб-сайт (8 миллионов посещений в месяц) с балансировкой нагрузки (около 20 серверов для веб-обслуживания).
В настоящее время мы выпускаем еженедельные выпуски с целью непрерывного развертывания.
Наши серверы работают под управлением Centos, наши клиенты - Mac OS X.
В настоящее время мы оцениваем различные системы упаковки:
Интересно, есть ли у некоторых из вас опыт использования систем упаковки для развертываний и могут ли они что-то поделать.
Я бы предложил Capistrano который, хотя и не является системой упаковки, специально разработан для развертывания кода на одном или нескольких серверах. Он развертывается непосредственно из вашей системы контроля версий (svn, git, mercurial и т. Д.) На серверах, выполняет любые необходимые вам скрипты, выполняет миграцию базы данных и т. Д.
Он хранит на серверах несколько предыдущих версий, что позволяет выполнить откат за секунды в случае непредвиденных проблем.
Кроме того, он обеспечивает развертывание на нескольких серверах, одновременное развертывание на нескольких серверах, откат их всех к предыдущей версии, если какая-либо часть не может быть развернута должным образом.
Capistrano берет свое начало в мире Ruby, но широко используется сегодня. Это может показаться простым, но это очень мощный инструмент, который настоятельно рекомендуется. Моя компания использует его для развертывания десятков веб-сайтов на нескольких серверах.
Поскольку Capistrano - это инструмент командной строки, мы используем Webistrano, веб-интерфейс для удобного управления и запуска Capistrano.
Я использовал пакет RPM для развертывания и ненавижу его по сравнению с пакетом Debian. Использование пакета дает вам множество преимуществ, таких как настройка зависимостей, конфигурация apache, logrotate, cronjobs, сценарии публикации и т. Д., А также только исходный код и разрешения. Возможность использовать debconf, чтобы задавать вопросы пользователю (например, по какому URL-адресу следует обслуживать это веб-приложение?), А затем шаблонировать ответы в конфигурации apache, действительно полезна. Однако, насколько я могу судить, для RPM нет эквивалента, подобного debconf, а это означает, что вам придется редактировать файлы конфигурации вручную и не сможете легко установить новые версии из пакета.
Обычно я думаю, что простая установка из системы управления версиями на серверах упускает из виду главное, потому что для сложных приложений это только часть дела. Итак, учитывая ваши три варианта выше, я бы выбрал 3.
Учитывая простоту вашей ситуации, вы, вероятно, могли бы обойтись без использования монтирования rsync или NFS для распространения кода, а затем небольшого фрагмента кода для «обновления» от запуска одной версии до другой (это то, что я предполагаю, вы имеете в виду под опцией # 2).
Однако, если вам нужно что-то получше, я настоятельно рекомендую использовать собственную систему упаковки для доставки кода (тогда вы получаете «бесплатную» интеграцию со всеми собственными инструментами упаковки). Конечно, это требует некоторые умение создавать хорошо пакеты ... но эти вложения должны окупиться. С другой стороны, использование неродного формата упаковки - это то, за что вам придется платить снова и снова.
Как сказал другой плакат, вы можете затем использовать config. система управления (но опять же, любая хорошая система управления конфигурациями должна интегрироваться с собственной упаковкой ... так что любые вложения туда все равно окупятся).
Что касается некоторых ответов, подразумевающих «правила dpkg, rpm - отстой», я бы посоветовал, если вы вообще склонны их прислушиваться, просто переместите свои серверы на Debian и используйте собственные пакеты.
Я бы серьезно посоветовал вам выбрать систему управления конфигурацией. На выбор есть несколько проектов с открытым исходным кодом: cfengine, кукольный, bcfg2, ...
Cfengine является наиболее широко используемым (17-летний опыт, есть развертывания до +60000 серверов, таких как facebook). При необходимости есть платная поддержка. cfengine.com
Puppet довольно популярен среди новичков в этой области, потому что он кажется более простым (это дело вкуса, IMO), но имеет огромную проблему: он зависит от Ruby, поэтому вам нужно установить эту движущуюся цель. Посмотрите этот пост в блоге сопровождающего debian ruby, чтобы узнать мнение о том, хотите ли вы использовать этот беспорядок для управления своей инфраструктурой: http://www.lucas-nussbaum.net/blog/?p=566; у них также есть платная поддержка.
Я не знаю никого, кто использует bcfg2, выглядит неплохо.
О, да, еще есть рубиновый инструмент, повар. Также беспорядок в установке.
Конечная цель - просто запустить (вы используете centos) новый сервер и позволить ему автоконфигурировать себя. Управление конфигурациями позаботится обо всем. Вам нужно что-то менять на всех серверах? Нет проблем, напишите политику, и она развернется при следующем запуске программного обеспечения. На настройку уходит время (правда, не очень долго, но, как и в случае со всеми новыми вещами, вам нужно почувствовать себя), но вы удивитесь, как вообще вы могли жить без этого.
Следуя принципу бритвы Оккама и принципу простоты Эйнштейна, я бы выбрал номер 3. Насколько я мог понять из моего ограниченного опыта работы с этой системой (я в основном использую Deb, Arch и BSD), RPM - довольно раздутое ПО, вероятно, слишком сложное. для ваших нужд. Я не вижу преимуществ от введения дополнительного слоя SVN. Наиболее логичным кажется использование некоторых сценариев для создания архивов из тегов SVN, а некоторых - для доставки и развертывания. ПО МОЕМУ МНЕНИЮ.