gpt4 book ai didi

适用于多个应用程序的多个环境的 Puppet 架构

转载 作者:行者123 更新时间:2023-12-01 11:26:06 27 4
gpt4 key购买 nike

我的团队使用 Puppet 架构,该架构目前可在多个环境(流浪者、暂存、生产)中容纳单个应用程序。

我们现在想要扩展此设置的范围以支持其他应用程序。他们中的许多人将使用我们已经定义的现有模块的子集,而其他人将要求定义新模块(可能共享也可能不共享。)

什么是最合适的 Puppet 架构,以支持多个应用程序的多个环境?

在这样的架构中,每个应用程序大概相当于一个模块。什么是(文件)在结构上区分作为应用程序的模块和作为一个或多个模块的依赖项的模块的最佳方式?

是否可以像在顶级 applications 文件夹下添加第三个 modules 文件夹一样简单?还是有更好的分层策略?

到目前为止,研究还没有发现任何最佳实践示例/样板,例如通过 GitHub 上的 example42 或 puppetlabs。

我们的文件结构:

puppet
├── environments
│   ├── production → manifests → init.pp
│   ├── staging → manifests → init.pp
│   └── vagrant → manifests → init.pp
├── hiera.yaml
├── hieradata
│   ├── accounts.yaml
│   ├── common.yaml
│   └── environments
│   ├── production.yaml
│   ├── staging.yaml
│   └── vagrant.yaml
├── modules
│   ├── acl [..]
│   ├── newrelic [..]
│   ├── nginx [..]
│   └── puma [..]
└── vendor
├── Puppetfile
├── Puppetfile.lock
└── modules [..]

最佳答案

我敢肯定,对于“最合适”的解决方案是什么,有很多意见,但我会告诉你我的意见。

Puppet 实际上是为支持多个环境中的多个应用程序而设计的,开箱即用,但有一些值得注意的警告:

  • 所有公共(public)依赖项(在单个环境中)必须固定到同一版本
    • 因此,如果您有三个应用程序需要 Apache,那么您只能有一个 Apache 模块
  • 所有应用程序都可以使用独特的名称来引用
    • I.E.如果您有三个不同的 node.js 应用程序需要它们自己的模块,则您需要为它们提供三个唯一命名的模块(或 list )
  • 您愿意解决同时更新多个应用程序依赖项的维护/维护问题
    • 如果应用 1 需要更新 Apache 模块依赖项,您愿意确保应用 2-* 保持兼容

要记住的另一件事是 Puppet 的“环境”术语是 acknowledged misnomer .为了避免 environment leakage 的危险,我见过的大多数运行良好的环境实际上在每个真正的“环境”(vagrant/dev/stage/prod)中都有不同的 Puppet masters以及测试 Puppet 基础设施的升级(您应该有一个地方可以测试不会立即影响您的生产的 Puppet 版本的升级)

因此,这释放了 Puppet 的“环境目录”,使其在真正的“环境”概念之外运行,并且应该被视为“特定修订版的模块集合”而不是“环境”。您仍然需要意识到环境泄漏,但这确实为拆分模块开辟了一条潜在途径。

您需要牢记的另一个概念是角色和配置文件(Gary LarizzaAdrien TheboCraig Dunn 对此进行了深入讨论)。这些有助于将业务逻辑与技术管理模块分开。然后,您可以将依赖项排序和面向业务的逻辑与用于管理各个组件的代码/模块分开。

有了所有这些概念,这里有两种架构布局可能非常适合您的用例:

应用环境

puppet
├── environments (Managed by r10k/code manager)
│ ├── app1
│ │ └── modules
│ │ ├── profiles [..]
│ │ └── app1_specific_component [..]
│ ├── app2
│ │ └── modules
│ │ ├── profiles [..]
│ │ └── app2_specific_component [..]
│ └── app3
│ └── modules
│ ├── profiles [..]
│ └── app3_specific_component [..]
├── hiera.yaml
├── hieradata
│ ├── accounts.yaml
│ ├── common.yaml
│ └── applications
│ ├── app1
│ │ ├── default.yaml
│ │ └── environments (server environments)
│ │ ├── vagrant
│ │ │ └── roles
│ │ │ ├── role1.yaml
│ │ │ ├── role2.yaml
│ │ │ └── role3.yaml
│ │ ├── stg
│ │ │ └── roles
│ │ │ ├── role1.yaml
│ │ │ ├── role2.yaml
│ │ │ └── role3.yaml
│ │ └── prd
│ │ └── roles
│ │ ├── role1.yaml
│ │ ├── role2.yaml
│ │ └── role3.yaml
│ ├── app2
│ │ ├── default.yaml
│ │ └── environments
│ │ ├── vagrant
│ │ │ └── roles
│ │ │ ├── role1.yaml
│ │ │ ├── role2.yaml
│ │ │ └── role3.yaml
│ │ ├── stg
│ │ │ └── roles
│ │ │ ├── role1.yaml
│ │ │ ├── role2.yaml
│ │ │ └── role3.yaml
│ │ └── prd
│ │ └── roles
│ │ ├── role1.yaml
│ │ ├── role2.yaml
│ │ └── role3.yaml
│ └── app3
│ ├── default.yaml
│ └── environments
│ ├── vagrant
│ │ └── roles
│ │ ├── role1.yaml
│ │ ├── role2.yaml
│ │ └── role3.yaml
│ ├── stg
│ │ └── roles
│ │ ├── role1.yaml
│ │ ├── role2.yaml
│ │ └── role3.yaml
│ └── prd
│ └── roles
│ ├── role1.yaml
│ ├── role2.yaml
│ └── role3.yaml
├── modules (These are common to all environments, to prevent leakage)
│ ├── acl [..]
│ ├── newrelic [..]
│ ├── nginx [..]
│ └── puma [..]
└── vendor
├── Puppetfile
├── Puppetfile.lock
└── modules [..]

