【问题标题】:How to stage, develop, and test changes to the chef repo如何暂存、开发和测试 Chef 存储库的更改
【发布时间】:2017-07-18 02:27:14
【问题描述】:

我想问一下什么是最佳实践,以及测试和开发对食谱、环境、节点(主要是 Chef 存储库)的更改的常见做法。我问这个的原因是当前设置有一个厨师服务器。所有环境(staging、beta、prod)都使用这个服务器,并从这里提取所有相关信息。

但是,当我想对食谱进行更改并在我们的一个暂存环境中对其进行测试时……它从这个 repo 中提取,我要么必须进行混乱的配置更改,要么……上传食谱使用不同的名称,测试,然后继续将我的食谱重命名回原来的名称。远非高效,甚至令人沮丧。

我想也许我可以有不同的 git 分支并以某种方式将它们指向不同的方向,但它仍然会从我想象的同一个 repo 中提取..

我当时的想法是简单地拥有一个完全独立的 Chef 服务器,专门用于开发和测试,并将我的暂存环境指向该 Chef 服务器。

不知道我是否遗漏了另一种更简单的方法,因此我问社区。​​p>

这似乎与我问的另一个问题有关,但我希望这两个问题之间的区别很明显 (How to update chef cookbooks in a developer workflow)

【问题讨论】:

    标签: chef-infra


    【解决方案1】:

    正如 Stefan 所提到的,环境是这里的一种选择。您还可以查看环境说明书模式(类似但使用不同的工作流程来更新环境和管理运行列表,或者更新的 Policyfile 系统。如果可以的话,我建议从 Policyfiles 开始,尽管它们有一些限制并且可能不适用于所有团队。

    【讨论】:

    • 这个想法行得通,因为我指定了一个环境来使用最新的食谱版本(环境文件中的cookbook_version)并上传我的开发文件,同时在生产环境文件(通过相同的 cookbook_version 属性)。因为 prod 环境不会选择最新的,而 test env 会,所以不会有问题。我理解正确吗?
    • 是的,但正如我所说,您应该从 Policyfiles 开始。
    • 同样的问题,但不同的领域 - 我们在我们的堆栈中使用了一些 AWS opsworks,尽管我没有发现任何说我可以版本和固定食谱或任何明确使用策略文件的示例。这在 opsworks 中不可用吗?
    • 正确,OpsWorks Stacks 与所有工作流任务的普通 Chef 无关。你必须接受他们,我们没有输入或控制权。
    【解决方案2】:

    厨师有不同环境的概念:https://docs.chef.io/environments.html

    您可以拥有将所有相关说明书固定到稳定版本的 prod 和 staging 环境文件。

    然后,当您对您的说明书进行更改时,您应该增加版本号并使用新版本更新暂存环境,以便您可以在那里测试更改。 IE。

    chef exec knife environment from file environments/staging.json
    

    然后,只有在您测试了更改并且对它们感到满意时,才使用新版本更新 prod 环境。

    【讨论】:

      猜你喜欢
      • 2023-02-05
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-04-16
      • 1970-01-01
      相关资源
      最近更新 更多