Многоступенчатый совет по развертыванию? - PullRequest
5 голосов
/ 01 июня 2009

Каковы некоторые рекомендации и общая теория многоэтапного развертывания для веб-приложений?

Меня особенно интересует развертывание приложений Rails с использованием Git, Capistrano и Passenger, и я нашел посты, в которых обсуждаются основные моменты процесса:

Какие соображения я должен принять в отношении каждого этапа (тестирование, подготовка, производство)? Должны ли стадии быть развернуты на разных физических серверах? Любые советы или рекомендации по многоэтапному развертыванию? Любые препятствия, которые я должен высматривать?

лучше

Jacob

Ответы [ 3 ]

1 голос
/ 07 июня 2009

Я всегда только создавал задачи cap для каждой цели развертывания и использовал их в командной строке:

# deploy.rb
task :stage do
  server 10.0.0.1 ...
end

> cap stage deploy

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

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

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

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

Соблазнительно добавить множество пользовательских действий в ваш файл deploy.rb, но я обнаружил, что это имеет тенденцию откатываться назад и требовать больших усилий по техническому обслуживанию по мере изменения вашей среды или изменения cap api.

Другая практика, которую я видел в более крупных средах, - это иметь учетную запись оболочки с проверкой, которая отслеживает стабильную ветку, специально настроенную для работы в качестве контрольной точки capistrano. Вы используете ssh и запускаете команды cap вместо локально. Это может помочь избежать проблем, связанных с тем, что ваш локальный checkout-файл deploy.rb содержит изменения, которые вы не готовы использовать при развертывании в производство. Это не проблема для git vs svn, но все же нужно быть осторожным, чтобы подумать о том, каков их локальный deploy.rb в тот момент, когда они запускают команды cap.

В наши дни Heroku действительно облегчает эту задачу, и EY и другие не сильно отстают.

0 голосов
/ 22 июля 2009

Мы успешно используем многоступенчатое развертывание capistrano уже более года. Система прекрасно разделяет файлы развертывания для каждого этапа практически идентично файлам среды Rails. Это было очень легко настроить и управлять.

0 голосов
/ 02 июня 2009

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...