Gitpod Usage and a Simple Principle Analysis

Gitpod is a web-based VSCode that can open Github projects directly. When I first used it, it only offered the web version — quite inconvenient. Retrying it a few days ago, I found it can already open the local VSCode directly, similar to remote ssh functionality. This tool feels full of potential; interested readers can find a Github project and explore. Here I briefly analyze the usage and principles; the second half explores the future direction of development modes and development tools.

I’m a Python backend programmer mainly responsible for PaaS platform governance; the descriptions in this blog are merely my own views.

Simple Usage

1. Install the Gitpod extension, or log into Gitpod directly with a Github account

2. Find a Github project and open it

3. The web-side effect

4. Opening in the local VSCode is now also supported; after opening, the effect matches ordinary remote ssh

After jumping over, it first installs the Gitpod extension, then opens

5. If you want to log in with local ssh, that’s also possible — you can see the concrete ssh configuration here

This is the login command:

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

Pod Internal Information and ssh Working Principle Analysis

Inside the Pod, supervisor is used to start things; sshd and the vscode web service are fairly normal. Rather unexpectedly, it supports running docker inside docker.

# the system is `Ubuntu 20.04`
gitpod ~ $ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"

# can switch directly to the root user
gitpod ~ $ sudo su
# looking with visudo, users in the sudo group need no root password
# gitpod ~ $ visudo
# %sudo ALL=NOPASSWD:ALL


# this address comes from GCP
gitpod ~ $ curl ip.sb 
34.127.117.8

# this workspace directory is mounted in, so the contents above should persist
# I'm a bit puzzled why it isn't mounted at /home/gitpod/workspace — that feels more reasonable
gitpod ~ $ df -Th
/dev/md42        xfs       30G  114M   30G   1% /workspace


# an sshd service is started locally, though the port isn't the default 22 but 23001. But the permission given here is too large — this sshd should just listen on 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))

The supervisor Process

I initially thought this supervisor was the Python one; later I searched the code on the Github official site and found it’s a self-written Golang service:

The VSCode Remote Connection Method

When opening with the local VSCode, you can see an ssh target here:

Its config file looks like:

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

It looks like it directly connects to a local port. Who created this port? Searching around, it’s gitpod-local-co. This operation should be similar to frp’s stcp mode — mapping the remote ssh port to local.

# 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 shows users in the %sudo group can switch directly to root without a password. gitpod belongs to this group, so the sudo command works directly.

Problems to Consider

1. VSCode currently allows only one ssh config file, so it invalidates the user’s own config file — quite a pitfall

1. The pod’s internal ssh port should listen only on 127.0.0.1, because this port is mapped out for use — avoid the Pod being directly accessed externally
2. Mind the pod’s ssh key — regenerate it each time a pod is created
3. The pod’s lifecycle must be short; ideally it exits immediately when VSCode closes. Some may think the pod should keep running in the background, but that actually increases risk. For background-type tasks, use online containers rather than containers in development tools; and once this container has a security problem, it may affect all of the user’s repositories.
4. Every application of every user needs its own separate pod to avoid mutual influence.
5. Authentication is important — permission control must be done well when the tunnel establishes the connection; only authorized users get local connection ports established. During intranet penetration, unauthorized users simply don’t get it done
6. How to prevent user abuse: we provide a full-featured root shell — users with ulterior motives will definitely freeload and mine coins.

A Few Short-Term Optimization Points

1. Extract the main code: Gitpod’s current server side should be made into a separate service. After starting, it can be seen directly in Gitpod’s web backend, and VSCode can be called directly to open the workspace. This way the server can run in the user’s own container, solving intranet penetration for user-built containers and the unavailability of the VSCode web version — THIS is the feature individual users want

2. Custom image functionality: for a given repository, users should be allowed to customize the Dockerfile or use custom images, indirectly standardizing development environments

3. Instant opening: since the Pod must stop serving after VSCode closes, how to achieve instant opening next time? I think on closing you can delete the ssh key, dynamically adjust cpu to 0.01 cores, ensuring no access and no external service. When the user reopens, generate a new key and raise the cpu limit — much faster than restarting the container.

4. External service access: for backend code, seeing effects immediately after modification is most important — VSCode’s port mapping can forward to local. When demoing to others, ports can also be temporarily mapped to the public network or the development environment.

Disadvantages of Local Development Environments

1. Everyone’s development environment easily becomes inconsistent; even with detailed code norms, each person must reconfigure an environment locally for the code
2. Code hint tools demand ever more performance. Using TabNine locally, one project’s memory reaches 10+ GB — my 16G computer isn’t enough. And Copilot — I dare not use it locally either
3. Personal computers rarely consider disk redundancy techniques, and backups probably aren’t done often — code files may be lost

Development environments moving to the cloud should be a trend. Whether VSCode’s remote ssh feature or JetBrains’ newly launched Fleet, both convey this signal.

Gitpod’s Future Development

1. Establish the main use: from my personal perspective, Gitpod is very suitable for remote development and debugging of non-compiled languages — especially Python, Ruby, NodeJS. Even for Python applications, you could completely package and restart the production environment container, developing and debugging in Gitpod’s environment — equivalent to having a development environment completely identical to production.

2. Separate personal and enterprise editions: for individual developers, provide public cloud services, possibly with billing. For enterprises, an enterprise edition should be provided, because future remote development environment features will certainly be self-built inside enterprises — they’re unlikely to put internal code in public cloud environments. If a solution suitable for enterprises can be provided, and people use it, it should operate sustainably.

Summary

I’d been using github1s and github.dev to read code before discovering Gitpod. Compared with those two read-only tools, Gitpod provides a much more complete experience: you can use it to push code, fully take over development work — an experience users will love. I hope the community edition survives long; I don’t have many open source projects, but if there’s real need, I’d gladly use this tool further and pay.

I’m not a product manager; the later content merely explores the project’s future development trends from my own views — maybe it’s all nonsense.