kubernetes

When running other people’s software, there are a variety of ways that one can impact the deployment. Developers typically provide a set of configurations that can be set during deployment. Additional configurations are available once it’s running. These are design choices to decide which levers to provide and how flexible to make them. I wanted my instance to do some stuff that the latest release doesn’t do.

You know how every time any startup deployed software for the 2010s, a news article was posted 6-12 months later about how their files were all stored in a completely unprotected S3 bucket? It’s my turn and it’s a speedrun!

Since the Fediverse stuff is catching on, I decided to upgrade the deployment. New name, Kubernetes deployment, encryption, the whole thing. Also moving my account across instances went pretty well.

I feel compelled to write this up because of the struggles I faced along the way. Nothing was terrible or difficult but some of the docs were outdated and I had to find random gists and do some code archeology.

Picture it, Silicon Valley (but remote), twenty nineteen.

I’m working at GitLab after being hired despite the job description saying “needs Kubernetes experience” and my interview featuring the concession:

Yeah, we don’t really see anybody with Public Sector and Kubernetes experience.

Coder recently made their enterprise offering free for up to 10 developers. Since my solution, which I will henceforth call “ICSW”, supports 1 developer, it is well within that limit. I configured a new namespace in the same cluster to run the Coder Enterprise system to see how they compare.

TL;DR: Coder Enterprise has a lot of benefits for centrally managed code-server deployments as well as a multi-image workflow.

Upgrading code-server from 3.4.1 to 3.5.0 was always supposed to be easy. Turns out it was easy.

Just for the sake of sharing the ease, I’ve written up the embarrassingly simple process.

The new capability is running additional pods and services (and ingress and statefulsets) within the development namespace using the developer service account. This limited access role can’t impact other services but can start a container and use internal DNS and services to access them.

Pushing the limits of mobility and performance has become easier now that the iPad Pro has the Magic Keyboard and Visual Studio Code can be web-based as code-server.

TL;DR: It’s pretty nice but has some shortcomings. This article covers both the workflow and configuration.

One of GitLab’s strengths is creating productivity-boosting constraints that positively impact system architecture and DevOps cycles. This is very clear in the Kubernetes-powered workflow, but discovering this can be impossible if an org is already locked into an ops-focused Kubernetes deployment.

Also, Kubernetes is entirely optional so don’t force it before the operations team is ready. Avoid ClickOps, even if that means delaying orchestration.