gpt4 book ai didi

deployment - apt::source 和阶段的 puppet 问题

转载 作者:行者123 更新时间:2023-12-03 17:21:42 24 4
gpt4 key购买 nike

我已经完成了本地 Puppet 安装:

# puppet module install puppetlabs/apt  
Preparing to install into /etc/puppet/modules ...
Downloading from http://forge.puppetlabs.com ...
Installing -- do not interrupt ...
/etc/puppet/modules
└─┬ puppetlabs-apt (v1.1.0)
└── puppetlabs-stdlib (v3.2.0)

我还有以下 nodes.pp我想申请的:
node default {                                                              
include stdlib

class {'apt':
always_apt_update => true,
disable_keys => true,
stage => 'setup'
}
->
apt::source { "cassandra":
location => "http://debian.datastax.com/community",
release => "stable",
repos => "main",
key => "B999A372",
key_source => "http://debian.datastax.com/debian/repo_key",
include_src => false
}
}

当我尝试应用它时,我得到:
# puppet apply nodes.pp
err: Could not apply complete catalog: Found 1 dependency cycle:
(Anchor[apt::key B999A372 present] => Apt::Key[Add key: B999A372 from Apt::Source cassandra] => File[cassandra.list] => Exec[apt_update] => Class[Apt::Update] => Stage[setup] => Stage[main] => Class[Main] => Node[default] => Apt::Source[cassandra] => File[cassandra.list])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz
notice: Finished catalog run in 0.12 seconds

问题似乎在于 stage => 'setup'参数,但我想了解发生了什么以及我可以做些什么来解决这个问题(我继承了一个大型 puppet 代码库 - 以上只是一个概念证明 - 它使用了 stage 的东西,我不我还不想删除它,因为我不太了解 Puppet 的内部工作原理)。

更新 #1

尝试移动 apt::source前往 setup阶段,像这样:
class cassandra {
apt::source { "cassandra":
location => "http://debian.datastax.com/community",
release => "stable",
repos => "main",
key => "B999A372",
key_source => "http://debian.datastax.com/debian/repo_key",
include_src => false
}
}

node default {
include stdlib

class {'apt':
always_apt_update => true,
disable_keys => true,
stage => setup
}
->
class {'cassandra': stage => setup}
}

但是,这并不能解决问题,只会产生另一个依赖循环。
err: Could not apply complete catalog: Found 1 dependency cycle:
(Anchor[apt::key B999A372 present] => Apt::Key[Add key: B999A372 from Apt::Source cassandra] => File[cassandra.list] => Exec[apt_update] => Class[Apt::Update] => Anchor[apt::update] => Class[Apt] => Class[Cassandra] => Apt::Source[cassandra] => File[cassandra.list])

完整调试输出 here .依赖图是 this

所以在我看来,试图以“自然”的方式(通过 -> 运算符)强制执行操作顺序会导致这种奇怪的依赖循环。

最佳答案

基本上看起来你的 apt::source 指定了一个键。 apt::key 的 apt::source 声明指出 apt::key 需要在添加文件 cassandra.list 之前进行处理。这是有道理的吧?

但随后 cassandra 文件资源有一个 Exec['apt_update'] 的通知,它存在于 apt::update 中。它是一个仅刷新包,仅由正在执行并通知它的 cassandra 文件资源触发。

Exec['apt_update'] 位于 apt::update 内部,因此需要对其进行处理才能使 Class['apt::update'] 被视为已处理。

现在实际问题发生在 apt 声明中。您已经使用元参数 stage => 'setup' 声明了 apt(apt 模块的初始化 list )。您会发现 apt 实际上包含 apt::update,这很好 - 但它还定义了一个 anchor 'apt::update',它需要类 apt::update。由于 apt 对 apt::update 的依赖,我们现在在设置阶段也隐含了对 apt::update 的依赖。

主要阶段取决于设置阶段,任何没有给出阶段的东西都会自动选择主要阶段 - 因此 File['cassandra.list'] 也是主要阶段资源(但需要在 apt::update 之前发生,即隐含的设置阶段资源!)

我希望这会有所帮助,它看起来很复杂——尤其是对于 anchor 。

关于deployment - apt::source 和阶段的 puppet 问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15384733/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com