远程连接本地和其他容器上的Docker容器
为了我们的开发debugging的简单性和less部署的问题，我们计划对我们拥有的服务进行容器化。 例如。
我有服务，如A ， B ， C和D 其中A是我的开发代码（经常变化），B，C和D是相关的服务。
目前， B ， C和D计划进行远程部署，因为它们只是一个依赖项（Docker Container），我想要一种debugging/部署的方式，以便
-
我的服务
A可以在本地，它可以很容易地连接到远程Docker服务B，C，D -
或者
A可以以某种方式部署到远程集群，并且可以进行testing。
我以为要推进registry，但每个开发人员都有自己的快照，不能与其他图像共同关联。
注意：
-
我不想Swarm类的东西，但要保持简单。
-
集群通过Docker Machine进行pipe理。 可以更换吗？
-
这些服务由Docker Compose编织而成。
任何build议，我怎么能驾驶呢？ 也是首选的方式是通过Docker。
分享我的这个经验的简化版本。 要考虑在远程docker引擎上运行依赖关系（ B ， C和D ）是否值得麻烦，以下情况之一必须（通常）为真：
- 依赖服务使用的资源量在单个开发人员计算机上运行并不实际。
- 初始化依赖服务的数据太麻烦了，因为大小或其他因素使得本地运行太麻烦。
- 依赖服务使用的数据引发了隐私问题
使用远程方法可能会失去的东西有点吓人。
- 开发人员无法轻松控制正在运行的依赖服务的版本。 这是特别重要的，如果这些服务是自定义的，所以他们可以降级或升级版本的问题被发现或修复。
- 在向更新版本的第三方服务转换时也可能是一个问题，因为并不是所有的开发者都可能在支持它的分支上工作。
- 另外，如果不能快速跳回到较早的分支机构/版本来修复或发布问题，然后将其集成/testing到当前分支，那么当您最需要它时（如果时间成问题的话，情况会非常糟糕！
还有很多要添加到这些列表，但这些对我们来说是重要的。
我们结束了一个混合的方法。
开发人员将在本地执行大部分任务。 我们减less了为当地发展提供服务所需的数据，所以他们可以在几分钟内在当地启动。 使开发环境完全“脱机”是一个巨大的优势。 如果一个中央系统发生故障，你的开发人员很快就会沦落为在停机期间漫游大楼的一群僵尸。 他们还有能力在火车上打开他们的笔记本电脑，并在需要时debugging一些奇怪的问题，然后承诺，让CI系统咀嚼testing，而不是一边继续他们的个人生活。
另外我们启动了一些运行docker引擎的虚拟机。 这些（主要） live和dev名称前缀（和其他人，如果需要），并包含从现场环境的快照。 如果需要，开发人员可以使用单独的组合设置。 当开发者试图确定由不好的数据引起的问题或者用更大的数据集严重缩小的代码时，这是可行的。
A永远不会改变的是A会永远在开发者电脑上运行 。 如果某个人出于某种原因有其他需求，我们启动一个新的虚拟机与docker引擎，一些数据快照和相关服务。 这是一个完全自动化的过程 ，所以这需要一个完善的和有效的pipe道。 如果我select开始个人设置，则主机名可以使用我的用户名作为前缀。
我想说，如果开发人员可以在本地运行所有的东西，那么可以把自己从大量的工作中解放出来，做到这一点 find聪明的方法，让所有依赖的服务在几分钟内顺利运行。
数据依赖性和隐私问题
我也会在这里注明这一点，因为太多的方面忽略了这一部分。
现在GDPR和Privacy Shield很可能会给2018年的隐私问题带来更大的压力（至less在你存储有关欧盟公民的数据的时候），你的公司将不得不认真考虑这个问题，否则可能面临巨额罚款和/或客户抛弃你的问题。 这增加了一些工作。
- 本地服务的所有图像包含生成的数据或不能用于识别个体的实时数据的变换子集。
- 远程
dev和live主机也包含转换的数据以隐藏身份，但简化了一些，大大加快了进程。 - 只有一小部分开发人员可以访问实时系统，这些也是唯一允许用实时数据运行自己虚拟机的虚拟机（他们获得了该主机的唯一客户端证书）。
开发人员每天都会使用笔记本电脑，甚至将其带回家。 包含任何forms的个人信息的数据将永远不会在开发人员笔记本电脑上结束。
我同意格林美的回答，但只是为了增加一些颜色，我想我会描述一下我们去年使用的系统的效果。 基本上，我们试图在开发机器上尽可能接近我们的产品环境。 我们直接在实例上运行一些服务（mongo，haproxy，etcd），其他所有的东西都在Docker中运行。 所以在开发机器上，除了Vagrant，我们也是这样做的。 实际上，我们所有的AWS环境基本上都与产品环境相似，只是加/减缩放/冗余。 所有一次性“牛”，可以轻松重build。
我们有自己的古怪的小docker编制系统（pre-k8，pre-swarm），它基本上采用了“应该运行的东西”的声明性清单，并将其粘贴到etcd中。 然后，在每个系统的docker上运行的代理程序（对于vagrant来说，只有一个）将检查映像和configuration签名，以查看实际正在运行的内容，以及是否缺less任何内容。 （如果有什么东西在跑，那不该是杀了它）。 对于networking路由，通过etcd的confd模板，有一些令人恐惧但令人惊讶的haproxy操作，我不想再次触摸:-)，它将请求路由到正确的docker后端，支持蓝绿色的部署。
对于开发工作来说，它们完全一样。 对于快速的开发循环，你不需要一直重build集装箱，这很烦人。 因此，在集群清单中，我们有一个神奇的小旗子，您可以指定将一个服务标记为“在主机上”。 这通过相同的etcd / confd / haproxy的东西，但后端是你的开发系统！ 这里最大的好处就是你可以通过在prod中运行的完全相同的haproxy设置，将https路由到你的服务。
这是一个有点老派，但我们喜欢 haproxy。 🙂
所以基本上，要尽可能地接近你本地系统中完全孤立的产品环境。 哦，并努力刺激不成为宠物。