Подготовка Нескольких Ответвлений Мерзавца по единственному серверу
Действительно ли это - плохая идея использовать единственный сервер подготовки для подготовки нескольких ответвлений мерзавца?
Например, если непрерывный сервер интеграции автоматически выполняет Ansible, Шеф-повара, Марионетку, и т.д. настраивая комплект после того, как все тесты завершаются, и развертывает приложение на StagingApplicationServer.com / <имя ответвления здесь>
Это позволило бы ведущему устройству, разработало бы, и другие ответвления функции для этапа.
Если это не плохая идея, есть ли способ способности разделить различные ответвления, подготовленные в единой системе? Так, например, Nginx/Redis/MongoDB сервис для ответвления 1 может отличаться, чем ответвление 2 и быть вниз порван легко.
Вращение экземпляров Amazon EC2 в течение краткого промежутка времени было бы идеально, но это - к сожалению, не опция. Кроме того, использование субдоменов не является опцией для этого конкретного приложения.
Править:
Для определенных деталей приложение является использованием приложения Фляги Python Redis, MongoDB. Серверы настраиваются с Ansible.
EDIT2:
Для разъяснения я обеспокоен этим являющийся плохой идеей, потому что везде Вы читаете, что Ваша разработка, подготовка и продуктивные среды должны быть настолько же близкими максимально друг друга. Это означает, что, если Ваша стратегия развертывания работает на подготовку, необходимо смочь копировать ее без проблемы для продуктивной среды. т.е. если Ваши сборники пьес Ansible будут работать над подготовкой, то они будут работать на производство.
Для размещения нескольких ответвлений при подготовке, необходимо будет настроить Nginx, например, конфигурацию. Вы, возможно, также должны измениться, как Ваши базы данных, настраивают, или можно выполнить дополнительные шаги для настройки VM для содержания баз данных и т.д. Все эти вещи заканчивают тем, что делали Вашу среду подготовки отличающейся от Вашего производства один.
Я не вижу причин, по которым это было бы плохой идеей. Инсценировка подразумевает непроизводственный сервис, так что вы можете позволить, чтобы вся ваша инсценировка происходила на одном сервере без заботы о резервировании, производительности и т.д. Еще одна причина для разделения приложений и экземпляров приложений - это безопасность, но опять же, для непроизводственного сервиса это менее проблематично, если только вы не размещаете копию ваших производственных данных на вашем сервере сцены (что является еще одним типом разделения, о котором стоит подумать). Если есть проблемы с безопасностью, и вы не можете использовать субдомены, вы все равно можете использовать проксирование в nginx для разделения экземпляров на несколько ВМ. Но, в простейшем виде, вы просто запустите их все на одном экземпляре и используете директивы 'location' для определения того, какое приложение запускается по каждому пути.
nginx не заботится о том, как разделить приложения, хотя вам нужно будет настроить разные конфигурации прокси (либо разные порты, либо разные места для конфигурационных файлов, в зависимости от сервера приложений) для каждого сервера приложений в зависимости от каталога. Как вы это сделаете, будет в некоторой степени зависеть от того, что представляет собой ваш сервер приложений, который вы не указали.
Например, если Ruby использует сервер приложений Passenger, вы будете следовать этим инструкциям: https://www.phusionpassenger.com/documentation/Users%20guide%20Nginx.html#deploying_rails_to_sub_uri
Обратите внимание, что Passenger скрывает от вас некоторые детали реализации, так что вам не нужно думать о портах, а только о каталогах. В то время как в следующем примере вы бы указали порт для проксирования и он должен быть разным для каждого экземпляра приложения.
С Perl Mojolicious вы могли бы следовать этому примеру: http://search.cpan.org/~sri/Mojolicious-5.27/lib/Mojolicious/Guides/Cookbook.pod#Nginx
Обратите внимание, что раздел location в обоих примерах может быть скопирован для стольких путей, сколько вам нужно для независимых экземпляров вашего приложения. Это то же самое, что запускать несколько приложений; вы просто даете каждому свой каталог и конфигурационные файлы.
Я подозреваю, что причина, по которой вы до сих пор не получили никаких ответов, заключается в том, что вы не предоставили никакой конкретной информации о вашей установке. Мне трудно дать совет, когда вы указали, что будете использовать "Ansible, Chef, Puppet и т.д." и "Redis/MongoDB"... вы используете все эти вещи, несмотря на то, что они делают очень похожую работу? Большинство людей выбирают один инструмент развертывания (Ansible, Chef, Puppet и т.д.) и одно хранилище ключей/значений (Redis/MongoDB). Примеры конфигураций для всех этих инструментов, и предостережения о том, на что нужно обратить внимание, будут разными для каждого из них.
В любом случае, короткий ответ на ваш вопрос: Да, вы можете это сделать, и нет никаких технических причин, по которым вам не стоит этого делать.
.