Лучшие практики развертывания инструментов и сценариев в рабочей среде?

Здесь есть несколько категорий инструментов. Некоторые люди используют комбинацию инструментов из этих категорий. Я иногда использую, например, и Puppet, и Capistrano. См. Puppet или Capistrano — используйте Правильный инструмент для работы для обсуждения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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