我正在开始一个新项目,我想用它SaltStack来管理跨多个数据中心的大型部署.一切都在Linux上运行.我之前有过经历,Chef但我比较新SaltStack.我的目标是将整个项目保存在一个git存储库中,并使SaltStack从此存储库中提取配置并将其应用于minions.似乎SaltStack没有版本控制的概念,但是提供来自存储库中不同分支的内容会更好.所以,我正在考虑创建一个以下结构的git存储库:
salt -+- config (for salt-master config files)
+- states
+- pillars
+- reactors
+- formulas
并使用不同的分支dev, qa和prod环境.我也想pillars用于提供数据中心特定的配置,我想GitFS用来粘合所有东西.
然而,有一些讨厌的top.sls文件以非常特殊的方式处理,不适合这张图片并最终打破这个概念.
还有,我想继续在这个仓库的配置文件,但我现在其他然后手动复制或符号链接他们下没有更好的办法/etc/salt从config目录.
我经历了几次文档并在模拟环境中做了一些实验,但我还没有想出任何合理的项目布局,所以我到达了stackoverflow社区.
我的问题是:
听起来你正朝着一个合理的方向前进。我们没有像您那么大的操作（例如，我们还没有使用多个环境，只是base；我们不使用反应堆等），但我们有与我们的主要状态存储库类似的布局。
以下是我们采取的一些做法：
我们使用 Fabric 脚本将配置和更新的状态/支柱从存储库部署到 salt-master。Fabric 脚本还具有引导带有 salt-minion 的新机器并自动与 master 进行密钥交换的任务。
我想我们可以使用 GitFS，但我在设置它并可靠地应用更新的变更集时遇到了一些麻烦。理论上，您可以引导 salt 自行部署，但实际上，单独的、有限的部署过程就足够了。
我们将所有“秘密”作为支柱文件保存在单独的存储库中，以将它们排除在我们的主存储库之外。我们的部署脚本检查这些并将它们部署到 salt-master 上 /srv/pillar 树中的正确位置。这使我们能够将敏感数据（密码、密钥对等）保留在我们的主存储库之外。我们使用 salt 在开发人员机器上配置 Vagrant VM，因此“开发秘密”存储在主存储库中。