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

Question

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

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

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

• 我的服务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环境相似，只是加上或减去规模/冗余。所有一次性＆＃34;牛＆＃34;这可以简单地重建。

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

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

这是一所古老的学校，但我们爱 haproxy。 ： - ）

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