使用容器从本地开发迁移到远程开发

2022 年 4 月 4 日，作者：Olivia Guzzardo，@OliviaGuzzardo

我最喜欢行业专家询问有抱负的开发者的问题之一是：“普通开发者每天编写多少行代码？” 大多数人猜测是数百或数千行——当他们得知实际平均数字是几十行时，总是感到震惊。

那么开发者将剩余时间用于做什么呢？ 当然，有些时间花在重要的任务上，例如代码设计和搜索“如何在 CSS 中居中 div”，但大量时间花在了纯粹的开销上——设置项目、帮助其他开发者上手以及排查在你自己的机器上似乎无法重现的问题。

多年来，Visual Studio Code 团队一直将这种洞察力作为其研究的核心：如果我们能够减少花费在开销上的时间，例如阅读有关环境设置的文章，那么我们就可以提高生产力时间。我们有一个愿景，希望开发者不必一遍又一遍地与相同的难题作斗争。这意味着需要一个一致的开发环境设置，可以应对永无止境的版本升级、配置更改和硬件更新。

但是，实现这一目标的路径是怎样的呢？ 让我们审视一下提高开发者生产力的历程，这个历程引导我们从本地开发，到基于容器的开发，再到云端。

从本地开发开始

让我们从所有开发者开始的地方（以及许多开发者仍然处于的阶段）开始：本地开发。如果你曾经说过“但是在我电脑上可以运行啊！”，那么你很可能处于本地开发阶段。这意味着你的开发环境所需的一切都存在于本地机器上。

让我们描绘一下现实世界中本地开发的景象。你是否曾经加入一个新项目，准备开始工作和编写代码，但却被给予了厚厚的入职文档，以便搭建和运行你的环境。你花费数小时等待安装命令完成，并在同事之间来回奔波以排查构建失败。可能需要几天时间你才能成功运行该项目。

然后，一旦你度过入职难关，你的团队就需要更新项目的一个依赖版本。因此，你必须在笔记本电脑上安装更新的版本，测试更新，并推送任何重构更新。但是你的笔记本电脑运行 Windows，而你的队友运行 macOS，并且更改在他们的环境中无法工作，你还需要进行更多的故障排除。

然后，然后，你需要确保所有更新在生产环境中也能正常工作...

显然，当一切都只存在于开发者的机器上时，就会出现问题。你的机器可能与你的队友的机器差异很大，无论是已安装的依赖版本，还是运行完全不同的操作系统。这可能会导致永无止境的配置噩梦循环。即使你与你的同事保持一切同步，你也会失去对在部署代码时不会遇到更多问题的信心。

如果能够确信你的开发环境与包括部署环境在内的其他所有人的环境相同，那岂不是很好？ 这就引出了我们在简化开发生产力方面的第一个进步：基于容器的开发。

容器无处不在

“容器”在行业内已经成为一个热门词汇一段时间了，所以让我们深入了解一下容器到底是什么。为了理解容器的本质，将它与物理世界中的集装箱进行比较会有所帮助。

从简单的角度来看，物理集装箱允许货物作为一个单元存放。所有需要运往 A 公司的货物都在集装箱 A 中。到达后，A 公司不需要联系集装箱 B 和集装箱 C 来获取他们的完整包裹；一切都打包在集装箱 A 内。此外，公司不需要单独的基础设施来处理，例如，装满家具的集装箱与装满食物的集装箱。无论内容是什么，他们都有必要的工具来拿起那个集装箱并将其运送到目的地。这提供了一种高效、标准化的产品运输方式。

容器最初在虚拟世界中出现也是为了实现完全相同的好处：一种简化产品运输的方式。它们提供了一种将你的软件作为一个单元运输的方式，包括所有二进制文件、依赖项和配置文件。这减少了花费在配置开销上的时间，因为容器打包了软件运行所需的一切。然后，容器可以轻松地从一个环境部署到另一个环境。预测到 2023 年，全球超过 75% 的组织将在生产环境中运行容器化应用程序，高于 2020 年的不到 30%。

传统上，容器用于代码准备好部署到生产环境时。虽然这种模式确实简化了软件开发生命周期的末端，但当开发者实际编写和测试代码时，它并没有为开发者做太多事情。为了填补这个空白，基于容器的开发应运而生。

