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

本文插图
作者 | Micah Adams
责编 | 徐威龙
封图 | CSDN 下载于视觉中国
最近，我构建了一个本地开发环境，该环境使用 Docker 进行一些关键的集成测试。在我要完成这项工作时，我意识到在开始这项工作之前，我没有考虑到这么做的一些意义深远影响，如：

它要求开发人员在其本地计算机上安装 docker 和 docker-compose （命令行工具）。
为了让环境可以正常使用，需要大量的配置。
我需要编写 shell 脚本来“缓解”某些配置问题。
我编写的 shell 脚本最终也有些局限ーー它在某些环境中工作得很好，但是如果你在 Windows 系统上工作，你就得靠自己了。
我一天中的大部分时间都要用来排查一些数据库连接问题，结果发现我容器的数据库没有配置正确。

在这方面投入了大量的时间，最终使我的团队受益，并最终帮助我们解决了集成测试中遇到的一些难题。但是更让我感兴趣的是它所带来的麻烦，更不用说在最终合并之前我提交的 pull 请求时引发的热烈讨论了。此外，这种环境最终只有一个目的——提供集成测试环境，而不是像我最初希望的那样，提供一套完整的开发环境。最终的结果是，我们将这个环境从开发人员的机器上移开，并最终将其部署到云提供商的一个容器化列表中，以创建一个集成测试资源。我的努力基本上是失败的，尤其是考虑到我最初的动机。难道我误入歧途了？我所有的努力工作只换来一个花哨的测试环境？我决定更深入地研究基于容器的开发环境的问题，从那以后我所学到的东西极大地改变了我将来处理这个问题的方式。

本文插图
容器的当前状态
大量的调查向我们证明，使用 Docker 的人数在持续增加，特别是随着基础设施的增长和变得更加复杂之后。 2018 年 6 月来自 DataDog的一项调查显示，大约25% 的公司使用 Docker 部署了某种形式的基础设施。从 2017 年到 2018 年，部署的规模增加了75%。根据这些消息来源，Docker “革命”正在全面展开，没有减缓或停止的迹象。 (我仍然很好奇这75% 中的大多数公司在他们的部署中使用了什么？抱歉，我跑题了。 )调查内容：来自 DataDog 的调查：2018 年的 DataDog 调查也提到了使用最广泛的 Docker 镜像是“ Nginx ， Redis 和 Postgres” 。这对我来说很有意义，因为运行应用程序依赖项的容器似乎是容器的第一步。 Docker Compose 为多容器应用程序提供了一个相对简单的工具；它似乎也是一个很好的工具，允许开发人员为自己的环境运行特定的、底层的基础设施。也就是说，你要为你的项目设置了一个 `docker-compose.yml` 文件即可。这 25% 的公司在生产环境中运行 Docker ，究竟有多少公司使用 Docker 作为开发工具呢？2019 年 Stack Overflow 调查报告显示， 38.4% 的受访者使用容器进行开发工作，但目前约有一半的受访者没有使用任何容器技术。我想知道是否有一种方法可以进一步理解为什么开发人员不像我最初想象的那样经常使用 Docker 。我决定再深入挖掘一下，粗略地研究一下开发人员对 Docker 的看法。许多开发人员讨厌自己的 Docker 环境，这是有充分理由的——引入容器似乎会减慢开发人员与他们所构建的环境之间的反馈周期。容器化开发环境似乎也为操作员创建了一个不必要的抽象，这个操作员需要能够直接深入到代码、执行期函式库、甚至较低级别的操作系统ーー所有这些都是在构建一个特性的过程中。支持将 Docker 作为开发工具的人声称，这样做有明显的的好处。使用容器的开发环境也会导致整个开发团队实现对等。如果每个人都使用容器作为他们的数据库、缓存或其他杂项基础设施，那么设置编写代码应该和运行 `docker-compose up` 一样简单，你就可以拥有一个完整的开发环境。假设你的团队愿意在本地运行容器，那么你将永远不会在开发环境和生产环境之间造成差异。当运行 `brew upgrade`对其进行升级时，不会有啥意外——容器将始终与你的需求保持同步。坦白地说，我同情这两个群体。作为一个开发者，一只脚坚定地站在房子的运营方面，我认为运行容器的好处是巨大的。然而，我并不认为这些好处完全适用于开发人员工作流。我相信在开发环境中使用 Docker 的经验之间存在差异，因为 Docker 不是开发人员的工具。然而，我不认为这意味着开发团队不应该考虑利用一些 Docker 来满足他们自己的需求。但是我觉得将 Docker 作为另一个操作工具来处理可以帮助减轻在本地开发环境中运行 Docker 的痛苦。