Управление конфигурацией для многоузловых приложений SOA

Так что это кажется распространенной проблемой в программном обеспечении сегодня. Многие компании решают эту проблему с помощью облачных платформ, таких как AWS, Azure или Heroku. Однако для защиты данных, требующей частных облаков, варианты кажутся менее развитыми.

Чтобы уточнить, моя конкретная потребность заключается в управлении приложением, независимым от узла (физический/виртуальный сервер). В настоящее время мы используем Chef, который кажется далеко не идеальным для этой задачи. В Chef мне требуется иметь список выполнения на каждом отдельном узле в среде. Когда у меня есть SOA-приложение, зависящее от множества различных служб, которые я не хочу устанавливать на одном узле по очевидным причинам, Chef не может мне этого предоставить. Я должен сделать это вручную. Я должен внутренне документировать все зависимости, и кто-то должен принимать решение при создании списков выполнения для каждого узла, что и куда. Там нет параметров конфигурации типа с несколькими узлами (за исключением переменных среды) или автоматизированного способа установки моих служб на многих узлах.

Это кажется такой распространенной проблемой, что я должен поверить, что просто что-то упускаю. Должен быть инструмент, который позволил бы мне управлять приложением SOA в частном облаке проще, чем это делает Chef.

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

Чтобы сжать то, что я хочу в терминах шеф-повара:

Мне нужны роли, которые сопоставляются со средами, инкапсулирующими приложение. Я хотел бы запустить установку в ОКРУЖАЮЩЕЙ СРЕДЕ вместо отдельных узлов. Внутренне программное обеспечение управления конфигурацией будет принимать какое-то обоснованное решение относительно того, на каком узле фактически установить службу, и соответствующим образом обновлять зависимости этих служб (например, через переменную среды).

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

И если есть кто-то из opscode (или фанат шеф-повара), я с готовностью признаю, что, возможно, не использую все, что может предложить Chef, и в этом случае я хотел бы знать, как люди, использующие его в настоящее время, справляются с моей конкретной проблемой.

Кроме того, на всех моих серверах установлена ​​Windows 2008 R2 или Windows 2012, если это имеет значение.


person FredM    schedule 10.12.2013    source источник


Ответы (5)


Это действительно распространенная проблема, и намеки на виноградную лозу, кажется, предполагают, что Opscode (теперь известный как Chef, я думаю) знает об этом и работает над решением. Надеюсь, это то, что мы увидим в Chef 12.

Проблема в том, что Chef — это система управления конфигурациями. Это не продукт для подготовки или оркестровки. Нож пытается решить эту проблему, но в крайне элементарных масштабах. Другие продукты, такие как Ansible и Puppet, лучше приспособлены для решения этой проблемы. Но опять же, даже они не являются продуктами строгой оркестровки и по-прежнему не оправдывают ожиданий.

У меня не было возможности использовать его самостоятельно, но вы должны проверить http://deis.io/ . Это легкая платформа как услуга с открытым исходным кодом, которая, похоже, решает проблему оркестровки. Возможно, это то, что вы ищете.

Другой вариант — использовать что-то вроде https://github.com/coreos/etcd для управления запасами. Это позволяет вам иметь централизованный API инвентаризации системы, который является очень гибким и предлагает больше, чем собственные поисковые данные Chef. При этом вы можете писать поваренные книги для поиска других систем и сервисов и предпринимать шаги для подключения к ним. Это начинает сбивать с толку, но вы всегда можете заставить Chef выполнить команду ssh, которая выполняет команду на удаленном экземпляре.

В любом случае, всего пара предложений. Надеюсь, это поможет.

person wrangler    schedule 10.12.2013
comment
Я отметил это как ответ, потому что я думаю, что это самое близкое к ответу, который я получу. Между ответами здесь и независимым исследованием кажется, что пока нет панацеи для решения этой проблемы. Я посмотрю на те продукты, которые вы связали на выходных. Спасибо! - person FredM; 12.12.2013
comment
+1 Меня удивляет, что opscode (теперь шеф-повар) не использует Deis в качестве рекомендуемой платформы для развертывания приложений. Он умело использует как шеф-повара, так и докера. Существуют кулинарные книги приложений, но почти нет примеров того, как их использовать :-( - person Mark O'Connor; 12.12.2013
comment
@Марк: Согласен. Я надеюсь, что они решат эти проблемы в ближайшее время. А поваренные книги приложений — это что-то вроде шутки: очень сложные, плохо документированные, а на прошлой неделе в поваренной книге application_ruby была ошибка, которая полностью ее сломала, и потребовалось несколько дней, чтобы получить принятый пулл-реквест. - person wrangler; 15.12.2013

Я хотел бы запустить установку в ОКРУЖАЮЩЕЙ СРЕДЕ вместо отдельных узлов. Внутренне программное обеспечение управления конфигурацией будет принимать какое-то обоснованное решение относительно того, на каком узле фактически установить службу, и соответствующим образом обновлять зависимости этих служб.

Вы ищете решение PAAS (платформа как услуга). Ни повар, ни марионетка вам этого не дадут. Это инструменты, в первую очередь предназначенные для автоматизации развертывания инфраструктуры. Однако их можно использовать для установки приложений, как вы заметили, они используют подход, основанный на узлах.

Я не знаю ни одного решения PAAS с открытым исходным кодом для Windows, поэтому я бы посоветовал изучить коммерческие альтернативы размещенным решениям, таким как Microsoft Azure.

person Mark O'Connor    schedule 10.12.2013

Я не использовал Puppet с Windows, но Puppet поставляется в комплекте с Facter, который обеспечивает поддержку пользовательских фактов — http://puppetlabs.com/blog/facter-part-1-facter-101

Все переменные Facter доступны для манифестов puppet, поэтому вы можете создавать списки запуска, которые выполняют разные действия в разных средах.

Кроме того, вы упоминаете конфигурацию для приложения, а не для узла — для этого предназначены модули Puppet, и вы можете легко создавать свои собственные. Это позволит различным узлам применять одни модули, игнорировать другие или даже убедиться, что модуль отсутствует.

person xiankai    schedule 10.12.2013
comment
Очень интересный блог. Cheers For Balance Chef допускает роли, специфичные для среды, или различия среды между ролями и связанными с ними списками выполнения. Конфигурация среды также может быть настроена. - person PatrickWalker; 12.12.2013

Я удивлен, что не упомянуты RightScale, Scalr или enStratus. Большинство этих решений заполняют пробелы в реализации SOA, а также позволяют гибко изменять части SOA по мере необходимости.

person Electrawn    schedule 20.01.2014

Я знаю, что это не 100% победа, но если я правильно понимаю вашу проблему, это поможет. Мы используем поваренные книги, сделанные на заказ (очевидно), но с пониманием роли. Под этим я подразумеваю, что если мы запускаем новый сервер приложений, наш балансировщик нагрузки автоматически обновляется информацией о новом сервере. Вы можете реализовать это, используя

appservers = search(:node, "role:applicationServer")

и настроить его для правильной посадки.

Что касается автоматического масштабирования, у нас есть собственные скрипты Python для этого.

person Craneum    schedule 14.08.2014