原文作者：eveloper Relations Lead at itopia --- Jan Van Bruggen

原文译自：CNCF（云原生基金会）

在过去的十年中，我们见证了“as code”的兴起、标准化和模因化：基础设施即代码、监控即代码、政策即代码以及很快可能出现的数据即代码。从本质上讲，“Stuff as Code”是通过版本控制的声明性配置文件无状态地自动管理“stuff”的实践。因此，值得一提的是，相同的 DevOps 实践是否可以有效地应用于一组不稳定的资源，这些资源对开发人员来说比他们的后端更接近他们的本地编码环境。

开发人员环境配置漂移的常见问题，是在重新访问旧项目或遵循以往的教程时会带来一些不便，但可能需要专业开发人员每月花费数天的时间来恢复/更新他们的环境，尤其是在技术多元化的团队中. 不幸的是，Terraform 无法将我们从本地依赖的困境中拯救出来，Kubernetes 也无法帮助 Windows 和 macOS 笔记本电脑在代码库上进行协作……是否可以通过声明性配置文件、版本控制和无状态自动化实践来解决这些本地环境问题？

让我们先来思考一下，一个人在编写代码时所要依赖的所有“本地”内容都有哪些：

• 集成开发环境 (IDE)
• 个人设置
• 特定于项目的库
• 系统范围的软件包
• 操作系统 (OS)
• 电脑硬件
• 网络连接
• 电
• 键盘旁边的一杯水

本地环境对配置排斥的一个原因是，这些层中的每一层都依赖于它下面的层，因此任何对上层无状态自动化的谨工作都会被下面的状态混乱所破坏。例如，Python 项目的依赖项可能在声明性 requirements.txt 文件中定义，但每次执行的结果将根据设置的环境变量和安装的 OS 包而有所不同。支持容器化环境的 VS Code 是向前迈出的一大步，但它依赖于手动维护 Docker 安装（以及需要首先运行 Docker的兼容操作系统和订阅）。

所以，无状态地自动化部署一个完整的本地环境就不可能吗？答案，是可能的。

配置环境

我们最近看到这些混乱的中间层的无状态可配置性取得了重大进展，开发人员的工作流程也在相应地发展。让我们评估一下本地环境中每个软件定义层的当前可配置性：

个人设置

在 IDE 下，最高级别的配置是个性化。这包括覆盖应用程序和工具中的默认设置的配置文件，例如...

