我们现在在 Conjur 大量使用 Docker。 Jenkins 集成测试 - Docker，开发环境 - Docker，运送虚拟设备 - Docker。你明白了。我们的很多脚本中都有这样的行：
chef-runner --ssh Port=2200 -H root@$(boot2docker ip) mycookbook
我在 OSX 上开发，所以我使用 boot2docker 有一段时间了。但我真的很喜欢 docker-machine 发布时的功能集。它不仅允许部署到 VirtualBox，还可以与其他 Docker 工具很好地结合在一起。在过去的几个月里，我只使用 docker-machine。
但现在我们遇到了问题。
开发团队是分裂的：我们中的一些人正在使用 boot2docker 和一些 docker-machine。我们的自动化代码假定 boot2docker VM 已启动并正在运行。当出现这种问题时，我们有三种选择。
- 写代码。更新我们的自动化代码，使其更智能，并根据可用工具切换命令。
- 标准化。权威做出决定。或者我们有一个团队挤在一起，通过争论“唯一正确的方式”来强调每个人。
- 推迟。不要更改任何代码。让团队在每个人的基础上找到解决方案。
对于这种情况，我选择了#3。我将此功能添加到我的
~/.zshrc
：
chef-runner --ssh Port=2200 -H root@$(boot2docker ip) mycookbook
现在，当我在本地运行我们的脚本时，
boot2docker ip
只是
docker-machine
的别名。我将“使用 docker-machine”打印到 stderr，所以我不会忘记这是一个别名。自动化代码只读取标准输出。
不需要更改代码或开会，我只是与团队分享我是如何解决问题的。
群体如何做出决定让我着迷。在我的职业生涯中有几个工程团队，我观察到我们自然会按以下顺序评估我们的选择：
1. 编写代码。 2.标准化。 3.推迟。
但我观察到，最简单、最优雅的解决方案通常来自以下顺序：
1. 推迟。 2.标准化。 3. 编写代码。
我不 反对 标准化或编写代码。一定程度的架构和工具标准化对于您的团队的运作是必要的。如果不是经常需要编写代码，我就会失业。不过，推迟决定并不意味着失败。如果您正在编写无关紧要的代码，那么速度就没有任何意义。我将在以后的帖子中对此进行更多探讨。谢谢阅读！