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

Зачем использовать Chef / Puppet вместо сценариев оболочки?

Новое в инструментах Puppet и Chef. Кажется, что работа, которую они делают, может быть выполнена с помощью сценариев оболочки. Возможно, это было сделано в сценариях оболочки, пока они не появились.

Согласен, они более читабельны. Но есть ли какие-либо другие преимущества перед сценариями оболочки, кроме простоты чтения?

Специфичный для предметной области язык имеет большое значение в объеме написанного вами кода. Например, вы можете возразить, что нет большой разницы между:

chmod 640 /my/file

и

file { "/my/file":
    mode => 640,
}

но между ними есть большая разница:

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

и

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

Что произойдет, если wget выйдет из строя? Как ваш сценарий справится с этим? И что произойдет, если после этого в вашем скрипте есть что-то, что требует наличия $ FILE с правильным содержимым?

Вы можете возразить, что можно просто поставить echo "Hello world" > $FILE в сценарии, за исключением того, что в первом примере сценарий должен запускаться на клиенте, тогда как puppet компилирует все это на сервере. Поэтому, если вы меняете контент, вам нужно только изменить его на сервере, и он изменит его для любого количества систем, на котором вы хотите его разместить. А puppet автоматически обрабатывает зависимости и передает проблемы.

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

Это будет непопулярное мнение, но системы управления конфигурацией не обязательно лучше. Иногда действительно лучше просто.

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

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

Вы ответили на свой вопрос ...

Автоматизация становится более масштабируемой и формализованной. Puppet и Chef в наши дни считаются стандартами (см. объявления о работе).

Складчатые сценарии оболочки имеют свое место, но они не масштабируемость в контексте движения DevOps. Читаемость - часть этого.

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

Настоящая (часто незамеченная) польза от Chef: идемпотентность. Возможность быть уверенным в состоянии ресурса независимо от комбинации выполняемых рецептов с перекрывающимися интересами - огромное преимущество по сравнению с конфигурацией сценария оболочки. Если у вас сейчас есть сценарии оболочки для настройки, спросите себя, сколько из них можно запускать несколько раз без непредвиденных / нежелательных последствий?

Правильное решение CM помогает обеспечить масштабируемый успех за счет упрощения межплатформенной автоматизации и совместной работы в команде. Хотя всего этого можно добиться с помощью хорошо организованной, правильно поддерживаемой и управляемой версиями группы сценариев оболочки; вы должны спросить себя «почему». Chef / Puppet и аналогичные технологии появились потому, что группа талантливых SysOps устала решать одни и те же проблемы снова и снова и намеревалась предоставить нам лучший вариант.

Ключевые части:

  • Идемпотентность
  • Легкость управления зависимостями (управление версиями)
  • Стандартизированная организация (принята на отраслевом уровне)
  • Абстракция для отделения задач настройки сервера от деталей системного уровня
  • Способность использовать знания сообщества (гарантированно соблюдающие все вышеперечисленные принципы)

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

Например, ваша команда chmod предполагает, что файл существует, пользователь, владеющий файлом, существует, что каталоги созданы и так далее. Поэтому ваш сценарий должен учитывать все эти предпосылки.

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

Если вам доступны одноразовые серверы или у вас есть причина встать более чем по паре за раз, полноценная CM-система гораздо лучше удовлетворит ваши потребности, чем серия сценариев оболочки.

Если ваши потребности в сборке скромные (или вы любите вручную создавать органические серверы справедливой торговли свободного выгула), то оставайтесь простыми.

Лично я, активно используя Chef на прошлом концерте, попытался «сохранить простоту» на этом концерте, но мне очень не хватало примитивов, абстракций и возможностей, которые предоставлял Chef. Даже если вы попадете в ситуацию, когда вы можете получить то, что вам нужно, с помощью пары команд оболочки, вы можете просто запустить их с блоком «command», вводя команды оболочки точно так же, как вы бы написали их в оболочке.

С учетом сказанного, вы можете запускать Chef без сервера (chef-solo), и я почти уверен, что у Puppet есть аналог, где вы все еще можете использовать чужие кулинарные книги и рецепты без запуска центрального сервера.

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

Я создал среду автоматизации сервера на основе сценария оболочки: https://github.com/myplaceonline/posixcube

Я уверен, что я не первый, кто сделал такой проект, но я не смог найти что-то подобное, которое соответствовало бы моим потребностям, поэтому я подумал, что другие могут найти это полезным. У меня был только опыт работы с Chef, но, когда я начал смотреть на Ansible и другие, я хотел попробовать сценарии оболочки, и пока мне нравится результат.