TL; DR
Вы используете ограничение от DSL Chef таким образом, что оно не предназначено для использования. Вы должны выполнять ветвление на основе логического выражения, а не ограничения метаданных. Я предлагаю несколько способов сделать это, используя String # to_f в качестве примеров (не рекомендуется, если вы заботитесь об уровнях исправлений при семантическом версионировании), а также более точный, но часто упускаемый из вида Gem: :. Версия 1007 *
Не используйте ограничение для ветвления
if chef_version '<= 12'
Вы пытаетесь использовать ограничение из DSL. Это ограничение имеет конкретную цель : объявлять версии chef-client, поддерживаемые кулинарной книгой, а не обеспечивать логическое ветвление. Не глядя на базовый код Chef для DSL, я бы сказал, что маловероятно, что выражение питает ваше выражение if-then так, как вы ожидаете. На данный момент, не обращая внимания на то, является ли это правильным шаблоном, вы можете попробовать получить текущую версию инструментов Chef несколькими способами:
Ветвление в версии chef-client, скорее всего, в виде Float (обычно это String). Например:
if Chef::VERSION.to_f <= 12
Получить значение узла из ohai с чем-то вроде:
if node['chef_packages']['chef']['version'].to_f <= 12
Анализировать значение непосредственно у клиента, например ::
depends %x(chef-client --version).split[1].to_f <= 12 ? 'ypg_tomcat' : 'yp_tomcat'
Однако во всех случаях вам придется иметь дело с тем фактом, что вам передают String, содержащую семантическое управление версиями, а не Float или Integer. Итак, вам нужно выяснить, как вы действительно хотите анализировать информацию, которая потенциально подвержена ошибкам (хотя, см. Ниже трюк, использующий Gem :: Version). В любом случае, если вы проанализировали его так, как хотите, вы можете сопоставить его, используя оператор сравнения, чтобы получить желаемое поведение ветвления.
Лучшие варианты
Вместо того, чтобы пытаться ограничить метаданные бизнес-логикой, вам, вероятно, следует переместить данные в атрибут. Рассмотрим атрибут, такой как node['yp_linko']['tomcat_cookbook'], который можно установить на основе какого-либо другого обнаруживаемого значения узла, кроме семантического контроля версий.
Другим подходом было бы объявить обе кулинарные книги зависимостью, а затем включить ту, которая вам нужна, в рецепт вашей поваренной книги yp_linko . Например, если вы не объявили несовместимые версии клиента-шеф-повара в кулинарных книгах Tomcat:
# metadata.rb
depends 'yp_tomcat'
depends 'ypg_tomcat'
# default.rb
if Chef::VERSION <= Gem::Version.new(12)
include ypg_tomcat::default
else
include yp_tomcat::default
end
И, наконец, вы должны подумать, имеет ли смысл в первую очередь запускать разные версии ваших клиентов Chef в рамках инфраструктуры. Может быть, бизнесу нужно это сделать, но это реальная проблема, которую вы на самом деле пытаетесь решить. Разветвление в ваших кулинарных книгах - это решение X / Y для решения проблемы инфраструктуры. Вполне вероятно, что у вас есть другие поваренные книги с аналогичными проблемами, поэтому, по крайней мере, стоит подумать, имеет ли смысл ставить всех ваших клиентов на одну версию, а не решать проблему на уровне поваренной книги.