Alright, so today I wanna talk about this thing we internally started calling “Brighton Helm.” It wasn’t some official tool, mind you, more like our adventure into getting Helm charts to behave for our “Brighton” project. Things were a bit wild west before, deployments were all over the place, and we really needed to nail down a consistent way to do things.
Getting Our Feet Wet
We’d heard about Helm, obviously. Sounded like a good way to package up our Kubernetes stuff. So, the first thing I did was just try to understand what these charts even were. Spent a good few days just messing with the basic Helm commands, creating dummy charts, trying to install them. It felt a bit like learning to ride a bike again, lots of falling over initially.
Our first attempt at sharing charts? We just threw them into a Git repository. Yeah, you can guess how that went. It worked, kinda, for a tiny team. But as soon as more people got involved, it became a mess. Versioning was a nightmare, and telling people which commit to use for which chart was just painful. We knew we needed something better, a proper repository.
The Hunt for a Real Solution
So, I started digging around. Looked at a few options for hosting Helm charts. Some looked way too complicated for what we needed. We weren’t a giant corporation, just needed something solid for our Brighton project. I stumbled upon ChartMuseum, and it seemed to fit the bill. Simple, lightweight, and could run in a Docker container. That ticked a lot of boxes for me.
Here’s roughly what I did to get that going:
- Fired up a small virtual server. Nothing fancy, just enough to run a few containers.
- Got Docker installed on it. That part was easy enough, thankfully.
- Pulled the official ChartMuseum image. `docker pull chartmuseum/chartmuseum` – I remember typing that a few times.
- Then the tricky part: storage. I decided to start with local file storage on the server itself, just to keep things simple. Figured I could switch to S3 or something later if we really needed to. That involved mapping a volume in Docker, which always takes me a couple of tries to get right.
- Finally, ran the container. Had to fiddle with the port mapping and make sure it started up correctly. Watched the logs like a hawk.
Seeing it respond to a `curl` command for the first time felt like a small victory. It was alive!
Making it “Our” Brighton Helm
Okay, so ChartMuseum was running. Great. But it was empty. Now we had to actually get our Brighton project’s charts into it. This is where the “Brighton Helm” idea really started to take shape. It was about our specific workflow.
First, I had to learn how to properly package our existing charts. The `helm package .` command became my best friend. It crunches everything down into a neat `.tgz` file.
Then, uploading them. ChartMuseum has a nice API. I initially used `curl` to push the packaged charts. It was a bit clunky, but it worked. Later, we found the `helm-push` plugin (from the `cm-push` days, if anyone remembers that!), which made life a bit easier for the team.
The next big hurdle was integrating this into our CI/CD pipeline. We wanted new versions of our Brighton services to automatically package their Helm charts and push them to our new ChartMuseum instance. That took a fair bit of scripting and testing. Lots of trial and error there, believe me. Failed pipeline runs became a common sight for a while.
The Sweet Taste of Success
The real magic moment, the one where I knew all this faffing about was worth it, was when I could finally type:
`helm repo add brighton-charts http://our-chartmuseum-server-address`
And then, to deploy one of our Brighton services:
`helm install my-release brighton-charts/our-service-chart –version 1.2.3`
It just worked! Smooth as butter. Suddenly, everyone on the Brighton team could pull the exact version of the chart they needed, reliably. No more passing around tarballs or pointing to specific Git commits. It was a huge step up for us.
So yeah, that was our journey with “Brighton Helm.” It wasn’t some off-the-shelf product, but our process of taming Helm for the Brighton project. Took some effort, a bit of head-scratching, but in the end, it made our lives a whole lot easier. We could finally manage our application deployments in a sane way.
