使用Foreman 1.6.0.53附带的Satellite 6。 默认情况下，Puppetlabs的文档指出，hieraconfiguration应该在$config/hiera.yaml 。 # puppet config print confdir hiera_config confdir = /etc/puppet hiera_config = /etc/puppet/hiera.yaml 看看我们的hieraconfiguration： # cat /etc/puppet/hiera.yaml — :backends: yaml :yaml: :datadir: /var/lib/hiera :hierarchy: – users – groups – global 数据文件存在： # cat /var/lib/hiera/users.yaml — users: bfernandez: uid: 300 fullname: Belmin Fernandez 而且，为了testing它，我使用hiera的CLI和一个puppet apply ： # hiera –conf=/etc/puppet/hiera.yaml –debug -h users […]
我正在和领class（学习工头和docker工人）一起玩，想尝试docker的方法。 使用docker集线器的官方集装箱 在任何地方都找不到docker文件。 当我从容器中启动容器时，如何找出执行哪个文件？ 我问的原因是我希望容器使用主机的两个networking接口，一个用于Web-UI，另一个用于在单独的专用networking上分配DHCP和DNS。 如果我用'bash'执行容器，我可以通过我的dns和dhcp代理networking的configuration选项，但是我失去了所有其他的好处，即SSL证书，pipe理员证书，…
我刚刚安装了工头，我不知道如何去把我所有的configuration在版本控制。 我知道我可以使用Git来安装我在Puppet master上的每个模块，但是更喜欢一个更全面的解决scheme，它不仅包含模块，还包含与每个主机相关联的类以及主机上设置的任何variables。 任何build议将不胜感激与相关的工作stream程。 如果是相关的，我将GitLab设置为现场的中央Git服务器，并计划尽快安装一个CI服务器，如Jenkins。
我几乎不知道木偶问这个问题。 我想我明白，特定节点的configuration将由一些模块组成，并附带一些特定于节点的粘合剂。 从教程和文档可以看出，特定于节点的资源将位于node /nodename/ { }资源中的manifest / site.pp文件中，其中包含相关类的“includes”，以及使节点特定的资源configuration更改。 现在input一个外部节点分类器（ENC），如theForeman。 从我阅读的ENC文档中，我可以使用site.pp中的node /nodename/ { }资源，但是我不能声明任何新的资源。 基本上不推荐。 生成的YAML只是包含和可变的设置。 那么对于给定节点或主机组的特定configuration，这个接口是怎么做的？ 你最终创build一个特定于节点的类吗？ 你在哪里把这个类，在一个特定于节点的模块？ 或者，您是否为您的特定于站点的configuration创build了一个全面的模块，并使用可以分配给特定节点的类？
我们正在遇到一个有趣的争论，正在陷入两个阵营。 我感兴趣的任何想法或陷阱我们可能会失踪的任何特定的问题。 真的，任何能够帮助我们做出决定的东西，或者指出我们没有考虑到的事情。 我知道这个裙带着“无意见”的规则，但我希望这仍然是一个可以接受的问题。 对不起，长度也有一些微妙的差别。 1）一方（我 – 我不是没有偏见）发现云系统非常有趣的不变的服务器模型。 为此，我们将基础架构的所有组件移植到Docker中。 我们的自定义应用程序通过Jenkins直接构build到部署到本地Docker Registry的Docker镜像中。 然后，我们创build了一大组Ansibleangular色和一个能够伸手去找空服务器的剧本，安装Docker，然后告诉Docker根据需要安装所有的容器。 几分钟后，整个应用程序及其所有的支持基础架构就被连接起来并工作 – logging，监视，数据库创build/填充等。完成的机器是一个独立的QA或开发环境，具有应用。 我们计划扩大规模的计划是制作新的手册，从基础可信AMI（可能是一张非常光滑的图像）构build新的AWS服务器，对生产应用程序进行滚动部署以处理configurationpipe理和发布，而且通常不会再次编辑服务器 – 只是让他们重新。 我并不担心在实践中得到我所描述的工作 – 只要这是一个合理的模型。 2）另一个阵营希望使用Puppet来处理configurationpipe理，Ansible部署我们的自定义应用程序，这些应用程序是我们构build过程中生成的压缩包，Foreman负责处理整个stream程的触发和pipe理，Katello做一些基础图像pipe理。 发布将涉及Puppet根据需要更改configuration和Ansible部署更新的组件与一定数量的工头协调。 如果我们需要新的服务器，那么服务器的build立就会相当快，但是不要把它们作为标准stream程的一部分来处理。 尽pipe使用寿命长，但它更接近凤凰服务器模式。 所以我的问题真的归结为这个：是不是一成不变的服务器模型，我已经用上面描述的这些工具实际上是现实的了？ 我喜欢这样一个想法，即我们的暂存过程实际上可以在现场构build完整的应用程序副本，让QA锤击它，然后只是翻转数据库存储和一些DNS设置以使其生存。 还是不可变的服务器模型在实践中失败？ 我们在AWS和云环境方面拥有丰富的经验，所以这不是关注的问题 – 更重要的是如何让一个相当复杂的应用程序可靠地部署到今后。 这是我们特别感兴趣的，因为我们经常发布。 我们有Ansible，除了为我们创buildEC2服务器之外，还需要做大部分工作，这并不困难。 我很难理解为什么你真的需要木偶/工头/ Katello在这个模型中。 Docker比任何自定义的部署脚本更加清洁和简单。 Ansible似乎比Puppet简单得多，当你不必担心必须现场configuration它们，而只需使用新configuration再次构build它们。 我是KISS校长的粉丝，尤其是在墨菲法则猖獗的自动化领域。 国际海事组织越好，机械越less。 任何想法/意见或build议的方法将不胜感激！