Я собираюсь ориентировать этот ответ так, как будто вопрос был «в чем преимущества chef-solo», потому что это лучший способ, который я знаю, чтобы охватить различия между подходами.
Моя сводная рекомендация соответствует другим: используйте chef-сервер, если вам нужно управлять динамической виртуальной средой, где вы будете часто добавлять и удалять узлы. Chef-сервер также является хорошим CMDB , если он вам нужен. Используйте chef-solo, если у вас менее динамичная среда, в которой узлы не будут меняться слишком часто, а роли и рецепты будут меняться. Размер и сложность вашей среды более или менее не имеют значения. Оба подхода очень хорошо масштабируются.
Если вы развертываете chef-solo, используйте cronjob с rsync, 'git pull' или каким-нибудь другим идемпотентным механизмом передачи файлов, чтобы поддерживать полную копию репозитория chef на каждом узле. Cronjob должен быть легко настраиваемым, чтобы (а) вообще не запускаться и (б) запускаться, но без синхронизации с локальным репозиторием. Добавьте каталог узлов / в вашем хранилище chef с файлом json для каждого узла. Ваш cronjob может быть настолько сложным, насколько вы пожелаете, с точки зрения определения правильного файла узла (хотя я бы порекомендовал просто $ (hostname -s) .json. Вы также можете создать учетную запись opscode и настроить клиента с размещенным шеф-поваром, если для нет другой причины, кроме как использовать нож для загрузки кулинарных книг сообщества и создания скелетов.
У этого подхода есть несколько преимуществ, кроме очевидного «отсутствия необходимости администрировать сервер». Ваш источник контроля будет последним арбитром всех изменений конфигурации, репозиторий будет включать все узлы и списки выполнения, а каждый сервер, являющийся полностью независимым, облегчает некоторые удобные сценарии тестирования.
Chef-сервер вводит дыру, в которой вы используете «загрузку ножом» для обновления кулинарной книги, и вы должны исправить эту дыру самостоятельно (например, с помощью ловушки после фиксации) или риск изменения сайта может быть незаметно перезаписан кем-то, кто «загрузил нож» Это устаревший рецепт из устаревшего локального хранилища на его ноутбуке. Это менее вероятно в случае с chef-solo, поскольку все изменения будут синхронизироваться с серверами непосредственно из главного репозитория. Проблема здесь в дисциплине и количестве сотрудников. Если вы являетесь индивидуальным разработчиком или очень маленькой командой, загрузка поваренных книг через API не очень рискованна. В большой команде это может быть, если вы не установите хороший контроль на месте.
Кроме того, с помощью chef-solo вы можете хранить все роли своих узлов, настраиваемые атрибуты и списки выполнения в виде файлов node.json в своем главном хранилище chef. С помощью chef-сервера роли и списки выполнения изменяются на лету с помощью API. С chef-solo вы можете отслеживать эту информацию в системе контроля версий. Именно здесь можно четко увидеть конфликт между статической и динамической средами. Если ваш список узлов (независимо от того, насколько длинным он может быть) не часто меняется, очень полезно иметь эти данные в контроле версий. С другой стороны, если вы часто порождаете новые узлы и уничтожаете старые (чтобы никогда больше не видеть их имя хоста или fqdn), держать все это под контролем ревизий - это просто ненужная проблема, и иметь API для внесения изменений очень удобно. Chef-сервер обладает целым набором функций, предназначенных также для управления динамическими облачными средами, например, опция name в «начальной загрузке ножа», которая позволяет заменить fqdn в качестве способа идентификации узла по умолчанию. Но в статической среде эти функции имеют ограниченную ценность, особенно по сравнению с наличием ролей и списков выполнения в управлении ревизиями со всем остальным.
Наконец, среда тестирования рецептов может быть настроена на лету практически без дополнительной работы. Вы можете отключить cronjobs, работающие на сервере, и внести изменения непосредственно в его локальное хранилище. Вы можете проверить изменения, запустив chef-solo, и вы увидите, как именно сервер будет сам настраиваться в рабочей среде. После того, как все проверено, вы можете проверить изменения и снова включить локальные cronjobs. Однако при написании рецептов вы не сможете использовать API-интерфейс поиска, а это означает, что если вы хотите писать динамические рецепты (например, loadbalancers), вам придется обойти это ограничение, собирая данные из файлов json в Ваш каталог узлов / узлов, который, вероятно, будет менее удобным и не будет иметь некоторых данных, доступных в полной CMDB. Еще раз, более динамичные среды предпочтут подход, основанный на базе данных, менее динамичные среды подойдут для файлов json на локальном диске. В серверной среде, где шеф-повар должен выполнять вызовы API для центральной базы данных, вы будете зависеть от управления всеми средами тестирования в этой базе данных.
Последний также может быть использован в чрезвычайных ситуациях. Если вы устраняете неисправность критической проблемы на производственных серверах и решаете ее с помощью изменения конфигурации, вы можете сразу же внести изменения в репозиторий сервера, а затем отправить его наверх к главному.
Это основные преимущества chef-solo. Есть и другие, такие как отсутствие необходимости администрировать сервер или платить за хост-шеф, но это относительно незначительные проблемы.
Подводя итог: если вы динамичны и высоко виртуализированы, chef-сервер предоставляет ряд замечательных функций (о которых рассказано в другом месте), и большинство преимуществ chef-solo будут менее заметны. Однако, есть некоторые определенные, часто не упомянутые преимущества для шеф-повара, особенно в более традиционных средах. Обратите внимание, что развертывание в облаке не обязательно означает, что у вас динамическая среда. Если вы не можете, например, добавить больше узлов в вашу систему без выпуска новой версии вашего программного обеспечения, вы, вероятно, не динамичны. Наконец, с точки зрения высокого уровня CMDB может быть полезна для любого количества вещей, только косвенно связанных с системным администрированием и конфигурацией, таких как учет и обмен информацией между командами. Использование chef-сервера может стоить только этой функции.