git VSCode

Gitpod是一个可以直接打开Github项目的的网页版VSCode, 我一开始使用的时候, 它仅提供了网页版, 使用起来十分不便. 前些天再去试用时, 发现已经可以直接打开本地的VSCode, 类似remote ssh的功能, 感觉这个工具潜力很大, 有兴趣的读者可以找个Github项目探索下. 这里我就简单分析下使用方式和原理, 后半部分是对于开发模式和开发工具未来方向的探讨.

我是Python后端的程序员, 主要负责PaaS平台的治理, 博客中的描述仅仅是自己的一些见解.

简单使用

  1. 安装Gitpod插件, 或是直接用Github帐号登录Gitpod

  2. 找个Github项目打开

20211211234902

  1. 网页端效果

20211211235019

  1. 现在也支持了在本地VSCode中打开, 打开后的效果就和普通的remote ssh一致

20211214094151

跳转过去之后, 会先安装Gitpod插件, 然后再打开

  1. 如果你想用本地的ssh登录, 也可以, 看这里就能看到具体的ssh配置

20211215093059

这是登录命令:

1
ssh -F /tmp/gitpod_ssh_config-216243-zxK2tQ5tHG0H  moccasin-capybara-78upia72

Pod内部信息以及ssh工作工作原理解析

20211214100028

Pod内部是用supervisor来启动, sshd, vscode web服务是比较正常的, 令人比较意外的是它支持了docker内部运行docker.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# 系统是`Ubuntu 20.04`
gitpod ~ $ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"

# 可以直接切换到root用户
gitpod ~ $ sudo su
# 用visudo来看的话, 可以看到在sudo组里的用户不需要root权限密码
# gitpod ~ $ visudo
# %sudo ALL=NOPASSWD:ALL


# 这个地址是来自于GCP
gitpod ~ $ curl ip.sb 
34.127.117.8

# 这个workspace目录是挂载进来的, 所以上面的内容应该会保留
# 我有点奇怪, 为什么不把它挂到 /home/gitpod/workspace, 感觉可能更加合理
gitpod ~ $ df -Th
/dev/md42        xfs       30G  114M   30G   1% /workspace


# 本地启动了sshd服务, 不过端口不是默认22, 而是23001, 但是这里权限给的太大了, 这个sshd监听127.0.0.1就可以了
gitpod / $ sudo ss -tunlp
Netid  State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port  Process                              
tcp    LISTEN  0       128         10.0.2.100:40799        0.0.0.0:*      users:(("supervisor",pid=1,fd=38))  
tcp    LISTEN  0       511          127.0.0.1:40799        0.0.0.0:*      users:(("node",pid=1084,fd=19))     
tcp    LISTEN  0       128                  *:22999              *:*      users:(("supervisor",pid=1,fd=10))  
tcp    LISTEN  0       511                  *:23000              *:*      users:(("node",pid=348,fd=19))      
tcp    LISTEN  0       128                  *:23001              *:*      users:(("supervisor",pid=1,fd=8))

supervisor进程

我一开始以为这个supervisor是Python的那个, 后来我去Github官网找了找代码, 发现它是一个自己写的Golang服务:

20211215100134

VSCode远程连接方式

使用本地的VSCode打开时, 可以看到这里有一个ssh target

20211216092225

其中的配置文件类似如下:

1
2
3
4
5
Host moccasin-capybara-78upia72
HostName 127.0.0.1
User gitpod
Port 36129
IdentityFile /tmp/gitpod_bb1491a6-d26d-4e40-b0ae-d0b34a2d19f3_id_rsa

看起来它是直接连接了一个本地的端口, 具体这个端口是谁创建的呢, 找了一下是gitpod-local-co, 这个操作应该是类似frp的stcp模式, 把远程的ssh端口映射到了本地.

1
2
# ss -tunlp  | grep 36129
tcp   LISTEN 0      4096                                        127.0.0.1:36129      0.0.0.0:*    users:(("gitpod-local-co",pid=217415,fd=14))

su root

visudo可以看到%sudo组的用户可以不需要密码直接切换到root, gitpod属于这个组, 所以sudo命令直接可以用.

