远程连接本地和其他容器上的docker容器

Question

对于我们的开发调试简易性和部署问题，我们计划将我们的服务集中化。例如。

我有A，B，C和D等服务。其中A是我的开发代码（经常更改），B，C和D是依赖服务。

目前B，C和D计划远程部署，因为它们只是一个依赖项（Docker Container）我想要一种方法来调试/部署，以便

• 我的服务A可以在本地，它可以轻松连接远程Docker服务B，C，D
• 或者A可以某种方式部署到远程集群，它可以进行测试。

我想到了推送到注册表，但每个开发人员推送自己的快照都无法与其他图像联系起来。

注意：

• 我不想要Swarm类似的东西，但想要保持简单。
• 群集通过Docker Machine进行管理。可以更换吗？
• 这些服务由Docker Compose编织。

关于如何驾驶这个的任何建议？也是首选的方法是通过Docker。

Answer 1

与此分享我的经验的简化版本。要考虑在远程docker引擎上运行依赖项（B，C和D）是否值得麻烦，以下其中一项必须（通常）为真：

• 在一台开发人员计算机上运行依赖服务所使用的资源量是不切实际的。
• 初始化依赖服务的数据太麻烦了，因为大小或其他因素使得在本地运行过于繁琐。
• 依赖服务使用的数据会引起隐私问题

使用远程方法可能会丢失的东西有点吓人。

• 开发人员无法轻松控制正在运行的依赖服务的版本。如果这些服务是自定义的，则这一点尤为重要，因此可以在发现或修复问题时降级或升级版本。
• 在向第三方服务的较新版本过渡期间，它也可能是一个问题，因为并非所有开发人员都可以在支持它的分支上工作。
• 此外，没有移动性来快速跳回到较旧的分支/版本来修复或解决问题然后将其集成/测试到当前分支可能真的很令人沮丧，当你最需要它时（时间问题的情况！）

还有许多其他要点可以添加到这些列表中，但这些对我们来说非常重要。

我们最终采用了混合方法。

开发人员将在本地运行所有任务。我们减少了本地开发依赖服务所需的数据，因此他们可以在几分钟内在本地启动。使开发环境完全“离线”是一个巨大的优势。如果集中式系统发生故障，您的开发人员很快就会被沦为在停机期间漫游建筑物的大群僵尸。他们还能够在火车上把他们的笔记本电脑调高，并在必要时调试一些奇怪的问题，然后承诺并让CI系统在他们的个人生活中继续进行测试和诸如此类的东西。

此外，我们启动了一些运行依赖服务的docker引擎的VM。这些（主要）有live和dev名称前缀（如果需要，还有其他名称），并包含来自实时环境的快照。如果需要，开发人员可以使用单独的组合设置。当开发人员试图确定由不良数据或代码导致的问题时，这可能是实际的，这些数据或代码只会因较大的数据集而严重缩放。

永远不会改变的是A将始终在开发人员计算机上运行。如果出于某种原因有人有其他需求，我们会启动一个带有docker引擎，一些数据快照和依赖服务的新VM。这是一个完全自动化的过程，因此需要一个完善且高效的管道。如果我选择启动个人设置，主机名可以使用我的用户名作为前缀。

我会说开发人员是否可以在本地运行所有内容，然后从大量工作中解脱出来并做到这一点。找到智能方法，让所有依赖服务在几分钟内顺利运行。

数据依赖性和隐私问题

我会在这里注入这一点，因为太多人忽略了这一部分。

现在GDPR和Privacy Shield很可能会在2018年对隐私问题施加更大的压力（至少你存储有关欧盟公民的数据），你的公司将不得不严肃对待或者可能面临巨额罚款和/或客户放弃你。这增加了一些工作量。

• 本地服务的所有图像都包含生成的数据或不可能用于识别个人的实时数据的变换子集。
• 远程dev和live主机还包含转换数据以隐藏身份，但简化了一点以大大加快了进程。
• 只有一小部分开发人员可以访问实时系统，这些也是唯一允许使用实时数据运行自己的VM的人（他们获得了该主机的唯一客户端证书）。

开发人员每天携带笔记本电脑旅行，甚至带回家。任何包含任何形式的个人信息的数据都不会落在开发者的笔记本电脑上。

Answer 2

我同意格瑞米的答案，但只是为了增加一些颜色，我想我会描述我们去年使用的系统效果很好。基本上，我们尝试在开发机器上尽可能地镜像我们的prod环境。我们直接在实例上运行一些服务（mongo，haproxy，etcd），其他一切都在Docker中运行。所以在开发机器上，除了Vagrant之外，我们也是这样做的。实际上，我们所有的AWS环境基本上都与prod环境相似，只是加上或减去规模/冗余。所有可以轻易重建的一次性“牛”。

我们有自己内置的古怪的小码头编排系统（pre-k8，pre-swarm），它基本上采用了“应该运行的东西”的声明性清单并将其粘贴到etcd中。然后，在每个系统上的docker中运行的代理（对于vagrant，只有一个）检查图像和配置签名以查看实际运行的内容，如果有任何缺失则运行它。 （如果有任何不应该运行的东西，那就杀了它）。对于网络路由，有一些可怕但令人惊讶的haproxy操作通过来自etcd的confd模板，我不想再次触摸:-)将请求路由到正确的docker后端，支持蓝绿色部署。

对于开发工作，它完全一样。但是对于快速开发循环，你不想一直重建容器，这很烦人。因此，在集群清单中，我们可以指定一个神奇的小标记，将一个服务标记为“在主机上”。这通过相同的etcd / confd / haproxy的东西，但后端是你的开发系统！这里的好处是，您可以通过在prod中运行的完全相同的haproxy设置获得https路由到您正在测试的服务。

这是一所古老的学校，但我们喜欢haproxy。 :-)

所以基本上，努力尽可能接近本地系统上完全孤立的产品环境。哦，努力争取不成为宠物。