Рекомендации по развертыванию инструментов и сценариев для производства?

Ответ 1

Здесь есть несколько категорий инструментов. Некоторые люди используют комбинацию инструментов из этих категорий. Иногда я использую, например, и Кукольный и Капистрано. См. Кукольный или Капистрано - используйте подходящий инструмент для работы для обсуждения.

Инструменты для создания сценариев, предназначенные для развертывания приложения:

Общий шаблон с инструментами этой категории состоит в том, что вы создаете файл script и/или config, часто с наборами команд, аналогичных Makefile, и инструмент будет передан в вашу производственную коробку, выполните проверку ваш источник и выполните любые другие шаги.

Инструменты в этой области обычно имеют возможности для отката к предыдущей версии. Таким образом, они проведут проверку источника на каталог release/, и создадут символическую ссылку от "current" до "release/", если все будет хорошо. Если есть проблема, вы можете вернуться к предыдущей версии, запустив команду, которая удалит "текущий" и свяжет ее с предыдущими версиями/каталогами.

• Capistrano происходит из сообщества Rails, но является универсальным. Пользователи Capistrano могут быть заинтересованы в deprec, наборе рецептов развертывания для Capistrano.
• Владелец Deployer является альтернативой Capistrano, снова из сообщества Rails.
• Напишите свою собственную оболочку script или Makefile.

Параметры для получения файлов в окне производства:

• Прямая проверка из источника. Не всегда возможно, если в ваших производственных коробках отсутствуют средства разработки, в частности инструменты для управления исходным кодом.
• Проверить источник локально, затем tar/zip. Используйте scp или rsync для копирования tarball. Это иногда предпочтительнее для чего-то вроде развертывания Amazon EC2, где сжатый tarball может сэкономить время/пропускную способность.
• Проверить исходный код локально, затем rsync его в поле производства.

Инструменты для упаковки

Используйте свою систему упаковки ОС для создания пакетов, содержащих файлы для вашего приложения. Создайте главный пакет, который имеет в качестве зависимостей другие необходимые вам пакеты. Примером этого является RubyWorks, используемая для развертывания стека Rails и пример приложения. Тогда это вопрос использования apt, yum/rpm, Windows msi или любого другого для развертывания данной версии. Откат включает удаление и переустановку старой версии.

Общие инструменты, предназначенные для установки приложений/конфигураций и поддержки набора систем

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

• Cfengine является инструментом в этой категории.
• Puppet стремится улучшить Cfengine. Он получил кривую обучения, но многие считают целесообразным выяснить, как это сделать. Как только вы это сделаете, каждый блок периодически проверяет центральный сервер и проверяет, что все в актуальном состоянии. Если кто-то редактирует файл или изменяет разрешение, это обнаруживается и исправляется. Таким образом, в отличие от инструментов развертывания выше, Puppet не только ставит файлы в нужное вам место, но и гарантирует, что они останутся такими.
• Chef немного моложе Puppet с аналогичным подходом.
• Smartfrog - еще один инструмент в этой категории.
• Ansible работает с обычными файлами YAML и не требует агентов, работающих на серверах, которыми он управляет

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

Ответ 2

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

Ответ 3

Создайте свои собственные пакеты в формате, который использует ваш дистрибутив, например. Пакеты Debian (.deb). Они могут быть скопированы на каждый компьютер и установлены вручную, или вы можете настроить свой собственный репозиторий и добавить его в список источников.

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

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

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

Ответ 4

Мне приходится часто развертывать PHP-скрипты и конфигурации Apache нескольким клиентам. Поскольку все они запускают Debian Linux, я настроил репозиторий пакетов Debian на моем сервере, и все, что нужно сделать клиенту, это тип apt-get upgrade, и они получают последнюю версию.

Ответ 5

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

Ответ 6

Первое, что нужно сделать, - это получить все эти сценарии в репозитории управления версиями (svn или git хороши), чтобы вы могли отслеживать изменения этих сценариев с течением времени.

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