Coding, How to, kubernetes

How to build Kubernetes from source and test in Kind with VSCode & devcontainers

I found myself last week looking at a bit of code in K8s which I thought I could make better, so I set about trying to understand how to clone, change and test it.

Luckily K8s has some good docs, trust these over me as they’re a great guide. This blog is more of a brain dump of how I got on trying with Devcontainers and VSCode. This is my first try at this so I’ve likely got lots of things wrong.

Roughly I knew what I needed as I’d heard about:

  1. Bazel for the Kubernetes build
  2. Kind to run a cluster locally
  3. Kubetest for running end2end tests

As the K8s build and testing cycle can use up quite a bit of machine power I didn’t want be doing all this on my laptop and ideally I wanted to capture all the setup in a nice repeatable way.

Enter DevContainers for VSCode, I’ve got them setup on my laptop to actually run on a meaty server for me and I can use them to capture all the setup requirements for building K8s.

Continue reading
Coding, How to, vscode

VSCode Container dev a Remote Docker Daemon [Brain dump]

Note: This is more a stream of consciousness than a blog post. It’s not detailed and mainly for my own memory on how to set this up. Be cautious.

So I’ve recently built a new home server/lab and wanted to use some of it’s power to run my daily dev stuff.

I’ve been playing a bit with VSCode Remote for Containers which lets you define you dev environment as a container and commit it along with your code… it’s super nice.

So how about hooking it up to a remote docker daemon so that I can use the power of the new server from my laptop when I’m at home but switch back to my local docker deamon when I’m traveling… turns out the team have thought of that!

There are some great docs here on how to do this in detail:

What will follow is only useful if your like me, running Ubuntu on your laptop and also Ubuntu/Linux on the remote Daemon machine.

First up one of the key problems with this setup is with the file system access as a remote docker daemon on the server can’t see files on the Laptop. To get around this I’ve setup two alias which use rsync to push and pull data to and from the server from my laptop.

alias docker-remote-push="rsync -rlptv --progress \${PWD} \"lawrence@ubuntudev:\${PWD}/../\""

alias docker-remote-pull="rsync -rlptv --progress \"lawrence@ubuntudev:\${PWD}\" \${PWD}/../"

Then I can use docker context to setup a context for local and my ubuntudev remote box to easy switch between them.

Have a look here on how to create a context.

The last alias are to foward the docker for the remote deamon to my local box and switch to the context I’ve created for it.

alias docker-remote-start="ssh -fNL localhost:23750:/var/run/docker.sock lawrence@ubuntudev && docker context use remote"

alias docker-remote-stop="docker context use local"

Then all you need to do is add


To your settings.json in VSCode and now you are set to go.

Open up a folder in VSCode with a `.devcontainer` then run


Then use the `Reopen in container` option in VSCode and it’s done.

Coding, How to

Pass arguments to Golang program when debugging with VSCode

I’m doing some work on a golang project, the code takes a relative file path in as an argument.

Now I have Delve, VSCode and VSCode-Go installed which means I can have a nice interactive debugging session. The only snag I hit was that it wasn’t clear how to pass in my arguments when the debugger started my go code.

The trick is the use a double dash to indicate which arguments should go to the code, other args, before this, will go to the delve debugger. Also don’t forget to use “cwd” to set the working dir used when debugging.

Here is an example with comments

"version": "0.2.0",
"configurations": [
"name": "Launch",
"type": "go",
"request": "launch",
"mode": "debug",
"remotePath": "",
"port": 2345,
"host": "",
"program": "${workspaceRoot}/cmd/traefik",
"env": {},
// The here is key, telling delve to pass arguments after it to your code
"args": ["", "-c", "config.lgpriv.toml"],
// This controls the Working directory the code runs in, as my config.lgpriv.toml in my root
// I want the working dir to be the workspace root
"cwd": "${workspaceRoot}",
"showLog": true

view raw
hosted with ❤ by GitHub

And we’re away…

Screen Shot 2017-11-01 at 11.52.36


N.B The behavior is a bit odd, as the code here suggests that the “–” should be appended for you. However, this did not work for me, may be fixed in the future so double check!