今天这篇文章咱们来聊一聊 Sealos Devbox 到底是怎么设计的,据说隔壁老奶奶最喜欢看这种有技术深度的文章了。
Devbox 返璞归真,把开发者的开发精力放到开发中去,真正做到了摈弃复杂的 CI/CD,Docker,YAML 编排,除此之外还力求拉平开发与测试与运维团队之间的一切界限,从从业者的角度做到了一套环境,随处运行。
Devbox 的架构极大的阐释了 “Sealos - 一切皆应用” 的理念,通过对不同组件层级的抽象与集成,把复杂度控制在不同层级的内部,从而达到在体验和效果上的一致性。
在内部设计与架构方面,我们进行了大量复杂的工作,以确保系统的高效和解耦。这个过程涉及了不同分层级别下面的架构区别和规划,不同层级之间的技术细节与选型互不依赖,针对每一个功能点都进行了针对性的设计。
尽管内部逻辑复杂,Devbox 的核心却是让用户在几乎不需要更改现有的代码开发与上线流程的前提下能够直接无缝上云,快速且直接的体验到云原生与虚拟化的优势。在使用相同的 IDE 开发的前提下,可以提供和现有的所有开发流程完全一致的体验。
很多时候,研发同学和运维同学,开发流程和上线流程,很容易因为环境的不一致出现的问题而导致时间与精力的耗费。比如说在我的电脑上运行好好的,到了另一台电脑上就不行了,或者是同样的初始化脚本,在开发机上是可以跑起来的,但是在上线之后却出现了各种各样的问题,这种情况在 Devbox 上是不会发生的。
整体架构图如下:
Devbox 可以大致的分为三个大部分:
用户直接交互的界面与接口的聚合部分,包括 Web 前端,插件端,API 端。
Sealos 内 App 的部分,完整的用户交互界面,包括创建,查看,变更,删除等等,是用户与 Devbox 交互的第一入口。
实际为 VS Code 和 Jetbrain 等 IDE 的插件,在 IDE 内展示与管理 Devbox 列表,与 API 端交互。
负责与控制器交互,鉴权 web 前端/插件端请求,聚合转换数据接口等。
Devbox 控制器负责将来自用户的请求转换为 K8s 的资源,实际创建对应 Devbox 实例的 pod,svc,ingress 等,管理对应的数据,监听与同步 Devbox 实例的所有状态,返回外部可访问的网络 URL 等。
Devbox Controller 支持如下命令:
负责与 kubernetes 的底层 CRI 部分进行交互,实现容器的持久化与提交到 Devbox 专属的镜像仓库,更新镜像信息等,是 Devbox 的核心部分。
后续,Devbox 还会提供:
等等功能,力求在保证一致的开发运行体验的架构上,利用轻量级虚拟化的特点,提供更多的扩展能力。
颤抖吧世界,大的要来了!