我的团队使用Puppet架构,目前可以在多种环境中容纳单个应用程序(流浪汉,舞台,制作)。
我们现在希望扩展此设置的范围以支持其他应用程序。他们中的许多人将使用我们已经定义的现有模块的子集,其他人将要求定义新模块(可能会或可能不会共享。)
什么是最合适的Puppet架构,用于支持多个应用程序的多个环境?
在这样的架构中,大概每个应用程序都相当于一个模块。什么是(文件)结构上区分作为应用程序的模块和作为一个或多个模块的依赖的模块的最佳方式?
是否可以像在顶级modules
文件夹下添加第三个applications
文件夹一样简单?或者是否有更好的分层策略?
迄今为止的研究尚未发现任何最佳实践案例/样板,例如:通过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 [..]
答案 0 :(得分:5)
我确信对于最合适的'有很多意见。对此的解决方案是,但我会给你我的。
Puppet实际上是为了支持开箱即用的多个环境中的多个应用程序,但有一些值得注意的警告:
要记住的另一件事是Puppet的环境术语'是acknowledged misnomer。我见过的大多数操作良好的环境实际上都在他们真实的环境中拥有独特的Puppet大师。 (vagrant / dev / stage / prod)为了避免environment leakage的危险以及测试Puppet基础设施的升级(你应该有一个地方来测试升级到你的Puppet版本没有立即影响你的生产)
因此,这将释放Puppet环境目录'在没有真正环境的情况下运营概念,应该被视为特定版本的模块集合'而不是环境'。您仍然需要认识到环境泄漏,但这确实为分割模块开辟了一条潜在的途径。
您需要牢记的另一个概念是角色和个人资料(由Gary Larizza,Adrien Thebo和Craig 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
├── 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与您合作,以了解您的精确需求和环境,最终将得到一个比假设更好的调整和适当的解决方案,以及' cookie cutter'您可能在网上找到的解决方案(包括我的)。