Я ищу решения для автоматического развертывания для моей команды и последние несколько дней играю с Chef. Мне удалось запустить простое веб-приложение на базовой виртуальной машине Red Hat с помощью chef-solo.
Наша конечная цель - использовать Chef (или другую систему) для автоматического развертывания топологий приложений в облаке по мере выполнения сборок. Наш процесс в основном будет работать так:
Каковы преимущества и / или варианты использования запуска Chef Server?
Есть ли какие-либо серьезные преимущества в том, что Chef Server хранит и получает кулинарные книги из SCM, по сравнению с использованием chef-solo и скриптом, который будет извлекать кулинарные книги из SCM?
Я собираюсь сориентировать этот ответ, как если бы вопрос был «каковы преимущества chef-solo», потому что это лучший из известных мне способов объяснить различия между подходами.
Моя сводная рекомендация согласуется с другими: используйте шеф-сервер, если вам нужно управлять динамической виртуализированной средой, в которой вы будете часто добавлять и удалять узлы. Шеф-повар - тоже хороший CMDB, если он вам нужен. Используйте chef-solo, если у вас менее динамичная среда, где узлы меняются не слишком часто, а роли и рецепты будут. Размер и сложность вашей среды более или менее не имеют значения. Оба подхода очень хорошо масштабируются.
Если вы развертываете chef-solo, используйте cronjob с rsync, git pull или каким-либо другим идемпотентным механизмом передачи файлов, чтобы поддерживать полную копию репозитория chef на каждом узле. Cronjob должен легко настраиваться так, чтобы (а) не запускаться вообще и (б) запускаться, но без синхронизации локального репозитория. Добавьте в репозиторий Chef каталог node / с файлом json для каждого узла. Ваша cronjob может быть настолько сложной, насколько вы пожелаете, с точки зрения определения правильного nodefile (хотя я бы рекомендовал просто $ (hostname -s) .json. Вы также можете создать учетную запись opscode и настроить клиента с размещенным шеф-поваром, если для нет другой причины, кроме возможности использовать нож для загрузки поваренных книг сообщества и создания скелетов.
У этого подхода есть несколько преимуществ, помимо очевидного «отсутствия необходимости администрирования сервера». Ваш исходный элемент управления будет окончательным арбитром всех изменений конфигурации, репозиторий будет включать все узлы и списки выполнения, а каждый сервер, будучи полностью независимым, облегчает некоторые удобные сценарии тестирования.
Chef-server представляет собой дыру, в которой вы используете «загрузку ножа» для обновления кулинарной книги, и вы должны исправить эту дыру самостоятельно (например, с помощью крючка после фиксации), иначе изменения сайта будут перезаписаны незаметно кем-то, кто «загрузил ножом» s устаревший рецепт из устаревшего локального репозитория на его ноутбуке. Это с меньшей вероятностью произойдет с chef-solo, поскольку все изменения будут синхронизироваться с серверами непосредственно из главного репозитория. Проблема здесь в дисциплине и количестве сотрудников. Если вы разработчик-одиночка или небольшая команда, загрузка кулинарных книг через API не очень рискованна. В более крупной команде это может быть, если вы не установите хороший контроль.
Кроме того, с помощью chef-solo вы можете хранить все роли ваших узлов, настраиваемые атрибуты и списки выполнения в виде файлов node.json в вашем основном репозитории Chef. В chef-server роли и списки выполнения изменяются на лету с помощью API. С помощью chef-solo вы можете отслеживать эту информацию в системе контроля версий. Здесь отчетливо виден конфликт между статической и динамической средами. Если ваш список узлов (независимо от того, как долго он может быть) не часто меняется, очень полезно иметь эти данные в системе контроля версий. С другой стороны, если вы часто создаете новые узлы и уничтожаете старые (никогда больше не видите их имя хоста или fqdn), сохранение всего этого в системе контроля версий - просто ненужная проблема, а наличие API для внесения изменений очень удобно. Chef-server имеет целый набор функций, направленных на управление динамическими облачными средами, например, параметр имени в «Knife bootstrap», который позволяет вам заменить fqdn в качестве способа идентификации узла по умолчанию. Но в статической среде эти функции имеют ограниченную ценность, особенно по сравнению с тем, что роли и списки выполнения находятся в управлении версиями со всем остальным.
Наконец, среды тестирования рецептов могут быть настроены на лету, что почти не требует дополнительной работы. Вы можете отключить cronjobs, запущенные на сервере, и внести изменения непосредственно в его локальный репозиторий. Вы можете протестировать изменения, запустив chef-solo, и вы увидите, как именно сервер настроится в рабочей среде. Как только все будет протестировано, вы можете зарегистрировать изменения и снова включить локальные cronjobs. Однако при написании рецептов вы не сможете использовать API «Поиск», а это означает, что если вы хотите писать динамические рецепты (например, балансировщики нагрузки), вам придется обойти это ограничение, собирая данные из файлов json в ваш каталог узлов /, что, вероятно, будет менее удобным и не будет иметь некоторых данных, доступных в полной CMDB. Опять же, более динамические среды предпочтут подход, основанный на базе данных, менее динамические среды подойдут для файлов json на локальном диске. В серверной среде, где шеф-повар должен выполнять вызовы API к центральной базе данных, вы будете зависеть от управления всеми средами тестирования в этой базе данных.
Последние также могут использоваться в экстренных случаях. Если вы устраняете критическую проблему на производственных серверах и решаете ее с помощью изменения конфигурации, вы можете немедленно внести изменения в репозиторий сервера, а затем отправить его вверх по потоку на главный сервер.
Это основные преимущества chef-solo. Есть и другие, например, отсутствие необходимости администрировать сервер или платить за хостингового повара, но это относительно незначительные проблемы.
Подводя итог: если вы динамичный и высоко виртуализированный, chef-server предоставляет ряд замечательных функций (описанных в другом месте), и большинство преимуществ chef-solo будут менее заметными. Однако у шеф-повара есть некоторые определенные, часто не упоминаемые преимущества, особенно в более традиционной среде. Обратите внимание, что развертывание в облаке не обязательно означает, что у вас есть динамическая среда. Если вы не можете, например, добавить больше узлов в свою систему, не выпуская новую версию своего программного обеспечения, вы, вероятно, не динамический. Наконец, с точки зрения высокого уровня CMDB может быть полезен для любого количества вещей, только косвенно связанных с системным администрированием и настройкой, таких как учет и обмен информацией между командами. Использование chef-server может стоить только для этой функции.
Раскрытие информации: я работаю в Opscode.
Главное преимущество Chef Server над Solo - это возможность использовать поиск в вашей инфраструктуре. Классический пример - балансировщик нагрузки с веб-серверами. Балансировщик нагрузки может автоматически обновлять свою конфигурацию по мере добавления и удаления веб-серверов в инфраструктуру, просто выполняя поиск по ним. Solo - это всего лишь отдельные машины, в то время как Chef Server предоставляет возможность запрашивать такие вещи, как «все машины с более чем 4 гигабайтами ОЗУ» или «мастер базы данных».
Chef Server также дает вам возможность управлять своей инфраструктурой без копирования архивов, визуализировать вашу инфраструктуру с помощью консоли управления и управлять тем, на каких машинах работают какие версии поваренных книг с окружениями. Есть и другие преимущества, но они не в моей голове. Если вы хотите опробовать Chef Server без его установки, просто зарегистрируйте учетную запись Opscode Hosted Chef, первые 5 узлов будут бесплатными.
chef-server управляет кулинарными книгами и данными конфигурации для ваших узлов.
Вы добавляете кулинарные книги на сервер шеф-повара с помощью инструмента ножа, а затем даете каждому узлу рабочий список рецептов, чтобы они получали нужные им поваренные книги, когда узел настраивается с помощью шеф-клиента. Поскольку chef-client работает в фоновом режиме, ваши узлы будут периодически проверять наличие обновленных кулинарных книг на вашем chef-сервере.
chef-server также хранит ваши данные конфигурации и переменные, поэтому вы можете изменять настройки для ваших узлов, чтобы они подбирались автоматически. Это хорошо для более динамических настроек, которые не должны или не могут быть жестко заданы в ваших рецептах.