Test Driving Projector

Test Driving Projector

Jetbrains recently released Projector 1.0. This is akin to visual studio code remote access. It essentially allows for using any device as a thin client, and having Projector host the IDE, build and other items on a server.

My Use Case

For the past several years, I have used a partially optimal virtual machine setup. For each client I work with, they get a provisioned encrypted volume on my file server. That hosts the source code, and operating system image for that user.

The first pain point I had was the drift in operating system images. Utilizing ZFS I had a base snap short for my Linux or Windows install. I then based the client off that image. While that ensured all tools were installed, and my user account was set up. I still had to update the operating system on each respective system/client.

Looking at it another way the base system is ephemeral, I need a core set of tools depending on the engagement. Then a way to run an IDE. The only state that should be persisted is the project source I had tried a couple of other alternatives here, namely PXE boots. But the complexity outweighed the benefit.

The next complexity was remote graphical support. RDP is far and away the best remote graphcial tool. But Intellij feels noticeably slower to me on Windows, and my build process generally takes longer. The next issue with this approach was WSL. I had moved Intellij inside of WSL, which was decent. But all my servers are on Ryzen, which has issues with nested virtualization and Hyperv.

I had also used Spice, and it kind of works. But the lag feels a bit heavier than in Remote Desktop. It also took much longer to get a proper remote desktop setup working.

The last benefit is instance resume where I left off. All my servers sleep, and are woken via wake on lan. So when I start projector, it fires a wake on lan packet. Waking up the server. When I connect I immediately resume where I left off.

Switch to Projector

My first foray into Projector was the browser which was painful. Namely keyboard shortcuts. I then switched to the projector client. It works by and large, except for a few issues, and some are specific to docker.

My vision right now, is a continous build of a docker image container. The image is layered based on the project. Providing a set of core utilities, i.e. is this Kotlin, DevOps, TypeScript, etc. Running every X days it will automatically grab the latest security updates. Pulling the image  would update the underlying operating system.

Issues

  • Docker There is lag on the file system sync between the IDE and the shell.
  • Multiple windows is difficult at this point
  • A projector server UI would be really really really helpful
  • Invalidation of Cache is painful, and requires a stop of container
  • Re-freshing gradle projects is difficult.
  • Starting services, I bind an additional port.
  • MacOs client was noticeably slower, but I'm on a 2015 Macbook Pro

Forking Projector

AnimusDesign / Projector Arch Docker
Projector Images with arch support

I have forked projector docker container to my personal repository. The CI/CD isn't running this is due to an issue with glibc and containerd on Arch being too new :\.

This is my usual full stack environment

  • Kubernetes & kube ctx
  • Docker support
  • OhMyZSH
  • JDK 11, JDK 8 & GraalVM
  • NodeJS Type Script
  • Kotlin Interactive Shell
  • Kscript
  • Base build tools
  • Screen / tmux

The user is developer with no sudo access. This ensures lack of mutated state outside of the core code.

I tried volume binding just the core essentials, namely my dev folder. But I encountered errors with Intellij not recognizing my license, and other settings. There is a sample start script I use to launch an instance.

I also recently switch from a setting repository to the IDE Sync Plugin

Looking Forward

Every place I've worked the biggest initial pain point is getting my "dev environment" set up. This allows for a much more stream lined approach. By having a base container, all the tools can be provided, with boot strap scripts. The entry point can seed the container environment with appropiate secrets.

With Visual Studio Code, Jetbrains, and vim. You can cover a good chunk of the developer market with a base container image.

In a more locked down security context, you can deploy out side of a developers laptop onto a central server. On signs of a security issue just revoke, or terminate the developers instance.

I'm already looking into deploying onto a development Kubernetes cluster. Where each client is a name space and deployment, this would also allow deployment of other services say Redis, Kafka, etc.

We are now this much closer to the developer environment being repeatable infra as code.

Closing

Thank you Jetbrains, this has made my work flow much easier. The best statement I can say, is require minimal change to my existing process.