Назад | Перейти на главную страницу

Почему повар, марионетка, ансибль, соль и т. Д.?

Экосистема инструментов DevOps вызывает у меня недоумение. Вместо сценариев оболочки, которые работают повсюду, каждый в пространстве оркестровки / управления сервером использует свои собственные проприетарные форматы. У Ansible есть свои игровые книги YAML, у Puppet есть свой язык классов / графов, у соли, такой как ansible, есть какой-то формат YAML, chef - это встроенный Ruby DSL. Из всех этих подходов мне больше всего нравится шеф-повар, потому что он делает самые простые вещи. Итак, я предполагаю, что одним из преимуществ является лучшая видимость парка при использовании одного из этих инструментов, но он ортогонален фактическому компоненту конфигурации и обеспечения.

Я не совсем понимаю, почему все пытаются заново изобрести сценарии оболочки с помощью YAML, потому что чаще всего ssh -t это все, что мне нужно для работы вместе с библиотекой сценариев оболочки. Эти сценарии обычно упаковываются в виде автономных файлов tar, они достаточно малы и просты, чтобы их можно было смешивать и сопоставлять при необходимости. У них нет никаких зависимостей, кроме bash и будет работать где угодно. Так почему же тогда такое простое решение недостаточно для ансибля, марионетки, повара и т. Д.? Что получают все эти решения от замены bash скрипты в каком-то другом формате?

Есть много веских причин использовать программное обеспечение для управления конфигурацией. Хотя существует много разных инструментов, я сосредоточусь на некоторых функциях Puppet (основные концепции в основном те же).

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

Декларативная

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

Обеспечение желаемого состояния

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

Фреймворк для автоматизации повседневного

Puppet позволяет автоматизировать рутинные дела и работать над более сложными проектами, оказывающими большее влияние на бизнес.

Пример установки пакета

Вы можете делать всевозможные интересные вещи, например устанавливать пакеты (в большом количестве операционных систем) или гарантировать, что установлены только определенные версии пакета.

package { "screen":
    ensure => "installed"
}

Приведенный выше код гарантирует, что пакет screen установлен, и он будет работать в Debian (который использует apt) или Redhat (который использует yum). Вам не нужно поддерживать свои собственные сценарии или логику для каждой системы управления пакетами, Puppet сделает это за вас.

И есть еще

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