Setting up a local development environment with Rancher Desktop, WSL Ubuntu and VSCode

This article is part of Rafal’s subjective cloud journey and try-outs. A full picture view and the entire story is captured in my blog My Cloud tryouts.

I hope you will find it useful. Feel free to provide feedback either by contacting me or just simply leaving a comment below.

In this article, we will focus on setting up your local development environment. As a reminder, we want to develop a Java Spring app, test and run it locally in a prod-like environment, publish the results in a form of ready-to-go artifacts like application bundles, built docker images, helm charts, etc. This is more of the prerequisite for actual development and thus I’ll keep mainly references to other instructions plus some subjective observations (from a battlefield xD). We will play with a few things like

• Ubuntu in WSL (local Linux)
• VS Code and setup for WSL
• Rancher desktop for running docker

Ubuntu in Windows

This is as simple as installing Ubuntu from the Microsoft store. Windows is leveraging WSL2 (Windows Subsystem for Linux ) and I must say it works quite nicely! I was able to set it up to fully replace a need for GitBash with the advantage of being able to install all Linux software like Docker etc. I will highlight a few things only that helped me in my setup:

• You can run VSCode inside wsl (can choose distro), which means you will access the same data in vscode and ubuntu seamlessly
• From windows browser, you can access your distro via \\wsl$\
• Likewise, you can access Windows dir from within Linux via /mnt/c/
• You can easily install all remaining software via apt package manager. I installed things like docker, kubectl, helm, Kim, tree, zip + a few minor ones.

VSCode with integration with Ubuntu

The key highlight is to install Remote — WSL extension that allows you to set up VSCode in the context of your local Linux. Once installed you simply choose runtime (left bottom corner) and run in Ubuntu distro.

You can also set up your default shell to ubuntu, and thus run all commands in the context of the Linux distro.

There is only one point to this configuration. From time to time VSCode refuses to start with WSL error. To get rid of it, you need to run below from PowerShell

PS1 > wsl.exe --shutdown

Rancher Desktop

This is handy/light K8s local distro, that comes with 1 node cluster (run in a separate wsl distro) and some preinstalled software like helm, kubectl or kim (image manager). Some key highlights and considerations:

• This is quite stable, but from time to time may hang. The best approach is to tare everything down (reset to factory settings) instead of troubleshooting. You have it all in a code, right ??
• When you deploy your app, to access it, you need to setup port forwarding, there is a special tab in Rancher Desktop for that.
• It’s accessible nicely without any additional setup from Ubuntu, you just need to setup ~/.kube/config properly
• For kubectl, you will quickly discover you’ll find quickly you’ll have to manage several contexts. The option I follow is:

a) Create a symlink for kubeconfig

~/.kube/config -> /mnt/c/Users/[your user]/.kube/config

If you don’t do this, Rancher-desktop will show integration with wsl is not possible.

b) You can merge multiple contexts (clusters) into a single file. Some good documents:

How to merge kubectl config file with ~/.kube/config?

Configure Access to Multiple Clusters

c) Install kubectl extension to manage contexts. Works like a charm!

GitHub - ahmetb/kubectx: Faster way to switch between clusters and namespaces in kubectl

• You can increase visibility to your cluster by installing Lens. Works nicely
• You should also install ArgoCD to your local cluster. This will mimic your true GKE cluster behavior. I’ll explain setting up deployment and code placement in the following articles.

Getting Started - Argo CD - Declarative GitOps CD for Kubernetes

Rancher Desktop troubleshooting tips

• From time to time, Rancher Desktop hangs during cluster initialization with the message Waiting for cluster API. The best approach is to shut it down and restart wsl from Powershell with

wsl.exe --shutdown

Yeah I know, exactly the same “remedy” as for VSC. Seems like WSL is still not that stable as it should be :) Still a small trade-off if you know how to deal with it.

• Happened to me rarely, but I have a certificate issue when trying to leverage kim to push a new build image. For this, we need to bounce rancher-desktop by forcing a restart of an entire cluster

Uff, I think that’s it. I hope this was useful … You can read on next steps via My Cloud try outs

Rafał Kuszneruk