Каковы преимущества рабочего сервера шеф-повара вместо соло шеф-повара?

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

Моя сводная рекомендация совпадает с другими: используйте шеф-сервер, если вам нужно управлять динамической виртуализированной средой, в которой вы будете часто добавлять и удалять узлы. Шеф-сервер также является хорошей CMDB , если он вам нужен. Используйте chef-solo, если у вас менее динамичная среда, где узлы меняются не слишком часто, а роли и рецепты будут. Размер и сложность вашей среды более или менее не имеют значения. Оба подхода очень хорошо масштабируются.

Если вы развертываете chef-solo, используйте cronjob с rsync, 'git pull', или какой-либо другой идемпотентный механизм передачи файлов для поддержки полной копии репозитория chef на каждом узле. Cronjob должен легко настраиваться так, чтобы (а) не запускаться вообще и (б) запускаться, но без синхронизации локального репозитория. Добавьте в репозиторий Chef каталог node / с файлом json для каждого узла. Ваша cronjob может быть настолько сложной, насколько вы пожелаете, с точки зрения определения правильного nodefile (хотя я бы рекомендовал просто $ (hostname -s) .json. Вы также можете создать учетную запись opscode и настроить клиента с размещенным шеф-поваром, если для нет никакой другой причины, кроме как иметь возможность использовать нож для загрузки поваренных книг сообщества и создания скелетов.

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

Chef-server представляет собой дыру, в которой вы используете "загрузку ножа" для обновления кулинарной книги, и вы должны исправить это отверстие самостоятельно (например, с ловушкой после фиксации) или рискуют, что изменения сайта будут незаметно перезаписаны кем-то, кто «закачивает нож» по устаревшему рецепту из устаревшего локального репозитория на своем ноутбуке. Это с меньшей вероятностью произойдет с chef-solo, так как все изменения будут синхронизироваться с серверами непосредственно из главного репозитория. Проблема здесь в дисциплине и количестве сотрудников. Если вы разработчик-одиночка или небольшая команда, загрузка кулинарных книг через API не очень рискованна. В более крупной команде это может быть, если вы не установите хороший контроль.

Кроме того, с помощью chef-solo вы можете хранить все роли узлов, настраиваемые атрибуты и списки выполнения в виде файлов node.json в основном репозитории Chef. В chef-server роли и списки выполнения изменяются на лету с помощью API. С помощью chef-solo вы можете отслеживать эту информацию в системе контроля версий. Здесь отчетливо виден конфликт между статической и динамической средами. Если ваш список узлов (независимо от того, как долго он может быть) не меняется часто, наличие этих данных в системе контроля версий очень полезно. С другой стороны, если вы часто создаете новые узлы и уничтожаете старые (никогда больше не видите их имя хоста или fqdn), сохранение всего этого в системе контроля версий - просто ненужная проблема, а наличие API для внесения изменений очень удобно. Chef-server имеет целый набор функций, направленных на управление динамическими облачными средами, например, опция name в "Knife bootstrap", которая позволяет вам заменить fqdn как способ по умолчанию для идентификации узла. Но в статической среде эти функции имеют ограниченную ценность, особенно по сравнению с наличием ролей и списков выполнения в управлении версиями со всем остальным.

Наконец, среды тестирования рецептов могут быть настроены на лету, почти без дополнительной работы. Вы можете отключить cronjobs, запущенные на сервере, и внести изменения непосредственно в его локальный репозиторий. Вы можете протестировать изменения, запустив chef-solo, и вы увидите, как именно сервер настроится в рабочей среде. Как только все будет протестировано, вы можете зарегистрировать изменения и снова включить локальные cronjobs. Однако при написании рецептов вы не сможете использовать API "Поиска", Это означает, что если вы хотите писать динамические рецепты (например, балансировщики нагрузки), вам придется обойти это ограничение, собирая данные из файлов json в ваших узлах / каталоге, что, вероятно, будет менее удобно и не будет иметь некоторых доступных данных в полной CMDB. Опять же, более динамические среды предпочтут подход, основанный на базе данных, менее динамические среды подойдут для файлов json на локальном диске. В серверной среде, где шеф-повар должен выполнять вызовы API к центральной базе данных, вы будете зависеть от управления всеми тестовыми средами в этой базе данных.

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

Это основные преимущества шеф-повара. Есть и другие, например, отсутствие необходимости администрировать сервер или платить за хостингового шеф-повара, но это относительно незначительные проблемы.

Подводя итог: если вы динамичный и высоко виртуализированный, chef-server предоставляет ряд замечательных функций ( описано в другом месте), и большинство преимуществ шеф-повара будут менее заметны. Однако у шеф-повара есть некоторые определенные, часто не упоминаемые преимущества, особенно в более традиционной среде. Обратите внимание, что развертывание в облаке не обязательно означает, что у вас есть динамическая среда. Если вы не можете, например, добавить дополнительные узлы в свою систему, не выпуская новую версию своего программного обеспечения, вы, вероятно, не динамический. В заключение, с точки зрения высокого уровня CMDB может быть полезен для любого количества вещей, только косвенно связанных с системным администрированием и настройкой, таких как учет и обмен информацией между командами. Использование chef-server может стоить только для этой функции.