• IDE：settings.json、options/*.xml、.vimrc、.editorconfig 等。
• 终端：.bashrc、.zshrc、.tmux.conf 等。
• 其他：.gitconfig、psqlrc 等。

有趣的事实是：其中许多文件名以句点开头（因此被称为“点文件”）的原因是1997 年“隐藏文件”的意外发明。

IDE 依赖于快捷方式、键绑定、可访问性、布局和美学的个性化。这些文件应始终因开发人员而异，因为每个人都有自己独特的需求和习惯。那么，我们如何才能自动管理跨设备和环境的个性化，而不用同质对待开发人员呢？

最流行的答案是使用“点文件管理器”，如chezmoi、Dotbot、yadm或其他。每个点文件管理器都有不同的功能，但它们都自动更新个性化文件的过程以实现所需的版本控制状态。有些甚至使用声明性配置文件！

“个性化即代码”似乎是一个已解决的问题。尽管点文件管理器还不是很主流，但强烈建议在多个设备或帐户上coding的专业开发人员人手一个，因为它可以节省大量的设置、上下文切换和调试这些环境所带来的的时间。

项目库

从 Java 到 Rust，几乎每个软件项目都导入第三方库，并且这一层已经“作为代码”进行管理。库依赖项的声明性配置文件通常包含在版本控制中的项目源代码中：

• 带有 Maven 的 Java 的pom.xml
• Python 的requirements.txt
• Node.js 的package.json
• 用于 Rust 的Cargo.toml

清单还在继续，几乎每种编程语言都有一个行业标准协议。

有趣的事实是：多年来，这种趋势的主要例外是 C 和 C++，因为它们与系统包的独特集成（见下一节）和（可能）遗留工作流的惯性。然而，今天柯南和vcpkg似乎都很流行并且正在增长。

IDE 通常依赖这些库来格式化、分析和执行源代码，因此这些配置文件分布在源代码中对开发人员的体验大有裨益。事实上，“作为代码的库依赖”已经被彻底解决了很长时间，以至于……

• 几乎每个项目在第一天就开始无状态地管理其库依赖项。
• 几乎每一种编程语言都应该有一个库管理协议。
• 这是一个未使用的短语，因为它似乎只是常识。
• 大多数开发人员认为这是理所当然的，直到有人在谈论其他东西即代码时注意到它的无所不在。

系统包

与特定于项目的库不同，系统范围（和每个用户）的包用于开发人员的多个/所有项目，并针对每个操作系统进行定制。这些包括：

• 编译器和解释器，如 gcc 和 python
• 客户端和服务器，例如 curl 和 apache
• 终端 shell 和 GUI，例如 xterm 和 gnome

除了作为包本身之外，IDE 还依赖于其他包来呈现视图、连接到服务以及分析/执行代码。每个项目都依赖于一组独特的包，因此每个开发人员都会在他们的操作系统上安装这些包的独特集合。但是，通常一次只能安装一个包的一个版本，有时不同的包不兼容或相互竞争。这会导致环境之间（以及内部冲突）令人沮丧的依赖不匹配，那么有没有办法在不破坏另一个项目的包依赖的情况下跨设备和环境自动管理项目的包依赖？

在过去的几十年里，一种有状态的解决方案很流行：使用像APT、pacman、Homebrew或Chocolatey这样的包管理器来一次安装一个特定的包版本。这些工具支持强大的设置脚本，当与容器化的无菌性和短暂性结合使用时，这些脚本更加可靠和可维护（下一节将详细介绍）。不幸的是，如果没有容器化，有状态配置本质上比无状态配置更难扩展，无状态配置可以在未来的任何时候知道它是否变得无效/冲突，然后有效地自我修复；只需询问任何为此原因选择 Terraform 的基础设施即代码方法的人！

这就是为什么看到Nix慢慢变得 越来越 流行如此令人兴奋，因为 Nix 是针对同一问题的无状态解决方案。通过安装每个单独包的一个或多个不可变版本并将包依赖项（直接和间接）显式转换为 DAG，Nix 可以针对大多数形式的位腐烂提供面向未来的环境，并大大简化使用不同操作系统的开发人员之间的协作。任何遇到操作系统级依赖地狱的开发人员都绝对应该安装 Nix，看看 nix-shell 是否能让他们整整一周都充满活力。

操作系统

每个开发人员的软件堆栈的底部是他们的操作系统(OS)，其中包括各种子系统：

• 应用平台
• 文件管理
• 司机
• 资源（处理器、内存等）管理

对大多数开发人员计算机上安装的操作系统进行无状态配置是不可能的，因此管理这一层的最流行方法是使用容器化的客户操作系统来托管开发人员环境。对于我们的目的，“客户操作系统”意味着每个环境彼此隔离，“容器化”意味着每个环境的规范都可以受版本控制。

有趣的事实：实际上，确实存在一些无状态操作系统，但它们（还）不流行。NixOS是一个完全由 Nix 包管理器管理的无状态操作系统，Guix System是 NixOS 的自由模仿者。喜欢冒险的开发人员可能会爱上 NixOS，但它可能（尚未）支持所有开箱即用的开发工具，这主要是因为它的设计截然不同。

自从Docker起源于容器的大部分概念和行话以来，它一直是指定、构建和运行容器的最佳平台。尽管它实现了一个有状态的系统来指定构建步骤，但构建的容器镜像是一个不可变的工件，可以在声明性配置文件中引用。

推荐的方法

虽然对每一层都进行无状态自动化是理想的，但您可以通过单独引入新的自动化工具来逐步升级您的环境。单独的 Nix 是项目的强大补充，单独的 chezmoi 是开发人员的友好助手。

另一方面，如果您想直接跳转到全自动环境，那么设置和维护全自动本地环境的最佳方法是：

• 在构建环境时
• 使用 Docker 有状态地配置来宾操作系统
• 使用操作系统的包管理器有状态地配置一些系统包
• 运行环境时
• 使用已构建的容器映像无状态地配置容器
• 使用 Nix 无状态配置大多数系统包
• 使用您选择的语言工具无状态地配置项目库
• 使用 chezmoi 无状态地配置个人设置

根据您的用例，您可能希望将部分或全部这些无状态配置步骤移动到构建过程中，以将其结果缓存在容器映像层中。

运行 IDE

借助我们可以使用的所有上述工具，我们有多种方法可以可靠且可重复地配置本地环境。该环境可以是一个最小且高性能的日常驱动程序，并且与个人文件、消息传递应用程序、其他环境和 Docker 本身隔离。但是，如何与在容器内运行的 IDE 交互并不是很明显，这是下一步的必要步骤（除非您选择了不需要容器的 NixOS）。

本地安装的 IDE 可以在本地使用，因为 IDE 充当自己的客户端，但大多数容器化 IDE 需要使用与 IDE 服务器分开的 IDE 客户端，以便在操作系统之间进行通信。以下是一些著名的 IDE 客户端，包括基于 Web 的（“在线 IDE”）和本地（“混合 IDE”）：

VS Code

VS Code 是一种流行的 IDE，它是第一个同时提供混合和在线解决方案的 IDE。

远程开发是一组第一方 VS Code 扩展，除其他外，它允许将现有的 VS Code 安装用作混合 IDE，连接到在某处运行的 VS Code 服务器。这是一个易于设置的解决方案，但它确实需要用户在其容器中配置 VS Code 服务器或使用容器扩展来托管整个开发人员环境。这是一个适合想要将本地 VS Code IDE 用作 IDE 客户端的独立开发人员的工具。

或者，code-server是第三方 VS Code Web 服务器，它将 Web 应用程序中的 VS Code 客户端呈现为在线 IDE，连接到 VS Code 服务器。这是一个灵活的在线解决方案，需要高级网站托管技能，但它不支持来自 Microsoft 市场的扩展。这是一个为想要在非本地使用 VS Code 的独立开发者提供的工具。

JetBrains IDE

Projector是 JetBrains IDE 套件的第一方容器化解决方案：PyCharm、IntelliJ IDEA、PhpStorm 等。这允许您将任何 JetBrains IDE 作为在线 IDE 运行，但 UX 与其原生应用程序不一致，因为 Projector 实现了用于 IDE 基于 Swing 的 GUI 的 HTML5 连接器。

其他 IDE

selkies-gstreamer是一个 DIY 容器化解决方案，用于在容器中运行任何与 Linux 兼容的 IDE/GUI，具有基于浏览器的界面。我们将在后面的部分中更多地讨论更广泛的Selkies平台，因为它是一个非常独特的解决方案，但是对于想要运行没有自己的容器化工具的特定 IDE/GUI 的独立开发人员来说，这个独立组件是一个强大的工具或网络前端。

缩放问题

这些解决方案都需要一点 Docker 修补，但它们非常适合独立开发人员。但是，部署和扩展它们以服务于中型开发团队需要容器编排和网络方面的专业技能。为每个用户的应用程序流会话高效地配置和可扩展地维护 Kubernetes 集群是一项非常重要的技术挑战，分布式/远程团队可能需要多个大洲的多个集群，这增加了维护复杂性的额外维度。

扩展以服务您的团队

我们在itopia认为，对于我们的远程工作站团队来说，这种自动化挑战听起来比普通开发团队更有趣，因为大多数团队的优先级高于维护工作站集群。itopia 管理远程企业工作站已有近十年的历史，因此我们对大型团队如何采用、扩展和维护以生产力为中心的环境有一些见解。

设计时考虑到大型团队

对于远程工作站，大型团队有以下偏好：

• 可移植性：基于浏览器的 IDE 客户端比 OS-native IDE 客户端更方便。
• 性能：Web 应用程序应该在云中而不是在浏览器中完成所有繁重的计算和联网，以防止资源瓶颈。
• 灵活性：所有 IDE 都应支持与本地安装相同的 UX，以最大限度地降低转换成本并最大限度地提高开发人员效率。
• 安全性：高安全性端点对于保护知识产权至关重要。
• 维护：对于企业而言，完全托管的服务通常比自托管服务更实用，因为自托管需要进行细微的维护。
• 透明度：开源技术比闭源技术更灵活、安全和可审计，这对 CTO 和系统管理员都很重要。

我们惊讶地发现不存在满足上述所有偏好的解决方案，这意味着团队必须以某种方式妥协。浏览器渲染客户端和原生 IDE 客户端共同涵盖了大多数解决方案，都需要将源代码流式传输到所有开发人员设备，几乎没有针对 IP 泄露的保护。像GitHub Codespaces这样的自以为是的服务在仅支持一个 IDE 和版本控制系统方面是不灵活的。一些解决方案提供自托管作为安全性和灵活性升级，但这会增加维护工作。

itopia Spaces为团队和企业检查所有正确的框；这是一个免费的试驾来证明这一点。请参阅我们的 itopia 管理图像的开源目录，了解可能的想法和您独特定制图像的起点。

核心技术是公开的，所以还请查看我们与 Google 合作创建的开源云原生流媒体平台Selkies。如果您喜欢今天看到的内容，请加入我们的社区，让我们知道您明天想看到什么！我们喜欢看到人们在 Selkies 上进行构建，我们希望共同为远程应用程序流式传输建立一个高质量的新标准。

很高兴看到最近在改善开发人员环境方面取得了多少进展，并且想到几年后编码过程会是什么样子也很令人兴奋。然而，至少，开发人员将能够可靠地配置他们的环境以满足他们的需求，而无需在项目的任何时候手动输入命令和编辑文件 - 或者他们键盘旁边的杯子的角度 - 发生变化。

未来——云端IDE

随着企业上云成为了大规模的趋势，研发上云自然也是水到渠成，大势所趋。如何打通云原生开发体系，构建开发者之间的互联桥梁，在这方面，行云的TitanIDE做了深层的研究和实践。

TitanIDE, 集成了 VSCode 在线版本， TitanIDE 与传统IDE的主要区别在于 TitanIDE 是云原生集成开发环境 ，那有人也会说，我也可以从镜像仓库下载VSCode在线版本使用docker run来运行，但是通过docker run运行起来的在线IDE是一个独立的个体，和传统IDE运行在笔记本或台式机上没本质的区别。 TitanIDE 重点强调云原生环境，包含但不限于IDE本身，而是强调团队协同开发、多租户等企业级功能。 TitanIDE 聚焦于开发云原生应用，让传统服务开发人员使用自己熟悉的开发方式来开发云原生应用。 TitanIDE 也在持续不断的开发中，通过与客户互道，进一步强化协同开发能力，减低沟通成本以提升企业的开发效能。

将IDE搬到云端，直接在云端进行开发。这就是 TitanIDE采用的方案，这种方案有以下几个好处：

• 第一、缩短开发周期，通过拉近开发者与开发环境的距离，减少网络时延，并做到开箱即用，减少重繁琐而重复的发布调试过程；
• 第二、降低开发成本，通过统一资源调度，减少云基础设施资源投入；
• 第三、降低沟通成本，通过团队协同编码，加快业务价值的实现；
• 第四、提升数字资产安全，通过代码安全管控，用户在IDE上任何操作都可以记录下来；
• 第五、洞察团队开发成本与效能，通过报表统计，为管理者决策提供有力依据。

总之，开发上云，是云原生应用开发不可逆转的趋势，  TitanIDE要做开发者之间的互联的桥梁，打通云原生开发体系。

TitanIDE 在线免费体验环境，请点击>