利用容器从本地开发转向远程开发
2022年4月4日，作者：Olivia Guzzardo，@OliviaGuzzardo
我最喜欢问行业专业人士的一个问题是：“一名普通开发人员每天编写多少行代码？”大多数人的猜测都在数百或数千行——而当他们听到实际平均数字仅为几十行时，总是感到非常震惊。
那么，开发人员将剩余的时间花在了哪里？当然，有些时间花在了诸如代码设计和搜索“如何让 CSS 中的 div 居中”等重要任务上，但有相当多的一部分时间被浪费在了纯粹的开销上——设置项目、指导新开发者入职，以及解决那些在自己的机器上无法重现的问题。
多年来，Visual Studio Code 团队一直将这一见解作为其研究的核心：如果我们能减少在开销上花费的时间，例如查阅环境设置文档，那么我们就能提高生产力。我们的愿景是让开发者不必再反复进行同样的斗争。这意味着需要一种统一的开发环境，能够处理版本升级、配置更改和硬件更新带来的永无止境的变动。
那么实现这一目标的路径是什么样的呢？让我们回顾一下提升开发者生产力的历程，这一历程引领我们从本地开发走向基于容器的开发，再到云端开发。
从本地开发起步
让我们从所有开发者的起点（也是许多人仍处于的阶段）开始：本地开发。如果你曾经说过“但在我的电脑上它是好的！”这句话，那么很可能你正处于本地开发阶段。这意味着你的开发环境所需的一切都存在于你的本地机器上。
让我们描绘一下现实世界中本地开发的情景。你是否曾经加入一个新项目，准备好开始编码，结果却被塞了几页纸的入职指南来配置你的环境？你花费了数小时甚至数天时间等待安装命令完成，并在同事之间来回奔波以解决构建失败的问题。可能几天之后你才能成功运行该项目。
当你度过了入职的阵痛期后，团队需要更新项目的某个依赖版本。于是，你必须在自己的笔记本电脑上安装更新后的版本，测试更新，并提交任何重构后的更改。但你的笔记本电脑运行的是 Windows，而队友们使用的是 macOS，这些更改在他们的环境中无法运行，你还得继续进行更多的故障排查。
而且，在那之后，你还需要确保所有更新在生产环境中也能正常工作……
显然，当所有东西都仅仅存在于开发人员的本地机器上时，问题就出现了。你的机器可能与队友的机器有很大差异，无论是由于已安装的依赖版本不同，还是运行着完全不同的操作系统。这可能导致陷入永无止境的配置噩梦循环中。即使你设法与同事保持环境同步，当你准备部署代码时，你仍然无法保证不会遇到更多问题。
如果能确信你的开发环境与包括部署环境在内的所有人的环境完全一致，那该多好？这就引出了我们精简开发效率的第一个进步：基于容器的开发。
容器无处不在
“容器”在业界已经成为一个流行词有一段时间了，所以让我们深入了解一下容器到底是什么。要理解容器的本质，将其与物理世界中的集装箱进行对比会很有帮助。
简单来说，物理集装箱让货物作为一个单元存在。所有需要运往 A 公司的货物都在 A 号集装箱内。货物到达后，A 公司不需要去联系 B 集装箱或 C 集装箱来获取他们完整的包裹；一切都封装在 A 号集装箱内。此外，公司不需要单独的基础设施来处理装满家具的集装箱与装满食品的集装箱。无论内容物是什么，他们都有必要的工具来提取该容器并将其运送到目的地。这提供了一种高效、标准化的产品运输方式。
容器最初出现在虚拟世界中正是为了这个好处：一种精简的产品交付方式。它们提供了一种将软件作为一个单元进行交付的方法，包括所有二进制文件、依赖项和配置文件。这减少了在配置开销上花费的时间，因为容器封装了软件运行所需的一切。然后，容器可以轻松地在不同环境之间进行部署。据预测，到 2023 年，全球超过 75% 的组织将在生产环境中运行容器化应用程序，而 2020 年这一比例不到 30%。
传统上，容器在代码准备好部署到生产环境时使用。虽然这种模式确实简化了软件开发生命周期的末端，但对于开发人员在编写和测试代码时并没有太大帮助。为了填补这一空白，基于容器的开发应运而生。
面向开发者的容器
基于容器的开发的理念是在开发过程的最初阶段引入容器。开发人员可以在与生产环境等其他环境一致的环境中进行所有的编码和测试。当环境之间保持一致时，排查不同环境中代码行为差异所花费的时间基本上可以消除。
这就引出了开发容器（dev container）的概念：一个运行全功能开发环境的容器。开发容器包含了它自己的应用程序和依赖项，例如所需的工具、库和运行时。在下图中，你可以看到这些依赖项存在于容器中，而不是宿主机上，这意味着你可以瞬间在不同的技术栈之间无缝切换。
为了提供一种创建并连接到开发容器的方法，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% 月度正常运行时间的服务水平协议 (SLA)，并且可以使用 GitHub Advanced Security 来缓解任何安全顾虑。
凭借 VS Code、GitHub 和开发容器的力量，GitHub Codespaces 提供了一条从本地开发转向云端的清晰路径。
下一步是什么？
作为开发人员，我们希望将更多时间花在开发软件上，而不是花在令人头疼的配置上。行业趋势可以也应该被用来赋能开发人员，以提高他们的生产力。我们探讨了容器和云端如何将我们提升到一个新的水平，你可以通过 开始使用 Dev Containers 来亲身体验。现在，你认为让我们的生活变得更轻松的下一步可能是什么？
编码愉快！
Olivia Guzzardo, @OliviaGuzzardo