需要考虑的问题

  1. VSCode当前只允许添加一个ssh配置文件, 因此会令用户自己的配置文件失效, 很坑

  1. pod内部的ssh端口, 应该仅监听127.0.0.1, 因为这个端口是被映射出去使用的, 避免Pod直接被外部访问
  2. pod的ssh key要注意, 每次生成pod时要重新产生
  3. pod的生命周期一点要短, 最好VSCode关闭时就马上退出, 也许有人认为pod应该一直在后台运行, 但是这样其实加大了风险, 如果想要运行后台类型的任务, 应该用在线的容器, 而不是开发工具中的容器, 而且这个容器一旦出现安全问题, 可能会影响这个用户的所有仓库.
  4. 每个用户的每个应用都器要有自己单独的pod, 避免互相影响.
  5. 鉴权很重要, 需要在穿透建立连接时就把权限控制做好, 只有有权限的用户才会在本地建立连接端口, 内网穿透时, 没有权限的用户就不给做
  6. 如何防止被用户滥用, 我们提供了一个完整功能的root shell, 别有用心的用户一定会薅羊毛挖矿.

几个短期优化点

  1. 抽离主要代码: Gitpod中当前服务端, 应该做成一个单独的服务. 启动之后, 可以直接在Gitpod网页后台中看到, 并且可以直接调用VSCode打开工作区, 这样, 可以在用户自己的容器中运行服务端, 解决用户自建容器的内网穿透和VSCode web版无法使用的功能, 这个才是个人用户想要的功能

  2. 自定义镜像功能: 针对某个仓库, 应该允许用户自定义Dockerfile, 或是自定义镜像, 间接实现开发环境规范化

  3. 实现秒开: 因为Pod需要在VSCode关闭后停止服务, 那么用户下次打开时, 如何做到秒开呢? 我认为可以在关闭时, 删除ssh key, 动态的调整cpu到0.01核, 确保无法访问, 无法对外服务. 用户重新打开时, 再生成新的key, 调大cpu限制, 相比于重新启动容器应该会快很多.

  4. 服务对外访问: 对于后台代码, 修改之后能够立刻看到效果是最重要的, 可以利用VSCode的端口映射功能转给本地. 需要给别人演示时, 也可以将端口临时映射到公网或是功能开发环境中.

本地开发环境的劣势

  1. 每个人的开发环境很容易不一致, 即使有详细的代码规范, 每个人需要针对代码在本地重新配置一份环境
  2. 代码提示工具对性能的要求越来越高, 我在本地上用TabNine, 一个项目内存会占到10多个G, 我16G的电脑不够用的. 还有Copilot, 我本地也不敢用
  3. 个人的电脑很少会考虑磁盘冗余技术, 备份很可能也不经常进行, 可能存在代码文件丢失问题

开发环境上云应该是一种趋势, 无论是VSCode的remote ssh功能, 还是JetBrains新推出的Fleet, 都传达出了这么一种信号.

Gitpod未来发展

  1. 确立主要用途: 从我个人角度来看, Gitpod十分适合于远程调试开发和调试非编译型语言, 尤其适合于Python, Ruby, NodeJS, 甚至对于Python应用, 完全可以把线上环境容器打包重新启动, 在Gitpod中的环境中进行开发调试, 相当于拥有了一个于线上环境完全一致的开发环境.

  2. 个人版与企业版分离: 针对个人开发者, 提供公有云服务, 可以考虑计费. 针对企业应该提供企业版, 因为未来即使有远程开发环境的功能一定是企业内部自建的, 因为它们不太可能将内部代码放在公有云环境中, 如果能提供一套适合企业的解决方案, 并且有人用, 应该能长久运营.

总结

我之前就有在使用github1s和github.dev来读代码, 直到发现了Gitpod. 相比于前两个仅能读代码的功能, Gitpod提供了更加完善的体验, 你可以利用它push代码, 可以完整的接手开发工作, 这一点带给用户的体验会很好. 希望社区版能长久的存活下去吧, 我的开源项目不多, 如果真的有需要, 我很愿意进一步使用这个工具并且付费.

我不是产品经理, 后面的内容单单就我自己的看法探讨一下项目未来的发展趋势, 可能就是在瞎扯吧.