Если у меня есть программная система, которая имеет много зависимостей от других библиотек, таких как libssl или libxml и т. Д., Должен ли я создавать отдельные кулинарные книги для каждой из этих библиотек (с рецептом, который на самом деле состоит только из двух строк) или люди делают несколько блоков пакета в кулинарной книге, чтобы гарантировать наличие зависимостей (и не разделять эти блоки пакета на их внешние кулинарные книги)?
Если вам нужно только установить зависимости пакетов, вы можете сделать что-то простое, например:
%w{ package1 package2 package3 }.each do |pkg|
package pkg
end
Или вы даже можете создать атрибут и перебирать его.
атрибуты / default.rb:
default['app']['deps'] = [ "package1", "package2" ]
рецепты / deps.rb:
node['app']['deps'].each do |pkg|
package pkg
end
Второй способ позволит вам обновить список пакетов с помощью переопределений.
Вы даже можете добавить это в отдельный рецепт в своей книге рецептов, который можно добавить в run_list начальной загрузки или в роль приложения.
Как сказал CS3, действительно непрактично иметь сотни кулинарных книг только для того, чтобы в конечном итоге установить одно приложение. Chef на самом деле использует менеджер пакетов вашей системы и может автоматически разрешить зависимости за вас.
Единственная причина, по которой вы хотели бы отделить зависимость, заключается в том, что у вас есть некоторые конкретные элементы конфигурации, которые могут изменяться в разных системах или могут различаться в зависимости от пакета, который от него зависит.
Я бы начал с предложения просто встроить ваши зависимости, такие как установка libssl-dev, libxml2-dev, libxslt-dev и т. Д., Прямо в книгу рецептов, которая устанавливает ваше приложение для простоты.
Проблемы с этим подходом возникают в том случае, если вы когда-нибудь развернете две разные кулинарные книги приложений на одном и том же образе, которые содержат такие ресурсы, как package "libssl-dev" здесь вы увидите предупреждение о клонировании ресурсов CHEF-3694. Поскольку в обеих кулинарных книгах есть ресурс, названный так же, как и вы столкнулись с этой проблемой, в какой-то момент мы действительно хотим, чтобы это исчезло, и мы действительно хотим перейти в мир, где package "libssl-dev" определяется только один раз в цикле шеф-повара.
Затем вы можете начать сбор этих зависимостей в общей кулинарной книге, которую будут включать все кулинарные книги вашего приложения (если они в основном одинаковы для всех приложений, которые вы развертываете). Или вы можете начать разбивать их на разные подтипы приложений или очень подробно описывать специализированные кулинарные книги, такие как кулинарные книги opscode xml и zlib.
Я бы посоветовал создать "платформенную" поваренную книгу, в которой собраны все виды разного базового материала, который вы хотите использовать на всех ваших платформах (установите lsof, tcpdump, strace, zsh, htop вместе со всеми RPM-dev / -devel и debs, которые вам обычно нужно). Пока этот список вещей для установки не станет слишком громоздким, вам придется его разбить.
Все это спорно, хотя, и преимущество более мелкозернистых поваренные книги является то, что вы понимаете, ваши зависимостей намного лучше, и ваши пробеги повар должен иметь меньше ресурсов и меньше. Это своего рода компромисс между управляемостью и точностью. Лучше всего вам «следует» разбить их всех. Но если слишком много «надо» начнут мешать реальной работе, я буду консолидироваться.
Berkshelf, test-kitchen и правильное интеграционное тестирование кулинарных книг значительно упрощают создание небольших специализированных кулинарных книг, но там есть кривая обучения, и, вероятно, лучше не зацикливаться на разборке, устанавливая libssl-dev в свою собственную кулинарную книгу пока не выйдете дальше по дороге.