Setting Up a Cloud Development Environment

A long time ago, I was interested in a special operating system made in China called FydeOS. It is based on ChromiumOS and is a Chinese version of ChromeOS. The main idea behind this operating system is that many people do not need high-performance terminal computers for work; they just need an entry-level device that can access essential work services through a browser.

This concept is indeed very interesting, making me think about the different philosophies of version control software like Git and SVN. Git follows a distributed model where each developer has a complete copy of the project code with their own branches. On the other hand, SVN uses a centralized model where users access only the parts they need through a service.

Personally, I believe that neither distributed nor centralized models are inherently better; they have different applications depending on the situation. In my current work, everything is in a completely distributed manner without any backups, with both the working environment and content located on my personal or company computers. If one day my device fails… it would take quite some time to recover. Additionally, if I need to urgently handle something but the device is not nearby or has no power… there’s nothing much I can do except worry.

So, I also want to try whether my current work can be fully cloud-based. That is, deploying a series of self-hosted services and completing all work through browsers or other development tools that support remote projects, with actual execution happening on the server side.

All Software Needed for My Work

In bioinformatics, it’s essentially about writing scripts, creating statistical graphs, refining graphics, and writing various kinds of documents. The software I actually use includes:

Code writing/testing: VSCode, Jupyter
Environment deployment: conda, docker
File organization: System自带的文件管理器
Document processing: WPS series
Literature review: Zotero
Image processing: GIMP

What is Needed to Set Up a Cloud Development Environment

To achieve a fully cloud-based work environment, ideally, all the above software should have self-hosted cloud versions that can solve the following issues:

Code writing/testing: code-server, Jupyter is already a service and can be accessed remotely.
Environment deployment: Remote SSH login or find a web terminal emulator.
File organization: Nextcloud, firerun
Document processing: only office server
Literature review: paperpile (paid)

In summary, the only thing left is image editing… I haven’t found any self-hosted solutions yet. I’ll continue to keep an eye on this.

Attempt

ML-Hub / ML-Workspace Configuration

ML-Hub / ML-Workspace is a container-based multi-network service integration project that includes JupyterHub with many plugins, code-server, and a simple file manager. If not for user permission issues when running Docker, it would instantly solve about 60-70% of the problems…

Both are relatively easy to use; after installing Docker or Podman, you can start the services directly.

Intranet Penetration (nps)

nps is a Go language-based… composite network tool? One of its functions is intranet penetration. nps includes both server and client components. It’s important to note that the nps server acts as an intermediary station, connecting various clients together. Therefore, when setting it up, you first need a host with a public IP address to deploy the nps server. Then, the machines to be accessed need to connect to the nps server using the client npc. Other clients can then use the nps intermediary to connect to the target client.

In summary… unlike VNC, RDP, and SSH, where the machine being accessed runs a service, this method uses the nps server as an intermediary.

HTTPS Proxy Settings

If you want to host the built services under a domain and access them directly via the domain, for security reasons, HTTPS is still necessary. Domain registration can be done by finding the cheapest available one first, then using Caddy for reverse proxying. After much trial and error, I ended up with this configuration.

{
  http_port 8888
  https_port 8384
}

:8384 {
    reverse_proxy localhost:7788
    tls /etc/caddy/domain.top.cer /etc/caddy/domain.top.key
}

your.domain.top:8384 {
    reverse_proxy localhost:7788
    tls /etc/caddy/domain.top.cer /etc/caddy/domain.top.key
}

Firewall Settings (iptables)

As before… for security reasons, a firewall should still be enabled. I also found some tutorials on how to use iptables (CENTOS 8开启iptables), but this is quite outdated. Many new systems now use other firewall management programs.

Docker访问宿主机端口方法

iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 443 -j ACCEPT 
iptables -I INPUT -p tcp --dport 7788 -j REJECT
iptables -I INPUT -p tcp -s 127.0.0.1 --dport 7788 -j ACCEPT