Стоимость производительности автоматизированного управления конфигурацией - PullRequest
0 голосов
/ 05 февраля 2012

Я впервые узнаю о таких инструментах, как Chef / Puppet / etc, и мне было интересно, насколько хорошо (или плохо) они интегрируются с приложениями, развернутыми в облаке:

  • Зачем использовать Chef, когда есть API-интерфейсы для конкретных поставщиков, а также такие инфраструктуры, как JCloud, которые абстрагируют даже эти API-интерфейсы?
  • Существуют ли затраты на производительность при использовании этих инструментов конфигурации или (после настройки) узлы / машины просто работают как любая другая (неуправляемая) машина в облаке?
  • Может ли Chef использоваться для настройки какой-либо существующей технологии или он предоставляет список «поддерживаемых поставщиков / систем»? То есть, скажем так, у меня есть несколько серверов PostgreSQL, настроенных Chef. Затем на следующий день выходит какая-то безумная новая СУБД, и я хочу переключиться на нее. Нужно ли ждать, пока Chef «поддержит» эту новую систему, или Chef не зависит от поставщика?

Заранее спасибо!

1 Ответ

3 голосов
/ 05 февраля 2012

Раскрытие информации: я являюсь одним из разработчиков, работающих в Puppet Labs.

Зачем использовать Chef, когда есть API-интерфейсы для конкретных поставщиков, а также такие инфраструктуры, как JCloud, которые абстрагируют даже эти API-интерфейсы?

Есть две причины. Одним из них является то, что Chef, Puppet и подобные инструменты похожи на JCloud - они предлагают абстракцию над конкретными облачными API. Итак, вы используете их по той же причине.

Другое - то, что большинство облачных API-интерфейсов на самом деле предназначены для создания машин, а Chef, Puppet и аналогичные инструменты на самом деле предназначены для настройки после , когда машина создана. Абстракция над облачным API более удобна, чем основной упор.

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

Есть ли затраты на производительность при использовании knife для создания машины? Нет, это как любой другой неуправляемый узел. Если вы создаете машину без установленного Chef, это похоже на машину без установленного Chef. То же самое относится и к марионеточной стороне и т. Д.

(Имейте в виду, что у Chef, Puppet и подобных инструментов нет API, которого нет в API публичного облака. Никаких дорогих предложений для нас там.;)

Можно ли использовать Chef для настройки какой-либо существующей технологии или он предоставляет список «поддерживаемых поставщиков / систем»? То есть, скажем так, у меня есть несколько серверов PostgreSQL, настроенных Chef. Затем на следующий день выходит какая-то безумная новая СУБД, и я хочу переключиться на нее. Нужно ли ждать, пока Chef «поддержит» эту новую систему, или Chef не зависит от поставщика?

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

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

Если вам нужно больше - например, управление доступом в базе данных является частью первого класса модели, вам, возможно, придется подождать, пока кто-то не напишет поддержку для этого в вашем продукте. (Это кто-то, очевидно, может быть вами.:)

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

Ни один из продуктов не является "специфичным для поставщика" в каком-либо значимом смысле, хотя они оба более эффективны в Unix, чем другие платформы, и имеют более ограниченную, но все же ценную поддержку Windows.

Почти все здесь относится и к другим продуктам в космосе.

...