Как Juju "сосуществует" с Chef, делая процесс автоматизации "на шаг впереди"?

Из этого поста ясно, что Juju находится на другом уровне, чем Chef Server. Juju находится на уровне оркестровки или обслуживания, а Chef больше на уровне отдельного сервера или конфигурации.

На одной из главных страниц Juju в Canonical говорится, что Juju разработан так, чтобы "сосуществовать" с такими инструментами, как Chef и Puppet, что делает процесс "еще одним шагом вперед". В течение последних нескольких недель я изучал эту тему в Интернете и не могу найти хорошего объяснения того, как такой инструмент, как Chef, будет сосуществовать с Juju.

Итак, чтобы разбить всеобъемлющий вопрос в заголовке: (особый интерес к Juju работает вместе с Chef Server)

  • Что является примером очарования "написано в Chef"? Это просто заклинание, написанное на bash, которое затем вызывает chef-solo команда? Если это так, может ли очарование назвать chef-client Команде работать совместно с Chef Server?
  • Где совпадение между Джуджу и Шеф-поваром? Например, шарм apache2 имеет свои config-changed перехватывать там, где он вносит изменения в конфигурацию, которые в мире Chef будут иметь место в рецепте с применением файла шаблона. Если брелок Juju работал вместе с кулинарной книгой Chef по развертыванию службы apache2 (кластера), то казалось бы, что брелок "apache2-chef" должен быть написан так, чтобы вы могли разделить задачи. В этом случае очарование apache2 в Charm Store будет менее чем полезным.
  • Если у вас есть роли Chef, примененные к узлам (сервисным единицам), которые развернуты / управляются Juju, и ваш системный администратор решает изменить правила брандмауэра для конкретной роли сервера, и делает ли это в роли Chef, собирается ли Juju когда-нибудь перезаписывать эти изменения?
  • Проще говоря, может ли Juju быть оболочкой Chef Server, как Ironfan?

Я рассматриваю Chef Server как " как", тогда как "Juju" может делать " как", но также и то, что стоит на столе. Это означает, что реальное текущее состояние служб и машин можно запрашивать и реагировать на них. Вы не можете сделать это в Chef Server. Моя цель состоит в том, чтобы внедрить возможности Juju по повышению осведомленности и организации обслуживания в инфраструктуру, управляемую Chef Server.

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

Я хотел бы услышать взвешивания от кого-то в Canonical (например, Хорхе Кастро) и от Opscode (например, А. Джейкоб или Дж. Тимберман).

Источник

1 ответ

Решение

Классные вопросы!

TL; Dr

Я хотел бы разбить ваш вопрос (ы) на пару комментариев... во-первых, вот несколько общих подходов к интеграции шеф-повара и дзюдо:

  • Крюки Charms могут использовать существующие рецепты шеф-повара, которые работают в сольном стиле на сервисных единицах (рекомендуется)

  • сервисные единицы juju регистрируются на существующем chef-сервере, используя подчиненный сервис chef-node

Эти идеи еще не были реализованы/ проверены для шеф-повара, но существуют кукольные эквиваленты.

... гм.. не такой короткий ответ

Вот еще немного из двух подходов к интеграции шеф-повара и Джуджу:

Джуджу в роли топ-пса

Здесь Джуджу управляет шоу. Самая большая ценность, которую дает juju, - это координация событий во время управления распределенной конфигурацией... отсюда и название "оркестровка сервисов". Подвески Juju состоят из крючков, которые называются juju в "нужное время" при координации управления сервисом. Реализация этих хуков в значительной степени открыта. Это сценарии оболочки, исходный код, манифесты кукол или... рецепты шеф-повара.

Juju разбивает биты любой конфигурации сервиса на:

  • "установка".. биты, которые являются специфическими для установки конкретной службы на узел

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

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

Нам нужны некоторые примеры этого, но я думаю, что это будет популярный b / c шеф-повар, имеющий отличный dsl, отличный инструмент для создания шаблонов, и гораздо более приятный в использовании, чем bash при написании сложной конфигурации. Для простой конфигурации рецепты шеф-повара немного излишни, поэтому этот метод интеграции в значительной степени является лучшим из обоих миров... и имеет серьезные перспективы на будущее.

Повар как топ-пёс

Идея заключается в том, чтобы интегрировать службы juju в существующую инфраструктуру, управляемую chef-сервером. Для этого вам нужно написать подчиненный брелок chef-узла. Эта подчиненная служба будет привязана к основным службам juju и будет эффективно регистрировать эти службы как узлы (в частности роли) с сервером chef. Subs могут быть присоединены во время запуска службы juju или в любое время позже в течение жизненного цикла каждого сервиса.

Я думаю, что это будет очень похоже на сабвуфер узла. Все необходимые ключи, роли и т. Д. Будут указаны через config для подчиненного очарования chef-узла. Я бы начал там. Более сложный подход заключается в том, что подчиненный узел chef-node запрашивает как первичную службу, к которой он подключен, так и его chef-сервер для динамического определения ролей, но это будет немного сложнее, чем просто указывать их в конфигурации для подчиненной.

мнения

Я определенно рекомендую способ 1 выше, если это возможно. Наличие координационного уровня поверх инструментов конфигурации, вероятно, будет хорошо работать в долгосрочной перспективе. Излишне говорить, что реальные инфраструктуры могут быть неким сочетанием или вариацией обоих подходов в течение определенного периода времени... особенно во время миграции. Запланированное сосуществование с использованием метода 2, вероятно, будет работать, только если компоненты, управляемые обоими инструментами, будут несколько ортогональны друг другу. Не уверен, что именно это будет выглядеть. Возможно, juju и шеф-повар управляют отдельными относительно отделенными услугами? Я подозреваю, что это может хорошо сработать, чтобы juju управлял первичными услугами, а шеф-повар управлял другими аспектами инфраструктуры. Не знаю. Это немного длиннее обсуждение, хотя:)

Примечание: вы также можете использовать juju для управления самим chef-сервером... даже для больших сложных многоуровневых установок chef-сервера. В последнее время я не смотрел на прелесть chef-сервера, но если он в настоящее время не обрабатывает разделение на уровни и разделение служб, то это, безусловно, можно сделать.

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

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

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