Chef Policyfile.rb `include_policy` не гарантирует неизменность зависимости политики

Question

Допустим, у меня есть Polcyfile.rb в кулинарной книге под названием motd:

    name 'motd'
    default_source :chef_repo, "../"
    include_policy "Policyfile", path: "../environment"
    run_list 'motd'

и recipes/default.rb:

file '/etc/motd' do
  content node['message']
end

У меня есть другая кулинарная книга под названием environment который имеет файл Policyfile.rb:

name 'environment'
default_source :chef_repo, "../"
run_list 'environment'

Он имеет пустые recipes/default.rb и attributes/default.rb с:

default['message'] = 'i am a message'

Я запускаю chef install Policyfile.rb в environment dir для создать файл блокировки. Когда я запускаю kitchen converge из motd dir, а затем kitchen login, я получаю ожидаемый вывод на консоль:

This system is built by the Bento project by Chef Software
More information can be found at https://github.com/chef/bento
i am a message

Теперь я go и обновляю environment/attributes/default.rb до

default['message'] = 'i am updated'

I НЕ запускайте chef update Policyfile.rb для environment и снова запускайте kitchen converge из motd. Я ожидаю, что kitchen login не будет отражать мое обновление, потому что Policyfile.lock.json в motd не обновил свой revision_id для включенной политики environment. Но, к моему большому удивлению, я действительно вижу обновленное сообщение в консоли. Я вижу, что Policyfile.lock.json имеет новый root revision_id, а cookbook_locks->environment->identifier изменился. Но все же я бы подумал, что в этом случае, если поваренные книги в моей зависимости Policyfile.rb изменились и не вычисляются для соответствия ha sh его Policyfile.lock. json revision_id, тогда я все равно должен см. старый вывод, или здесь должно быть какое-то другое предупреждение.

Думаю, я просто пытаюсь понять концепцию здесь более полно. С одной стороны, root revision_id на motd изменилось, так что я достиг идемпотентности в одном смысле. Но, с другой стороны, зависимость revision_id для environment и ее рецептная книга компонентов не совпадают. Может кто-нибудь объяснить, почему это имеет смысл?

Answer 1

Похоже, есть ошибка или, возможно, особенность в способе взаимодействия chef install с test-kitchen. Все, что делает chef install, проверяется по номерам версий, и если вы обновите версию поваренной книги без регенерации с помощью chef update, вы получите исключение:

Error: Failed to install cookbooks from lockfile
Reason: (CookbookOmnifetch::CookbookValidationFailure) The cookbook downloaded for Cookbook 'xxxxxxx' = 1.2.3 {:path=>"."} did not satisfy the constraint.

Если вы измените поваренную книгу , test-kitchen запустит chef install и синхронизирует файлы поваренной книги с виртуальным экземпляром, который вы создаете, и запустит против них chef-client, что означает, что любые локальные изменения будут приняты автоматически без необходимости применения chef update .

Это не то, как это происходит в производственных настройках, так как вам нужно использовать chef push для загрузки кулинарных книг в репозиторий cookbook_artifacts, версия которого контролируется ша поваренной книги. Поскольку клиент извлекает cookbook_artifact на основе sha в файле блокировки, во время развертывания это не удастся. Поскольку test-kichen не использует chef push, у него нет функций неизменяемости, которые вы видели бы при развертывании.

Можно утверждать, что это функция тестовой кухни, иначе тестовая кухня потребовала бы для переключения на постоянное выполнение chef update каждый раз по умолчанию или для принудительного запуска пользователей вручную chef update между запусками. Но сохранение файла блокировки, отражающего производство, так что рабочий процесс должен повторять поваренную книгу и регенерировать файл блокировки только тогда, когда приходит время pu sh, может быть функцией рабочего процесса. Если кто-то считает, что это действительно опасная ошибка, вы можете открыть проблему для test-kitchen или chef-cli, чтобы исправить ее (но вам нужно будет спорить с убедительными функциями рабочего процесса, а не с философией). То, что тестовая кухня не является неизменной, хотя и не имеет никакого отношения к неизменности файлов политик в производственных настройках, хотя, я думаю, именно об этом и идет этот вопрос.

Answer 2

revision_id не замораживает зависимость. Не имеет значения, является ли это поваренной книгой в списке выполнения или зависимостью. Для блокировки используется только версия кулинарной книги.

Представьте, что у вас уже есть файл блокировки, например, с вашей версией environment кулинарной книги и путем к набору кулинарной книги.

[...]
"cookbook_locks": {
  "environment": {
    [...]
    "source": "../environment"
  }
}
[...]
"solution_dependencies": {
  "Policyfile': [
    ["motd", "= 1.2.3"],
    ["environment", "= 2.7.8"]
  ]
}
[...]

Тогда, если и только если вы измените версию поваренной книги в ../environment/metadata.rb, вы получите сообщение об ошибке, в котором говорится, что конкретная версия поваренной книги не найдена. В этом случае вам необходимо повторно создать файл блокировки.

Любые другие изменения в кулинарной книге не вызывают ошибок. И это ожидаемое поведение. Представьте себе, что если бы вам приходилось повторно создавать файлы блокировки для каждого внесенного вами изменения, это было бы очень накладно.

Думайте о revision_id в файле политики как о версии файла политики. Поскольку нет такой концепции, как обратная совместимость для файлов политик, нет необходимости использовать semanti c версионирование, и в этом случае достаточно длинной уникальной не так случайно сгенерированной строки в качестве версии. И именно поэтому chef show-policy покажет вам версии файлов политик, примененных в определенных группах политик, чтобы показать, что эта версия развернута в этой группе.