「CSDN」Docker 开发环境正在崩坏！( 二 )

本文插图
容器是开发人员友好的抽象吗？一个容器，就 Docker 而言：
是一种标准的软件单元，可以将代码及其所有依赖关系打包，使应用程序能够快速可靠地从一个计算环境运行到另一个计算环境上。
容器是应用层的一个抽象，它将代码和依赖关系打包在一起。
听起来不错，对吧？是的，特别是当你试图部署代码的时候，你会发现的确如此。换句话说，如果我主要关心的是让我们的代码在任何地方都能毫无意外地运行，那么容器似乎是目前最好的抽象——我并不真的需要了解我们正在运行的代码，相反，我需要对我们将如何运行它有一个可预测性。作为一个操作人员，这点非常棒。但是，作为一个开发人员，这种抽象可能会带来一些麻烦。容器并不真正关心自己在运行什么。操作系统是有目的地抽象出来的，运行容器所必需的任何依赖项也是如此。应用程序层本身和底层操作系统一样短暂，访问这些抽象层需要了解 Docker 希望以何种方式运行代码。尽管我已经谈到了容器的预期用途，但我认为说容器只是团队运营的东西的说法是错误的。我认为开发人员可以从容器化开发环境中受益。问题在于构建一个真正的开发人员友好的、基于容器的工作流并不容易。
基于 Docker 的开发环境的常见缺陷最后，我选择在自己的开发工作中多次使用 Docker 。这对我来说很有效，尤其是对于我每天所做的工作来说。在 Test Double ，更重视 Dev Ops 和 SRE ，我在这里每天都和容器打交道。当然，这可能不适合你的团队。但是，如果你确实希望在开发环境中使用 Docker 进行，我会提醒你注意一些我亲身经历过的常见陷阱。

假设容器化只有优点

在容器化的开发环境中，最大的陷阱可能是假设你在部署中获得的好处与开发人员在本地体验到的好处是一样的。类似地，假设一个团队希望与 Docker 密切合作，这种假设可能不适用于你的团队。如果你的开发人员与操作工作相对孤立，那么他们可能不希望每天都在本地使用容器，这可能不是一个严谨的假设。但是，如果你处在一个开发人员正在进行一些操作工作的团队中工作，那么假设你提供了仅仅是容器化开发环境的其他替代方案，那么这对你的团队有好处。【「CSDN」Docker 开发环境正在崩坏！】

本文插图
在本地运行容器会消耗大量资源。仅在我的机器上，在一个典型的工作日， Docker 就要消耗大约 36GB 的存储空间。我不会说对于我的特定品牌和型号的工作站来说系统使用量是非常大的，但是我可以很容易地看出，当我在工作流中包含更多的容器时，系统使用量会大大增加。在我的活动监视器中， Docker 也是占用 CPU、内存和磁盘资源最多的。更重要的是，尽管这可能不会给我的机器带来沉重的负担，但这并不意味着它与其他机器很好地匹配，而且最终决定将如此多的资源分配给 Docker 应该取决于开发人员自己的个人偏好。也就是说，你的笔记本电脑不是服务器，它可能不需要根据服务器标准构建的容器资源。但是，即使超出了系统资源，开发人员环境也不能很好地与运行你的代码的系统保持一致。在过去，这种差异是如此之大，以至于我们经常不得不进入一个与我们的生产服务器完全一样的环境，而且我们中的一些人(不幸的是，包括我自己在内)如果出现严重错误的话，甚至不得不在这些系统上进行实时代码更改！开发人员需要专注于编写可维护、可靠和经过良好测试的代码。我认为，在有限的环境中工作可以有更好的代码实践和决策ーー你不得不依赖于编写整洁的、可维护和可操作的代码，而不是希望服务器以这种方式配置来处理性能瓶颈和低效的实现。开发人员在工作时已经有很多需要构建和维护的上下文。如果你的本地 Docker 环境将这种上下文作为为判断容器是否正在运行，那么从长远来看，只会让你失望了。类似地，要求开发人员使用 `docker run` 命令启动容器会增加上下文切换的开销。在本地环境中开发时，开发人员已经建立了某种模式，而使用容器不仅与这些模式背道而驰，还需要对 `docker` CLI 本身有更多的掌握，这就给开发人员实现目标制造了阻力。当我不得不使用 Docker 容器来调试某些东西时，我也不禁感到有点奇怪。它有点像我之前提到过的一个错误: 进入生产服务器。这种启发式方法与其他服务紧随其后。如果你所在的团队都在使用微服务，而其他团队需要各种各样的服务来构建自己的特性，那么你应该谨慎地将这些镜像作为容器提供。在这些情况下，团队在自己的环境中支持服务本身实际上可能比用容器模糊服务更有益。对于这些特定的内部服务，可能值得对为此服务提供的文档进行审计，而不是对其进行容器化。维护不良的文档与容器结合在一起会产生诸多认知失调，从而导致放弃 Docker 环境的挫败感。我们所有人都应该更仔细地查看我们的文档，并经常对其进行审计，而不是构建新的东西。我上面提到的调查结果显示， Nginx、 Redis 和 Postgres 在拥抱的团队中非常受欢迎。很明显，为什么这些东西如此受欢迎。除非你的团队从事编写自己的 RDBMS 或 web 服务器 / 负载平衡器的业务，否则你将通过在堆栈中利用类似这样的开放源码应用程序而获益匪浅。直到彻底的容器化，你的运营团队可能无法获得与开发团队在决定将其包含在技术栈中获得的相同收益。通过容器化这些依赖关系，运营团队可以从一种类似的加速器中受益，这种加速器无需编写自己的 RDBMS 即可为开发人员提供帮助。容器化 Postgres 提供了大量用于部署，监视和扩展此关键依赖性的选项。它还减少了一些更新，升级和管理该系统的开销。这对运营团队来说非常有用，但这是否符合开发人员的需求？总而言之，即使简单地运行 `docker-compose up -d` 后台启动并运行容器，它也不能很好地与绝大多数开发人员用于本地运行环境的心智模型协同工作。这两种工作流程之间有着本质的差异。