Назад | Перейти на главную страницу

Ruby / Chef include_recipe и знать переменные из родительского файла?

Я пытаюсь использовать локальную переменную во включенном файле. Я получаю ошибку, это не определено. Я не знаю, как это сделать, а вы? У меня есть папка с рецептами:

recipes/
    development.rb
    testing.rb
    config.rb

development.rb

username = "vagrant"
static = []
django = ["project1", "project2"]

include_recipe "server::config"   # <-- Trying to use static and django in there.

config.rb

static.each do |vhost|  #  <-- How do I get the "static" var in here?
    ...
end

django.each do |vhost|  #  <-- How do I get the "django" var in here?
    ...
end

Вы не можете совместно использовать переменные между рецептами, но есть два способа обмена данными между рецептами.

  1. Предпочтительным путем было бы экстернализация static и django как атрибуты в attributes/default.rb. Это означает, что они станут доступны на node объект и доступный из каждого рецепта.

атрибуты / default.rb

default["server"]["static"] = []
default["server"]["django] = ["project1", "project2"]

рецепты / config.rb

node["server"]["static"].each do |vhost|
  ...
end

node["server"]["django"].each do |vhost|
  ...
end
  1. Использовать Библиотеки шеф-поваров чтобы создать общий метод, возвращающий эти массивы.

Я предлагаю обязательно придерживаться первого варианта, это наиболее распространенный подход. Надеюсь, это поможет!

Немного поздно для вечеринки по этому поводу, и я думаю, что принятое решение является предпочтительным вариантом здесь, но ...

Можно установить переменную в «родительском» рецепте и использовать ее во включенном рецепте, изменив узел при сходимости, например.

node.default['django'] = ["project1", "project2"]

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

Что касается того, является ли это наилучшей практикой, я приветствую комментарии, но это казалось проще, чем писать ресурс для упаковки git lwrp.