我目前正在研究使用盐为我们的一些项目存储库提供开发虚拟盒子。我假设我们将在某个阶段设置一个 salt-master 服务器，因为我们可能也希望使用 salt 来配置部署框。
但是，我正在努力弄清楚如何处理工作节点密钥 - 假设我有一个项目存储库MyRepo这是一个简单的 Web 服务，我希望能够vagrant up并在本地运行非常快。
现在，我在网上找到的大多数资源都说我应该进入我的 salt-master 服务器，运行 salt-key --gen-keys=my-repo 来生成密钥，然后将它们与 minion.conf 一起复制到我的项目存储库中，因此结构类似于：-
|--MyRepo/
|-- salt/
|-- minion.conf
|-- keys/
|-- my-repo-pem
|-- my-repo.pub
很好，除了现在我的存储库包含密钥，我们的一些东西可能是开源的，所以在这个系统中，我们要么维护两个存储库(愚蠢(，要么将密钥提交到存储库(愚蠢？
我接下来想出的想法是，与其为每个项目制作工作节点密钥，不如让每个开发人员以自己的名义创建自己的工作节点密钥，例如 ptinkler，然后将它们scp到.salt/文件夹或类似文件夹下的本地home_dir，可能会将它们重命名为 minion.pem 并在此过程中minion.pub，以便它们可以像这样在VagrantFile中引用
home_dir = ENV['HOME']
config.vm.provision :salt do |salt|
salt.verbose = true
salt.minion_config = "#{home_dir}/.salt/minion.conf"
salt.minion_key = "#{home_dir}/.salt/keys/minion.pem"
salt.minion_pub = "#{home_dir}/.salt/keys/minion.pub"
salt.run_highstate = true
end
很好，虽然有点草率，我不喜欢重命名它们。
下一个想法是拥有一个包含所有项目键的私有 git 存储库，开发人员只需将该存储库拉下，然后在需要时将正确的文件夹符号链接到项目存储库中。这似乎也有点奇怪。这也意味着，在任何开源项目中，如果想要使用 Vagrant 来快速运行，那么将 repo 拉下来的人无论如何都不能使用盐来配置。
我基本上处于一个十字路口，关于我是否停止尝试使用 salt-master 并只是将我们的 repo 设置为无主(我不知道这将如何影响用 salt 部署它们的难度？(或者是否有办法配置它以让每个人都满意。
如果您的用例是使用 SaltStack 来配置本地 Vagrant 来宾，我建议您在无主模式下运行 Salt 进行配置。否则，第三方如何在无法访问您的 salt 主节点的情况下使用您的存储库？如果主节点不是其计算机的本地版本，开发人员将如何测试不同版本的盐状态？
您可以拥有一个多机流浪环境并运行专用的盐主机器。但你应该瞄准的是让你的开发环境尽可能包容——这与"流浪者的道"是一致的。
获取用于主/工作节点部署的盐状态并调整这些状态以在无主 Vagrant 设置中使用应该不会太困难。我建议你走这条路。两条可靠的资源可以开始走这条路——
- Salt
- Master 快速入门 来自 SaltStack 文档
- 流浪盐供应器文档