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

Question

对于我们的开发调试简单性和部署问题，我们计划对我们拥有的服务进行容器化。例如。

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

目前B，C和D计划远程部署，因为他们仅仅是依赖（泊坞容器） 我会想办法调试/部署，使

• 我的服务A可在本地和它可以很容易地与远程多克尔服务B，C，连接D

• 或者A可能以某种方式DEP借用到远程集群并且可以进行测试。

我认为要推进注册表，但每个开发人员推出自己的快照都无法与其他图像共同关联。

注：

• 我不想群之类的话，但要保持它的简单。

• 群集通过Docker Machine进行管理。它可以被替换吗？

• 这些服务由Docker Compose编织而成。

有关我如何驾驶的建议？另外首选的方法是通过Docker。

Answer 1

分享我的这个体验的简化版本。要考虑是否在远程泊坞窗发动机运转依赖（B，C和D）甚至是值得冒这个险，必须执行以下中的一个（通常）是真实的：

• 资源由不同的服务使用量不适合在单个开发人员计算机上运行。
• 初始化依赖服务的数据过于麻烦，因为其大小或其他因素使其在本地运行时太繁琐。
• 通过根据服务使用的数据引发隐私担忧

什么你可能使用远程方式失去的是一个有点吓人。

• 开发人员无法轻松控制正在运行的依赖服务的版本。如果这些服务是自定义的，这一点尤其重要，以便在问题被发现或修复时降级或升级版本。
• 在转换到更新版本的第三方服务时，它也可能是一个问题，因为并非所有的开发人员都可能在支持它的分支上工作。
• 此外，如果您不需要快速跳回旧版本的分支机构/版本来修复或发布问题，然后将其集成/测试到当前分支，那么当您最需要它时可能会非常沮丧（时间是问题！）

还有很多要添加到这些列表的其他要点，但这些对我们来说很重要。

我们结束了一个混合的方法。

开发人员将在本地为大多数任务运行一切。我们削减了为当地发展提供服务所需的数据，以便他们可以在几分钟内在当地启动。使开发环境完全“脱机”是一个巨大的优势。如果一个中央系统发生故障，您的开发人员将迅速减少到在停机期间漫游大楼的一群僵尸。他们还有能力在火车上打开他们的笔记本电脑，并在需要时调试一些奇怪的问题，然后做出承诺，并让CI系统咀嚼测试，以及在他们继续个人生活的同时进行测试。

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

从未改变的是A将始终运行在开发人员计算机上。如果某人出于某种原因有其他需求，我们会启动一个新的VM，其中包括码头引擎，一些数据快照和相关服务。这是一个完全自动化的流程，所以这需要一个完善的高效管道。如果我选择开始个人设置，则主机名可以使用我的用户名作为前缀。

我想说的是，如果开发人员可以在本地运行所有东西，那么可以将自己从大量工作中拯救出来并做到这一点。在几分钟内找到聪明的方式让所有依赖的服务顺利运行。

数据相关性和隐私问题

，因为太多的忽略了这一部分，我将在这里注入了这一点为好。

既然GDPR和Privacy Shield最可能在2018年给隐私问题带来更大的压力（至少在你存储有关欧盟公民的数据时），你的公司将不得不认真对待或者可能面临巨额罚款和/或客户抛弃你。这增加了一些工作。

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

开发人员每天都会随便携笔记本电脑出行，甚至将其带回家。包含任何形式的个人信息的数据最终都不会在开发人员笔记本电脑上出现。

Answer 2

我同意格林美的回答，但只是为了增加一些颜色，我想我会描述一下我们去年使用的系统的效果。基本上，我们尽量在开发机器上尽可能接近我们的产品环境。我们直接在实例上运行一些服务（mongo，haproxy，etcd），而其他一切都在Docker中运行。所以在开发机器上，除了Vagrant之外，我们也是这样做的。实际上，我们所有的AWS环境基本上都与产品环境类似，只是加/减缩放/冗余。所有一次性“牛”，可以轻松重建。

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

对于开发工作，其全部完全相同。尽管如此，对于快速开发循环而言，您不需要随时重建集装箱，这很烦人。因此，在集群清单中，我们有一个神奇的小标志，您可以指定将一个服务标记为“在主机上”。这通过相同的etcd/confd/haproxy的东西，但后端是你的开发系统！这里最大的好处是你可以通过在prod中运行的完全相同的haproxy设置，将https路由到你的服务中。

这是一个有点老派，但我们爱 haproxy。 :-)

因此，基本上，努力尽可能地接近您本地系统上完全隔离的产品环境。哦，并努力刺激不成为宠物。