Press "Enter" to skip to content

Category: Containers

Load Testing SQL Server with HammerDB and Docker

Anthony Nocentino announces a new tool:

I’m excited to announce the release of a new open-source project that fully automates HammerDB benchmarking for SQL Server using Docker. If you’ve ever needed to run TPC-C or TPC-H benchmarks multiple times, you know how time-consuming the manual setup can be. This project removes the hassle and gets you up and running a single command: ./loadtest.sh.

Click through to learn more about the project and how you can grab the code.

Leave a Comment

Defending Kubernetes

Joey D’Antoni defends the defensible:

I’ve seen a couple of posts (of course they were chock full of AI slop images) on LinkedIn in the last couple of weeks, talking about how challenging it is to implement Kubernetes. In the most recent post I saw, it stated that “it took 5 months for our CEO to implement Kubernetes for our app”, to which I would ask, why the hell is your CEO configuring your clusters. I designed, and implemented the Kubernetes infrastructure on my current project, and I’ve worked on for a while, so of course, I felt the need to share my opinions on the matter.

As far as Kubernetes on-premises goes, there are quite valid reasons to run it on-prem. Yeah, it’s easier to host in AKS or EKS, but that’s not always possible. But regardless of whether you’re hosting on-prem or in a cloud provider, Kubernetes requires solid knowledge across several areas, including networking, storage administration, systems administration, and CI/CD, not to mention the development skills needed for containerization.

I think Joey downplays the skill level required, but I don’t want to err in the opposite direction by overstating the challenge. But if you want anything beyond the bog-standard deployment of AKS/EKS, the “You must be this tall to ride the ride” sign is significantly higher than using other containerized solutions like Azure Application Services/Container Apps or Elastic Container Service.

Leave a Comment

Secrets Management in Kubernetes

Anshika Varshney takes us through some secrets management:

Secret management is a critical part of working with Kubernetes. When working with Kubernetes, you’ll often need to store and use sensitive information — like database passwords, API keys, and certificates. That’s where Kubernetes Secrets come in. But here’s the thing: while Kubernetes provides a way to store secrets, using them incorrectly can still expose your sensitive data.

This blog will walk you through:

  • What Kubernetes Secrets are
  • How they work
  • Common mistakes (the wrong way)
  • Best practices (the right way)
  • Real-life examples and configurations

Read on for the full article. I do want to iterate what I consider the most important of Anshika’s points: these things should never go into source control. The problem is, source control history is a lot more permanent than people customarily think about, so if you accidentally checked in a password in a config file somewhere, then got rid of the line with the password in it, a bad person with access to your source control can still look at history and find that password. The mechanism to rewrite Git history to remove a line’s existence is purposefully difficult, so a lot of developers don’t even know that it’s possible. But even then, if you’re hosting on someplace like GitHub and forks are enabled, rewriting history in your fork doesn’t rewrite it in somebody else’s fork, so again, a bad person with a fork from the right time frame could still see your exposed password.

The only fix is to cycle credentials if you ever do accidentally expose a password or key in source control files.

Comments closed

Securing PostgreSQL Containers

Mercy Bassey grabs a certificate:

Running Postgres in Docker is great for a quick test but what if you want it to behave like a proper, production-style setup with SSL encryption, certificate-based authentication, persistent volumes, and custom configurations? In this article, we’ll find out how, tackling the various tasks involved such as:

  • Generating and using self-signed SSL certificates with Postgres.
  • Setting up a PostgreSQL Docker container that uses those certs for encrypted client connections.
  • Configuring authentication for both automated services and human users.
  • Controling the behavior of your Postgres instance using mounted config files.

Read on to see how.

Comments closed

First Thoughts on Rancher Desktop

Steve Jones tries something new:

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.

I’m guessing corporate made the switch because of Docker for Desktop’s licensing costs. It is kind of funny how, in the Windows and even MacOS world, “Docker” is synonymous with “container,” whereas in the Linux world, that’s not at all the case.

Comments closed

Creating a SQL Server 2025 Container

Vlad Drumea tries out SQL Server 2025:

This post covers creating SQL Server 2025 containers in Podman, Qnap Container Station, and sqlcmd, and restoring a sample database to test the new version.

One important thing to remember is that all SQL Server 2025 containers are based on the Linux build of SQL Server. For 90% of tasks (give or take), that won’t matter, and you’ll still have a good time trying out the new version of SQL Server and make sure things still work in your databases the way you expect them to. But some functionality (e.g., merge replication) is not available in Linux and other functionality (like PolyBase or Machine Learning Services) has a very different installation process.

Comments closed

Online Vertical Scaling of SQL Server in Kubernetes

Andrew Pruski controls the horizontal. Andrew Pruski controls the vertical:

One of the new features in Kubernetes v1.33 is the ability to resize CPU and memory resources for containers online, aka without having to recreate the pod the container is running in. In the past, when adjusting a pod’s resources, Kubernetes would delete the existing pod and create a new one via a controller.

Not a problem for applications that can have multiple replicas running, but for SQL Server this would cause a disruption as we (generally) only have one pod running SQL Server in a statefulset. Let’s see this in action.

Click through to see an example of normal behavior, followed by how it differs in the latest version of Kubernetes.

Comments closed