面向开发者的容器

基于容器的开发背后的想法是在开发过程的最初阶段引入容器。然后，开发者可以在与生产环境等其他环境一致的环境中进行所有编码和测试。当跨环境具有一致性时，花费在排查不同环境之间代码行为差异的时间可以大大减少。

这就引出了开发容器的概念：一种运行功能齐全的开发环境的容器。开发容器容纳了自己的应用程序和依赖项，例如所需的工具、库和运行时。在下图 中，你可以看到这些依赖项存在于容器中，而不是在主机上，这意味着你可以立即在不同的技术栈之间无缝切换。

为了提供一种创建和连接到开发容器的方式，VS Code 在 2019 年发布了 Dev Containers 扩展。此扩展通过使用开发容器的全部功能来增强本地开发，所有这些都在不离开舒适的 VS Code 的情况下完成。该扩展的安装量超过 1100 万次，这让我们思考：如果可以拥有一个托管在云端的开发容器呢？

迁移到云端

说实话：一切都在向云端迁移，那么为什么你的开发环境应该与众不同呢？ 好吧，首先，云容易受到攻击。其次，我们似乎经常听到重大故障的消息。第三，它可能很昂贵。第四……等等，云不是应该是一件好事吗？

考虑到所有这些对云持谨慎态度的理由，想到像我们的开发环境这样重要的东西被托管在那里可能会让人感到不舒服。 所以让我们保持舒适吧！ 让我们继续依赖我们那台用了 6 年的笔记本电脑，如果你尝试快速打开电子邮件，它就会发出非常奇怪的嗡嗡声，更不用说尝试构建项目了。 我们将舒适地等待不可避免的笔记本电脑崩溃，然后一旦我们拿到新的笔记本电脑，我们就必须重建我们的开发环境，并努力记住我们是如何配置它的。

事实证明，待在舒适区听起来也不是那么美好。

虽然云存在固有的风险，但如果你明智地选择你的云托管服务，这些风险是可以减轻的——我们稍后会详细讨论。 随着这些顾虑的消除，你将收获云端的一些主要好处：可扩展性、更快的性能和更易于维护，仅举几例。

在云端托管使你可以访问另一台机器的资源，这些资源可以快速启动并在任何地方可用。 将这些与基于容器的开发的优势结合起来，开发者可以在眨眼间开始编码。

云端容器

在云端运行容器并不是一个新概念；事实上，一项研究表明，至少一半的容器在云端运行。 基本的基础设施包括将容器部署到云端托管的虚拟机。 我们可以将我们的开发容器部署到云端，以提供云端托管的开发环境。

VS Code 进入这个领域源于为 GitHub Codespaces 提供支持。 在几分钟内，你可以创建和配置一个托管在云端的开发容器，它随时为你准备就绪。 然后，你可以通过 VS Code（在浏览器或桌面端）连接到一个为你完全管理的开发环境，不再依赖笔记本电脑的资源来处理需求。

Dev Containers 扩展中使用的相同开发容器也可以在 GitHub Codespaces 中使用，从而提供到云端的无缝过渡。

但是还记得所有那些关于云的可怕可能性吗？ 好吧，GitHub Codespaces 通过利用 GitHub 的云功能来缓解这些问题。 Codespaces 在 GitHub.com 上托管的计算选项上运行，该功能目前可供使用 GitHub Team 或 GitHub Enterprise Cloud 的开发者使用。

GitHub 按用户收费，因此你永远不会支付超过你使用的费用。 你还可以设置消费限额，消除任何意外费用。 此外，GitHub 可以提供 99.9% 月度正常运行时间的服务级别协议，并且 GitHub Advanced Security 可用于缓解任何安全顾虑。

借助 VS Code、GitHub 和开发容器的力量，GitHub Codespaces 为从本地开发迁移到云端提供了清晰的路径。

下一步是什么？

作为开发者，我们希望花更多时间开发软件，而不是花时间在令人头疼的配置上。 行业趋势可以而且应该被用来赋能开发者，提高他们的生产力。 我们已经探讨了容器和云如何将我们带到下一个 level，你可以开始使用 Dev Containers 亲身体验一下。 那么，你认为下一步可以让我们的生活更轻松呢？

编码愉快！

Olivia Guzzardo，@OliviaGuzzardo