这是本节的多页打印视图。
点击此处打印.
返回本页常规视图.
概述
产品定位,用户价值,使用场景,主要概念和技术架构。
SmartIDE是一款 远程/云端工作区调度工具,其 核心价值是从根源上解决软件环境问题。当前,SmartIDE主要采用容器技术,比如:Docker和Docker-Compose;以及容器集群编排技术,比如:Kubernetes,来解决软件运行环境的一致性,标准化,快速获取,可扩张性和可维护性问题。
SmartIDE对IDE的边界重新进行了定义,我们认为任何当前应用所需要的代码编辑器,运行时,SDK,中间件,应用服务器,配置以及底层操作系统均属于我们所定义的IDE的一部分。与传统的IDE工具的不同之处主要在于E(Environment 环境)。开发者常用的Visual Studio, Visual Studio Code, JetBrains全系列以及Eclipse这些传统的IDE工具在 I (Integrated 集成性)和 D(Development)上面做的都非常出色,但是它们都没有为开发者彻底解决E的问题。这是因为在这些IDE产品出现的时候,软件本身的依赖环境还没有那么复杂,大多数的软件都是单体,微服务架构还未出现,通用中间件软件也不流行,大多数的开发者都可以在自己本地的开发机上完整整个应用(系统)的完整搭建,开发调试,测试以及打包发布过程。
当前的软件系统已经越来越复杂,越来越多的开发者在使用各种中间件来简化自己的软件开发过程,越来越多的团队在引入微服务架构来适应业务架构的敏捷性需求,云原生技术正在被更多团队接受,容器化和集群编排系统以及DevOps CI/CD流水线的引入也给软件工程引入了更多的复杂度。在这样的背景下,传统IDE产品的局限性日渐显现,开发者不得学习更多的技术,引入更多的工具,花费的更多的时间在软件环境的管理和维护上。在软件工程领域种,也出现了类似SRE这种专注于打通复杂软件工程系统协同的专业化工作角色/职责,软件环境在SRE的工作职责种占有非常高的比重(参考:Google SRE。即便如此,软件环境问题仍然是企业改进软件工程系统过程种最难解决的核心问题之一。 (参考:8 Key Challenges in Adopting DevOps)。对于希望通过改进软件工程工艺来提升研发效能的团队来说,解决环境的可获取能力是实现端到端持续交付能力的主要障碍。
也因为以上原因,IT行业内开始涌现了Docker, Kubernetes, Hashicrop等专注于解决软件环境问题的基础工具类软件。从2013年Docker引领的容器化浪潮开始,软件交付方式已经有了翻天覆地的变化,而且这种变化在逐步从生产环境向开发测试环境推进。这个趋势的核心实践,Infrastructure as Code(IaC 基础设施即代码)的思路正在影响着越来越多的DevOps实践者和工具厂商。可以说,在容器化浪潮的背后其实是IaC实践广泛应用,也因为此IaC实践被大多数DevOps实践者作为判断一个组织的软件工程能力的重要评估标准。
如下图所示:IaC实践(工具)正在从生产环境逐步左移
IaC实践左移实际上是从问题的表象逐渐触达实质的过程。容器化/IaC实践首先被用于生产环境的原因很容易理解,因为这个环境最贴近用户,最贴近业务,也是企业最愿意投入资金的部分;但随着生产环境的容器化进程推进,组织会逐步认识到生产环境的问题的根源其实并不在生产环境,而在其左侧的测试,流水线以及开发环境。开发环境作为产生环境的源头,如果不能被容器化,会对其下游(右侧)环境构成连锁问题效应,破坏容器化本应产生的效益,比如:为管理容器编排文件而专门设置的权限、人员角色和流程,因为开发人员引入的环境变更而引起的后续环境的连锁变更;运维人员为了防止以上问题影响系统稳定性而采取的保守管理策略,以及受到损伤的业务敏捷性。
应该说,在容器化进程发展到今天的将近10年以后,开发环境的非标准化已经成为阻碍整个持续交付体系效能提升的关键性障碍。同时,随着企业中的容器化平台(包括:各种类型的k8s以及很多企业习惯称之为PaaS的私有云平台)以及DevOps工具链的普及,已经为IDE上云提供了必要条件。
从传统IDE工具的演进来看,以 Visual Studio Code Remote 以及 JetBrains Gateway 为代表的远程开发能力已经被越来越多的开发者接受并喜爱;同时也出现了类似 Squash, telepresence, Nocalhost ,Bridge to Kubernetes (Visual Studio 插件 和 Visual Studio Code 插件) 这样专注于解决K8S环境下调试场景的特定工具(参考:[Debugging Microservices: The Ultimate Guide](https://lightrun.com/debugging/debugging-microservices-the-ultimate-guide/)。这些都代表着传统IDE工具的云化进程。
SmartIDE 定位于远程/云端工作区的调度,为传统IDE上云提供服务端的完整解决方案,依托于已经在大量企业普及的容器云和DevOps平台,为开发者提供更加安全,简单和高效的全新工作模式。最终实现在 探索阶段 就能确认软件的最终形态的目的,为后续的环节提供明确的状态基准。
1 - 什么是云原生IDE
云原生IDE应该可以以云应用的特性(自助化、按需使用、可扩展和弹性)在任何地点运行,云应该无处不在
SmartIDE CLI可以在 Windows/MacOS/Linux 三种操作系统上运行,并且支持x86/ARM两种CPU架构。因此无论开发者所使用的开发机使用了怎样的操作系统,均可以正常安装和使用CLI来完成工作区的管理。
很多人会觉得一个云原生IDE产品为什么要做跨平台支持,其实这个和我们对云原生的理解有关。我们认为云原生不能被简单的理解为使用k8s,而是要用利用云的能力让用户的工作和生活变得更加简单。对云原生IDE而言,这意味着它应该可以以云应用的特性(自助化、按需使用、可扩展和弹性)在任何地点运行,云应该无处不在。
相对于大众普遍理解的CloudIDE,SmartIDE希望可以在任何贴近应用最终运行环境的地方让开发者进行开发和调试,这意味着:
- 如果开发者希望使用自己的本地开发机作为自己的开发环境,那么开发者应该可以使用SmartIDE做到
- 如果开发者希望使用一台主机(本地、数据中心、私有云或者公有云)作为自己的开发环境,那么开发者应该可以使用SmartIDE做到
- 如果开发者希望使用Kubernetes作为自己的开发环境,那么开发者应该可以使用SmartIDE做到
- 如果开发者希望使用一台运行着ARM芯片的硬件作为自己的开发环境,那么开发者应该可以使用SmartIDE做到
- 如果开发者希望使用XXX作为自己的开发环境,那么开发者应该可以使用SmartIDE做到
- 在任何以上环境中进行编码开发,开发者应该有一致的体验和开发效率
因此,SmartIDE并不是一个单纯的CloudIDE产品,我们将其定位于云原生IDE。
2 - 工作模式和使用场景
跨平台、跨云;本地开发到云端开发,各种开发场景支持。特别对于远程开发场景提供完善支撑,大幅提升云计算、大数据,人工智能,微服务等新时代/下一代开发场景下的开发效率。
SmartIDE支持3种模式,分别为本地模式,远程模式和k8s模式。
本地模式 支持开发者在本地开发机上使用 smartide start 指令启动工作区,这种模式主要现象个人开发者独立使用。开发者无需关心所启动环境所需要的开发语言,SmartIDE将确保环境的标准化和一致性。
远程主机模式 支持开发者通过增加 –host 参数将工作区部署到任意远程主机上,无论这台主机在什么地点运行,开发者都可以一键完成开发环境的部署并将使用远程主机来完成代码编译,打包,运行和测试过程。
k8s模式 支持开发者增加 –k8s 参数将工作区部署到任意k8s集群中,利用k8s所提供的调度能力,可扩展性和弹性,可以提供支持更加复杂的开发环境调度场景。
使用场景
虽然SmartIDE理论上可以支持任何应用的开发场景,但对于以下这些类型的应用来说可以提供比传统开发模式更好的体验。
代码安全管控: 对于非常关注代码安全性或者使用大量外包人员的组织来说,如何防止代码离开自己受控的服务器环境,同时又可以让开发者方便的完成代码开发一直都是一个矛盾。很多资金充裕的企业已经在使用的虚拟桌面(VDI)解决方案就是针对这种场景,但是VDI系统价格昂贵,资源占用量大而且无法动态调度资源,这也造成很多企业给开发者提供的虚拟桌面配置很低,开发效率非常低。SmartIDE所采用的容器化方案可以做到动态资源调度,根据项目本身的特性控制资源使用,同时开发者可以只需要浏览器即可访问这些资源。对于企业优化IT基础设置资源利用率,提升开发者体验和工作效率非常有帮助。
大数据和AI开发: 这些开发场景因为需要更强的算力并处理大量的数据,因此通过远程开发方式可以让开发者更好的利用云端资源更加便捷高效的完成开发。
微服务架构开发: 当系统中所设计的微服务数量到达一定量级之后,开发者无法在本地开发环境运行完整系统,利用SmartIDE所提供的远程工作区则可以利用云端的大量服务器资源轻松完成环境搭建。同时因为IDE工具与运行环境可以非常贴近,在开发调试过程中也可以避免因为网络延迟而造成的各种问题。
实验室/培训环境: 教育/培训行业往往休要同时提供多种不同的开发语言,工具的环境以便适应不同类型的课程的需要,但是因为课程本身的时效性问题,这些环境并不需要一直运行,而只需要在学员需要的时候启动,课程结束之后即可销毁。采用SmartIDE工作区可以非常便捷的快速为新课程配置环境,随用随起,用完即焚。
工业软件/硬件开发: 工业软件和硬件开发往往需要在特定硬件环境中才能进行调试和测试工作,传统模式下IDE是无法运行在这些硬件上的,开发者需要通过开发同步工具,命令行调试工具才能完成日常开发调试工作。这个过程往往非常繁琐,大幅降低了开发效率。SmartIDE所采用的集成了IDE工具的工作区可以很方便的部署到这些硬件环境中,让开发者直接在这些硬件上进行开发调试,大幅提升日常工作效率。
3 - 开发语言和中间件支持
全语言技术栈支持,为不同开发语言技术栈提供一致的开发环境启动方式。
SmartIDE中的开发语言支持只可扩展,可插拔的。通过IDE配置文件,开发者镜像和模板的配合,开发者可以将任何可以在容器中运行的开发语言SDK与SmartIDE进行适配,整个适配过程无需修改SmartIDE本身的代码逻辑。当前我们已经提供的开发语言支持包括:
- JavaScript/Node
- Java
- C# (跨平台版本,包括:.net core 和 .net 6以上,暂时不支持.net framework)
- Python
- Golang
- PHP
- C/C++
- Anacoda (Juypter Notebook)
对于各种类型的中间件的支持方式也是一样的,任何剋有在容器中运行的中间件均可以适配到SmartIDE工作区中使用。当前我们已经提供支持的中间件以及配套工具包括
- MySQL + PHPMyAdmin
- Redis
- Nacos
4 - 产品架构
对SmartIDE所包含的产品组件和相互关系进行介绍
SmartIDE 由4个组件组成,分别是CLI, Server,开发者镜像和模板,插件市场。
组件说明
CLI 是所有组件的核心,SmartIDE的远程/云端工作区能力全部都封装在这个大小只有50M左右的命令行工具中。可以说,这个小小的命令行工具的能力等同于一个CloudIDE系统(比如:Github Codespaces, AWS Cloud 9, 腾讯Code Studio等等),任何人都可以安装这个CLI工具并在自己选择的硬件/虚拟机/k8s上自助部署属于自己的CloudIDE系统。CLI的功能非常单纯,它只负责一件事情,就是按照 IDE配置文件(.ide.yaml)文件 的描述,完成对远程/云端工作区的生命周期管理。
Server 是在CLI的基础上提供的WebUI访问方式,为用户提供更加友好的交互方式以及承载企业级特性的平台。Server本身不会直接维护远程/云端工作区的状态,所有针对工作区的操作全部通过CLI完成。
开发者镜像 & 模板 是交付标准化环境的载体,通过提供预制的Docker镜像和环境模板,SmartIDE可以在无需修改系统代码的前提下适配各种不同类型的环境,包括:IDE工具,开发语言和SDK,应用依赖的中中间件,应用服务器以及专属工具等等。开发者镜像和模板支持用户自定义,用户可以自由的使用自有的镜像以及模板库来支持高度定制化的场景。
插件市场 是为IDE工具(当前只支持类VSCode IDE,未来也会支持JetBrains系列)提供的插件集中管理能力。
私有部署优先
SmartIDE 的设计目标是企业用户,因此我们优先支持私有部署,以上所有组件均可以在公网或者私有隔离网络中进行部署,为企业用户提供完整闭环的云端IDE解决方案。
CLI设计目标
全功能独立工作
CLI是SmartIDE产品架构中与其他类似产品最大的差异。大多数CloudIDE都会提供CLI工具,但是这些CLI都是作为辅助性工具存在的,也就是说用户使用CLI连接到CloudIDE服务来完成类似端口转发,如果脱离的CloudIDE服务,这些CLI本身是无法单独使用的。
SmartIDE的CLI则不同,用户可以使用CLI直接创建、停止,删除,清理远程/云端工作,这个过程无需CloudIDE服务(SmartIDE Server)的存在。
这样设计的目的是为了方便个人开发者可以非常轻量的管理自己的远程/云端工作区,无需预先部署Server。这样,个人开发者可以在需要的时候使用一个 smartide start 指令即可在任何资源上启动远程/云端工作。
快速迭代
从开发和调试的角度来说,CLI工具的迭代速度是带有WebUI或者API类型的应用无法比拟的。因为CLI极度简单的操作方式,我们无需处理界面的布局,美观,操作体验,各种边界条件等问题,可以专注于业务目标的实现。这种快速迭代能力让我们可以更早的触达用户,验证产品核心功能并及时调整产品方向。在过去的6个月,CLI的发布速度是平均每天3.8个版本。
可集成性
CLI封装了管理远程/云端工作区的所有能力,这让用户利用CLI来搭建自己的CloudIDE系统,实际上SmartIDE Sever 本身就是这样工作的,通过将 CLI 打包成 tekton流水线任务,SmartIDE Server 的所有工作区操作都不会直接调用虚拟机或者k8s集群,而是通过CLI来完成。借助CLI的快速迭代特性,我们的Sever开发人员可以更加专注于用户体验和企业级功能,而不用关心底层工作区调度问题。
对于希望构建企业内部CloudIDE平台的组织来说,利用CLI的这种可集成特性,可以非常快速底层本的完整平台的搭建,不用去关注与虚拟机以及k8s集群进行操作的细节问题。
我们当前已经提供了gitlab-ci的集成示例,未来我们会提供更多各种类型的DevOps系统场景。
5 - IDE支持
我们不会发明另外一个IDE,我们你使用自己喜欢的IDE,并更加高效。
作为工作区(远程/云端)与用户之间的交互方式(Interface),IDE工具是开发者的入口。为了能够让开发者使用自己喜欢的IDE工具,SmartIDE可以引入任何能够提供WebUI的工具作为IDE入口,从实现上来看,实际上就是一个WebApp而已。
当前,SmartIDE支持4种IDE接入方式,分别是
- WebIDE:任何可以提供WebUI的协助开发者进行软件开发的工具均被被认为是IDE的组件,比如
- VSCode WebIDE:我们内置提供了基于OpenVSCode Server的WebIDE支持
- JetBrains Projectors:Projectors是JetBrains提供的全系列IDE的WebUI版本,可以通过浏览器访问呢,界面和功能上和JetBrains的桌面IDE保持一致。当前我们内置提供了以下Projectors支持(根据不同的开发语言)。
- IntelliJ IDEA
- WebStorm
- Goland
- PyCharm
- Rider
- PHPStorm
- Clion
- OpenSumi:阿里蚂蚁开源的WebIDE开发框架
- Eclipse Theia: Eclipse基金会旗下的开源WebIDE开发框架(有限支持)
- SSH Remote 接入:开发者可以通过SSH协议,使用本地的终端程序,VSCode Remote SSH插件,JetBrains Gateway或者任何支持SSH远程接入的工具连接到SmartIDE工作区进行操作。
- Web Terminal 接入:SmartIDE工作区提供 webterminal addon,可以在现有工作区上提供浏览器内访问的终端程序,并允许用户进入工作区内的任何容器进行操作。使用Web Terminal不需要工作区对外暴露SSH端口。
- 其他Web应用:开发者在工作中还需要各种类型的第三方工具来管理工作区种的各类资源,比如:如果工作区内使用了MySQL作为后天数据库,那么开发会希望使用PHPMyAdmin来通过浏览器管理数据库,协助完成日常开发调试。类似的场景均可以通过SmartIDE的IDE配置文件实现。当前已经支持的其他Web应用工具包括:
- PHPMyAdmin
- Nacos
- Juypter Notebook
6 - IDE配置文件
IDE as Code
IDE配置文件是SmartIDE的真正内核,无论是CLI, Server,开发者镜像和模板都是围绕IDE配置文件的规范进行实现的。IDE配置文件的设计灵感来自:如何让README文件活起来(参考:博客README.exe)。作为开发者,拿到一个新的代码库的时候一般都会先去看README文件,通过这个文件可以知道这套代码所需要安装的环境,工具和操作方式。但是README只能由人来阅读理解只有手工操作,这就引入了大量的不确定性,造成了很多开发者在搭建环境上浪费了太多时间。在开发过程中我们也经常会对环境进行变更而忘记更新README,这就会造成其他开发者的困扰以及后续持续交付流程的不稳定。
为了解决这个问题,我们设计了一个 IDE配置文件 (默认文件名 .ide.yaml)文件格式。这个文件中完整描述了运行当前代码所需要的环境配置,包括 基础环境SDK,应用服务器,应用端口,配置文件,网络依赖以及所使用的IDE工具。有了这个文件,开发者就可以真正实现一键启动开发调试,而不会再听到:“在我这里工作呀,是你的环境问题!” 这种骇人听闻的抱怨。
以下是一个典型的IDE配置文件的示例:
示例来源:https://gitee.com/idcf-boat-house/boathouse-calculator/blob/master/.ide/.ide.yaml
version: smartide/v0.3
orchestrator:
type: allinone
version: 3
workspace:
dev-container:
service-name: boathouse-calculator-dev
ports: # 申明端口
tools-webide-vscode: 6800
tools-ssh: 6822
apps-application: 3001
ide-type: vscode #vscode/jb-projector/theia/opensumi
volumes:
git-config: true
ssh-key: true
command:
- npm config set registry https://registry.npmmirror.com
- npm install
kube-deploy-files: "k8s-deployment.yaml"
docker-compose-file: "docker-compose.yaml"
这个文件内容非常通俗易懂,是个程序员应该都能看明白,不过我还是简单说明一下:
- orchestrator - 环境调度工具设置,用来制定调度容器环境的底层工具,我们当前支持3种调度方式
- allinone:同时提供docker-compose和k8s mainfest,可以同时支持本地,远程主机和k8s模式
- docker-compose: 仅使用Docker Compose进行调度,只适用于本地和远程主机模式
- k8s: 仅使用k8s进行调度,只适用于k8s模式
- workspace - 工作区配置,工作区 是SmartIDE中最重要的概念,包含开发者用来进行开发调试的所有环境信息
- dev-container - 开发者容器设置
- service-name - 开发者容器所对应的 docker-compose 服务名称
- ports - 开发者容器对外暴露的端口
- ide-type - 开发者容器所所用的IDE类型,支持:vscode, sdk-only, jb-projector (Jetbrains系列全家桶)和 opensumi
- volumes - 配置映射,支持将开发者的git-config和ssh密钥导入容器
- commands - 开发环境启动脚本,对环境进行初始化;比如以上脚本中就完成了2个关键操作:1)设置npm国内镜像源 2)获取npm依赖。这部分脚本开发者可以根据自己代码库的情况设置,SmartIDE会在环境启动后自动运行这些脚本,让程序处于开发者所希望的状态上。
- kube-deploy-files:k8s模式所使用的k8s manifest文件路径,支持目录或者单一文件
- docker-compose-file: 本地和远程主机模式所使用的docker-compose文件路径
以上所使用的docker-compose和k8s manifest兼容业界标准的文件格式,开发者可以直接链接现有的编排文件。
IDE as Code
这种做法称为 IDE as Code 也就是 “集成开发环境即代码”,将你的开发环境配置变成一个 IDE配置文件 的配置文件放置在代码库中,然后根据这个配置文件生成对应的自动化脚本,完成“集成开发环境” 的创建。
IDE as Code 的做法源自DevOps的核心实践 Infrastructure as Code ,也就是 “基础设施即代码” 简称 IaC。其核心思想是将环境配置代码化,常见的k8s的yaml文件其实就是典型的基础设施即代码实现。在运维领域常用的工具比如chef/puppet/ansible,还有 HashiCorp 的 Terraform 也都是 IaC 的经典实现。IaC 的主要价值和目标就是将环境搭建过程标准化,让任何人在任何环境中都可以获得 一致、稳定、可靠 的环境搭建体验。SmartIDE所创造的 IDE配置文件 延续IaC了的使用场景,并将其基本思路应用到了开发测试环境中,这其实就是 SmartIDE 的产品核心能力。
基于 IDE as Code 的实现,SmartIDE在产品实现过程中一直秉承一个原则:能够让用户通过配置文件实现的东西,就不要通过代码实现。这个核心原则给予了SmartIDE非常强的灵活性,比如以下这段视频中所演示的 若依管理系统 项目。
描述性配置
描述性配置是IaC的核心原则,用户只需要告诉IaC系统目标是什么,而不用关心如何实现。在现代软件系统环境越来越复杂的背景下,如果开发者为了完整应用的开发还需要去学习容器,网络,集群编排,存储,安全配置等等内容是不现实的。因此SmartIDE将这些复杂度全部封装在CLI中,将那些用户需要控制的变量通过IDE配置文件交给用户管理,这样就可以让开发者享受云原生技术带来的好处而不必关心背后的复杂度。
IDE配置文件的解析工作全部通过CLI完成,作为外围界面的Sever无需了解IDE配置文件的结构和工作方式。CLI为最终用户提供了使用IDE配置文件的能力,Sever本身也只是一种“用户”类型。
开发者镜像和模板需要符合IDE配置文件的约定,确保这些镜像和模板可以被CLI调度。
7 - 远程工作区
远程工作区(Remote Workspace)是SmartIDE中的最重要的概念,SmartIDE的所有功能都是围绕远程工作区展开的。SmartIDE支持3种远程工作区运行模式,本地模式、远程模式和k8s模式。
远程工作区(Remote Workspace)是SmartIDE中的核心概念,远程工作区为开发人员提供某个应用开发所需要的完整组件,一般来说会包括:代码库、代码编辑器、开发语言SDK、开发调试工具、测试工具、依赖环境/中间件以及管理工具。SmartIDE使用一个叫做 .ide.yaml 的文件对这些组件进行描述,并通过容器的方式标准化这些组件的获取过程,达到简化开发环境管理的目标。
为什么一定要是 “远程”
远程工作区强调的是工作区与所在环境是隔离的(采用容器技术),开发者与工作区之间的互动是通过远程方式(api, 浏览器,ssh等方式)。远程工作区也可以运行在开发者的本地开发机上,只是工作区内的资源与开发者的机器上的其他资源一直保持隔离状态。更常见的场景是运行在远程主机或者k8s环境中。这样做的目的是为了能够将工作区的资源标准化和统一,并且允许在不同的工作区之间进行 工作区漫游。
工作区漫游
所谓漫游,就是允许开发者在不同的环境之间随意的迁移自己的工作上下文,而且在迁移过程中保持工作不中断。SmartIDE 的远程工作区采用了 IDE as Code
技术,所有工作区相关的内容都可以通过 3个标准化对象 完整保存和移动:
- 开发者镜像:提供远程工作区的标准化环境基础,包括:底层库、开发语言SDK和工具、IDE工具和其他配套工具;
- 代码库:提供当前项目的代码;
- 持久化数据集:开发者对环境的修改,临时配置变更和中间状态。
经过以上抽象,我们可以通过 IDE配置文件
将这3个标准化对象链接到一起,形成一个 远程工作区 的完整数据对象。SmartIDE 的所有工具处理逻辑都是围绕这3个标准化对象展开的。
有关 IDE as Code 的概念解释请参考以下文档和博客:
localhost访问
SmartIDE远程工作区集成了 SSH隧道 技术,无论你采用那种以下哪种方式启动远程工作区,SmartIDE CLI都会自动帮助你建立起本地开发机和远程工作区资源之间的隧道,并将远程工作区内部资源的端口转发到 localhost
上,这样你就可以完全通过 localhost:<port>
来访问这些资源,而不用关心这些资源具体运行在本地、远程主机或者k8s集群中。
这样做的另外一个好处是,如果你已经习惯了使用一些开发环境管理工具,比如:MySQL Workbench来连接你的MySQL服务器,那么对于SmartIDE远程工作区种的MySQL服务器就可以直接通过 localhost:3306
来访问;这种体验和MySQL服务器就运行在你本地开发机上完全一致,但是又不会占用你的本地资源。
使用 SSH隧道 技术的另外一项优势是:避免了在远程服务器环境(linux主机或者k8s集群)上对外暴露端口,因为所有的转发都通过 SSH隧道 完成,因此远程服务器资源只需要提供最基本的访问方式,而不必另外打通防火墙或者进行额外的网络配置。
一般来说SmartIDE远程工作区都提供WebIDE和SSH终端方式,那么你就可以通过
http://localhost:6800
访问WebIDE (6800是SmartIDE内集成的WebIDE的惯用端口号)ssh smartide@localhost -p 6822
访问远程工作区的终端 (6822是SmartIDE远程工作区内置的SSH服务的惯用端口号)
注意: 为了避免因为端口占用造成端口转发失败,SmartIDE CLI会自动检测当前端口被占用的情况,并自动将端口值增加100以便避免冲突。
四类远程工作区
SmartIDE的远程工作区可以通过以下4种方式启动,覆盖开发者所需要的所有使用场景:
- 本地远程工作区:远程工作区运行在开发者自己的开发机上,开发机可以是Windows, MacOS或者是Linux均可。
- 主机远程工作区:远程工作区运行在linux主机上,这台linux主机可以运行在任何位置(本地虚拟机、局域网中或者云端),只要开发者可以通过SSH访问这台主机即可。
- k8s远程远程工作区:远程工作区运行在k8s集群中,一般来说一个远程工作区就是一个pod。
- server远程工作区:开发者在SmartIDE Server的网页上启动的远程工作区,可以以远程模式或者k8s模式运行。严格来说,Server模式并不是一个独立的模式,而是远程模式和k8s模式的另外一种操作方式。
本地远程工作区
本地远程工作区完全运行在开发者自己的开发机上面,但是采用容器的方式运行。开发者可以使用Windows,MacOS或者Linux三种操作系统中的任何一种运行本地远程工作区,唯一的前提条件是已经安装了 Docker桌面版 工具,具体的安装方式请参考我们的 安装 文档。
启动本地远程工作区的cli指令非常简单,只需要运行以下一个指令即可:
主机远程工作区
远程主机远程工作区运行在linux主机上,同样采用容器的方式运行。这台linux主机可以运行在任意位置,包括:本地虚拟机(VirutalBox/VMWare/HyperV),本地网络上的服务器或者云服务器;唯一的要求是开发者可以通过SSH直接登录这台主机。
启动远程主机远程工作区并不需要开发者在远程主机上安装 SmartIDE CLI 工具,开发者只需要按照我们的 安装 文档对linux主机进行初始化以后,即可在本地开发机上使用 SmartIDE CLI 工具远程操作这台linux主机。在这种场景下,开发者本地的开发机也不需要安装 Docker桌面版 。
启动远程主机远程工作区的cli指令也非常简单:
## 添加远程主机到SmartIDE主机资源列表
smartide host add <远程主机的IP地址> --username <SSH登录用户名> --password <SSH密码/如果使用key的方式认证则不需要输入>
## 获取SmartIDE主机资源列表
smartide host list
## 通过<主机ID>在远程主机上启动项目
smartide start --host <主机ID> <代码库Url>
k8s远程工作区
k8s远程工作区运行在k8s集群中,采用容器的方式运行。开发者需要首先获取k8s集群的操作密钥并且在本地安装好Kubectl工具,接可以通过 SmartIDE CLI 工具在k8s其中启动远程工作区。在这种情况下,开发者本地的开发机也不需要安装 Docker桌面版 。
## 在K8s集群上启动项目
smartide start --k8s <实例名称> --namespace <命令空间名称> <代码库Url>
Server远程工作区
SmartIDE Server为用户管理远程工作区提供可视化的网页操作,但是Server远程工作区本质上仍然是运行在远程linux主机上的工作区或者运行在k8s集群中的工作区。SmartIDE Server允许用户讲自己的linux主机或者k8s集群注册到资源列表,并通过 远程工作区管理 页面创建server远程工作区。
在用户使用Server远程工作区的过程中,需要使用SmartIDE CLI执行 smartide connect
指令允许cli监听正在运行的Server远程工作区列表并建立 SSH隧道 以便用户可以继续使用 localhost:port
的方式访问远程工作区资源。
对于运行在k8s中的工作区,SmartIDE Sever会自动创建Ingress 3级域名映射,为每个工作区(及其资源)提供访问通道,同时可以提供基于SSH协议的远程终端访问能力。
8 - SmartIDE插件市场
SmartIDE插件市场针对中国开发者的使用习惯和网络状况对这个开源项目进行了本地化,提供中文界面和中国大陆本地化下载地址,大幅提升国内开发者的使用体验。同时,SmartIDE插件市场也支持在企业内部进行私有部署,在封闭/受控网络内提供IDE插件的集中管理。
SmartIDE插件市场是基于 Eclipse OpenVSX server 开源项目的一个fork,我们针对中国开发者的使用习惯和网络状况对这个开源项目进行了本地化,包括:界面的中文翻译处理和将插件同步到中国大陆的地址上供开发者下载使用。同时,对于无法直接使用微软官方marketplace的类VSCode IDE来说,比如:Codium, Code Server 和 OpenVSCode Server这些VSCode fork,可以使用SmartIDE 插件市场作为自己的插件市场,方便这些工具的使用者获取与VSCode类似的插件安装体验。
现今非常多的企业开发者在使用VSCode作为自己的主力IDE工具,但是由于很多企业对开发者连接互联网有严格的限制,大多数企业开发者都在采用离线安装的方式来获取VSCode的插件,这样做不仅操作繁琐,而且没有办法及时获取插件的更新,同时也会对企业的研发管理带来直接的安全隐患。
SmartIDE 插件市场 的目标并不是替代微软的Marketplace或者 Eclipse 的 open-vsx.org 而是希望为国内的开发者以及企业内部的开发者提供一种安全可靠,而且高效的插件管理机制。
SmartIDE 插件市场 与 Eclipse OpenVSX 一样是开源项目,并且我们提供了国内Gitee的开源库地址与Github保持同步,开源库地址如下:
相关文档和常见问题如下:
- 部署手册
- 操作手册
- 配置连接 :如何更新Visual Studio Code以及兼容IDE的配置文件连接到SmartIDE 插件市场,包括:VSCode, Codium, Code Server, OpenVSCode Server和OpenSumi
- 插件安装:如何使用SmartIDE 插件市场安装插件
- 插件同步:SmartIDE 插件市场 插件初始化同步机制
- 插件发布:如何发布插件到 SmartIDE 插件市场
- 私有化部署
技术架构
SmartIDE插件市场各模块整体架构如下图所示
- 主体为OpenVSX-Server,spring boot框架的java服务,我们在部署时需要自行添加 application.yml 配置文件,并将其放置对应位置,以便Server启动后加载。
- 后台数据库使用PostgreSql,并使用Pgadmin进行数据库的管理和查询等操作,数据库的创建和表结构的初始化过程Server进程启动时会自动执行。
- 前端界面为NodeJS架构的Web UI,我们在部署时会将前端代码库构建的静态网站结果放入Server服务的对应文件夹,使其二者变为一个进程即Server进程加入前端界面。这也是Sprint Boot框架的灵活性功能,使用者可以基于Web UI代码库自定制前端界面,并将自定制的前端页面嵌入Server服务。
- 用户登陆验证,目前只支持OAuth Provider,官方文档中声明目前只支持Github AuthApp和 Eclipse OAuth,我们在部署时使用Github AuthApp。
- 插件存储可以使用数据库(默认)、Google Storage或 Azure Blob Storage三种模式,推荐添加Google Storage或 Azure Blob Storage以避免数据库过大的情况出现。
- 插件搜索服务支持数据库搜索和附加Elastic Search服务两种模式,推荐有条件的情况下添加Elastic Search搜索服务提高搜索效率,降低数据库压力。
9 - 开源协议
SmartIDE的所有组件均采用开源的方式提供给个人,团队和企业使用;不同的组件采用了不同的开源协议,请用户遵守开源协议。
SmartIDE已经加入开放原子基金会,由基金会和LEANSOFT一同运营。欢迎社区的小伙伴参与项目的开发和共建。
SmartIDE的所有组件均采用开源的方式提供给个人,团队和企业使用;不同的组件采用了不同的开源协议。
- CLI 采用GPL 3.0开源协议
- Server 采用Apache 2.0 开源协议
- 开发者镜像 & 模板 采用 GPL 3.0开源协议
- 插件市场 采用EPL开源协议,是Eclipse OpenVSX Server的一个Fork