Voice of the DBA

Author: way0utwest

Moving to Rancher Desktop

I’ve been very happy with Docker Desktop for years, running it on both laptop and desktop. However, a corporate decision was made to move to Rancher Desktop, so I now have an unexpected “opportunity” to learn something new.

Here’s a short post on how things went on the desktop and laptop.

Getting Rancher Desktop

I had never heard of Rancher. I’ve met a number of Linux/Oracle people using Podman, but not Rancher. You can download Rancher from rancherdesktop.io. This is a project from SUSE, of the Linux distribution fame, and one of their many projects.

The install is a next/next/next standard Windows MSI, though once installed, I found I needed WSL2 on my desktop. On my laptop, I ran wsl –v and saw this.

On my desktop, I installed this first, and tried to get things going. It installed, downloaded some Kuberbetes things, asked me to use containerd or dockerd (I chose the latter), and then was running. Once the engine was up, my docker commands worked and I could start containers.

However, there was a problem in that I had a volume (unnamed) that a few containers were using. However, after uninstalling Docker Desktop, I couldn’t find the volumes. I’m lightly concerned I’ve lost some data, which isn’t the end of the world, but it annoying.

Learning From My Mistakes

On my laptop, I decided to try and make this smoother. First, I uninstalled Docker.

Next I ran the Rancher install.

Once this installed, I started the desktop program. It again downloaded some Kubernetes components and then seemed to be up and running.

I tried Docker components after starting the Rancher Desktop (RD), but before I realized it was downloading stuff. That was the docker error shown first below. The second one was once the online status was shown in RD.

First Tests

I have a few containers set up to run SQL Server with docker compose files. I have a batch file I double click for “docker compose up” (and another for down). I clicked one and saw this: images downloading.

I assumed an image store would be an image store, but apparently not. Rancher must use a different place. That’s an interesting thing I need to check. Do I have extra images laying around. I think my Docker Desktop was using containerd, so maybe that’s part of this.

I could connect from SSMS fine and I could see my container running in the desktop (I had to switch away from the Containers item and back).

I also checked some docker commands and they seemed to work. I could get a list of containers, and apparently Rancher runs a bunch itself.

I could also see logs from my container, which are handy at times when I need to try and debug an issue.

Summary

I have to admit that after a week, I’m still nervous. Losing a volume, whether it’s really gone or I just can’t find it, is disturbing. I hate losing data.

Rancher seems to work fine for the basic things I do with containers, though the interface feels incomplete and simple. I can’t set hardware limits, it isn’t an active interface, and I feel like I’ve lost a lot of options. I didn’t really use more, but I still feel some loss.

I haven’t heard internal complaints from anyone, so I’m assuming that most container based things still work. We’ll see how I like this across the next month.

June 16, 2025
The Third Sabbatical
I can’t believe I’ve been at Redgate long enough to get a third sabbatical. I’ve very lucky to have this job, still enjoy it, and get the benefit. I’ve scheduled it from Jun 30 – Aug 8, and I’ll be gone from work during that time.

The idea of the sabbatical is to get away from work and recharge. It’s an extended break, and while some people use this to further their career in some way, others just try to get away from their daily life.

I wrote about a bunch of projects I had during my first one. The second one was less planned, but I also had a quick review of the time away.

For this one, I have no great plans right now. In fact, life has been so busy this year, I haven’t even had time to think about what to do, but I didn’t want to delay things, so this was the best time to take it.

I started this post to get me to at least lightly focus on the time and what the possibilities could be. For now, I have a few things to do:
- Work with a contractor to replace the covering on our riding arena
- Rebuild a better generator house and re-wire a circuit
- Replace some damaged fencing
- Rebuild 2 horse feeders
- Organize the garage a bit more
June 13, 2025
Advice I Like: Focus on what’s important

Don’t let someone else’s urgency becomes your emergency. In fact, don’t be governed by the urgent of any sort. Focus on the important. The urgent is a tyrant. – from Excellent Advice for Living

I try to set my life up to be fairly relaxed. A little chaotically busy, but relaxed. I try to stay ahead of work, plan things, get them prepped, and beat my milestones, at work or at home.

However.

As some people might say, life happens. Others might use a different 4 letter word, but I’ve liked life. As John Lennon says: Life is what happens to you while you’re busy making other plans.

I do try to help others and accommodate them, but another’s emergency isn’t mine. I am here for support, and to listen, but encroaching on my wallet or my time is something I have to choose to give you. Sometimes I might, but sometimes I might not. Ultimately. I don’t want to get jerked around by others, at work or in life.

I try to remember what’s important, which might not be someone else’s thing. This might mean previous plans take precedence. Or it might mean that I decide to help with your emergency. The important thing is the important thing.

I’ve been posting New Words on Fridays from a book I was reading, however, a friend thought they were a little depressing. They should be as they are obscure sorrows. I like them because they make me think.

To counter-balance those, I’m adding in thoughts on advice, mostly from Kevin Kelley’s book. You can read all these posts under the advice tag.

June 13, 2025
What is a Failed Deployment?

When talking about DevOps, the goal is to produce better software over time. Both better quality as well as a smoother process of getting bits to your clients. There are a number of metrics typically used to measure how well a software team is performing, and one of the things is Change fail percentage. This is the percentage of deployments that causes a failure in production, which means a hotfix or rollback is needed. Essentially we need to fail forward or roll back to get things working.

For most people, a failed deployment means downtime. I’ve caused a service to be down (or a page or an app) because of a code change I made. This includes the database, as a schema change could cause the application to fail. Maybe we’ve renamed something (always a bad idea) and the app hasn’t updated. Maybe we added a new column to a table and some other code has an insert statement without a column list that won’t run. There are any number of database changes that might require a hotfix or rollback and could be considered a failure.

However, some people see an expanded definition. If a service is degraded (slower), is that a failure? Some people think so. If we change code in a database (or indexes) and see performance slow down. In that case, is this a failed deployment? Customers would think so. Developers might not like this idea, at least not without some sort of SLA that might allow for some things to be a little slower. After all, slow is still working, right?

What if I don’t notice a problem? Imagine I add a new table/column, and the app starts accepting data and storing it. What if we are supposed to use this data downstream, and we don’t notice it is being aggregated incorrectly by a process until many days later. Perhaps we’ve performed some manipulation or calculation on our data and the result isn’t what we wanted. It might not be incorrect, but maybe it’s ignoring NULLs when we want NULLs treated as 0s.

Is that a failure? If I deploy today and Bob or Sue notices next week that the data isn’t correct, that’s a failure. I don’t know I’d count downtime from today until next week, but from when Bob/Sue files a ticket, the clock starts on calculating the MTTR (mean time to recovery).

I don’t often see database deployments failing from the “will it compile on the production server” standpoint. Most code gets tested on at least one other system, and with any sort of process, we catch those simple errors. More often than not, we find performance slowdowns or misunderstood requirements/specifications. In those cases, some of you might consider this a failure and some may not. I suppose it depends on whether these issues get triaged as important enough to fix.

While I might have a wide definition of deployment failures for most coding problems, I don’t for a performance slowdown. Far too few people really pay attention to code performance and are happy to let bad code live in their production systems for years.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

June 13, 2025