作为“发布”的环境(随着时间的推移对 Puppet 代码进行迭代)

puppet
├── environments (Managed by r10k/code manager)
│ ├── release_1
│ │ └── modules
│ │ ├── profiles [..]
│ │ ├── app1_specific_component [..]
│ │ ├── app2_specific_component [..]
│ │ ├── app2_specific_component [..]
│ │ ├── acl [..] (v1)
│ │ ├── newrelic [..]
│ │ ├── nginx [..]
│ │ └── puma [..]
│ ├── release_2
│ │ └── modules
│ │ ├── profiles [..]
│ │ ├── app1_specific_component [..]
│ │ ├── app2_specific_component [..]
│ │ ├── app2_specific_component [..]
│ │ ├── acl [..] (v1.1)
│ │ ├── newrelic [..]
│ │ ├── nginx [..]
│ │ ├── puma [..]
│ │ └── some_new_thing_for_release_2 [..]
│ └── release_3
│ └── modules
│ ├── profiles [..]
│ ├── app1_specific_component [..]
│ ├── app2_specific_component [..]
│ ├── app2_specific_component [..]
│ ├── acl [..] (v2.0)
│ ├── newrelic [..]
│ ├── nginx [..]
│ ├── puma [..]
│ ├── some_new_thing_for_release_2 [..]
│ └── some_new_thing_for_release_3 [..]
├── hiera.yaml
├── hieradata
│ ├── accounts.yaml
│ ├── common.yaml
│ ├── environments
│ │ ├── release_1.yaml
│ │ ├── release_2.yaml
│ │ └── release_3.yaml
│ └── roles
│ ├── role1
│ │ ├── default.yaml
│ │ ├── environments (server environments)
│ │ │ ├── vagrant
│ │ │ │ ├── defaults.yaml
│ │ │ │ └── release (optional, only if absolutely necessary)
│ │ │ │ ├── release_1.yaml
│ │ │ │ ├── release_2.yaml
│ │ │ │ └── release_3.yaml
│ │ │ ├── stg
│ │ │ │ ├── defaults.yaml
│ │ │ │ └── release (optional)
│ │ │ │ ├── release_1.yaml
│ │ │ │ ├── release_2.yaml
│ │ │ │ └── release_3.yaml
│ │ │ └── prd
│ │ │ ├── defaults.yaml
│ │ │ └── release (optional)
│ │ │ ├── release_1.yaml
│ │ │ ├── release_2.yaml
│ │ │ └── release_3.yaml
│ ├── role2
│ │ ├── default.yaml
│ │ └── environments
│ │ ├── vagrant
│ │ │ └── defaults.yaml
│ │ ├── stg
│ │ │ └── defaults.yaml
│ │ └── prd
│ │ └── defaults.yaml
│ └── role3
│ └── default.yaml
├── modules (Anything with ruby libraries should go here to prevent leakage)
│ ├── stdlib [..]
└── vendor
├── Puppetfile
├── Puppetfile.lock
└── modules [..]

请记住,嵌套顺序(发布/环境/角色等...)是灵活的,具体取决于对您的实现最有意义的顺序(如果您不打算使用它们,则可以消除一些顺序)。

我鼓励您仅将此信息作为一个起点,而不是具体的“立即成功”。与您在网上(包括我的)可能找到的假设和“千篇一律”类型的解决方案相比,拥有高技能的 Puppet Architect 与您合作以了解您的确切需求和环境最终会得到一个更好调整和更合适的解决方案。

关于适用于多个应用程序的多个环境的 Puppet 架构,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37070456/

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